Use of Config Class Handle inside Transaction Class

UVM
1

Hi,

I’m using a transaction class, in which most of the variables are configurable whose details are there in config class.

So is it good to use config class handle inside transaction class to do configurable or I need to use config class handle somewhere else like inside test for this?

2

Transactions are typically generated by sequences. Once created, the sequence can set values in the transaction directly or via inline constraints:

tr = tr_type::type_id::create("trans");
  tr.op = cfg.op_type;
  start_item(tr);
  tr.randomize() with {addr < cfg.max_addr;};
  finish_item(tr);

The recommendation would be to have the sequence get the configuration object and use that information to set/constrain the transaction. If the configuration information may change on a per-transaction basis, it’s still preferable to have the sequence re-get the config object before calling finish_item().
Since transactions get created and destroyed many times during simulation, it’s better to keep them as small as possible. Besides, since there’s no “run” method for transactions [unlike the body() method of the sequence], you’d have to create your own get_transaction_config() method and call that from the sequence anyway. You may as well just get the config from the sequence and use that to set the values in the transaction.
-Tom

3

In reply to tfitz:

Thanks Tifitz.

But suppose We have 3 values like RGB444, YCBCR444, RGB888. Now if the config class will make the Support_RGB888=1, then in the packet class , RGB888 pixel_coding value will be activated and such type of packet will be generated.

Here in my transaction class all the fields are config class dependent. So in this case is it OK to use the instance of config class inside transaction class or as per you we can only use it through Sequence Class or inside test.

4

In reply to psp127143:

pixel = pkt_type::type_id::create("pixel");
uvm_config_db#(pkt_cfg)::get(this,"","pkt_cfg",pkt_cfg_h);
case(pkt_cfg.pixel_coding)
  RGB444: // set RGB444 data in pixel
  YCBCR444: // set YCBCR data in pixel
  RGB888: // set RGB888 data in pixel
endcase

That works if there’s one pkt_type that can hold any type of pixel. If you make each pixel type an extension of a base_pixel type, then you would need to get the config in the sequence before creating the pixel in the first place, so checking the config in the pixel transaction would be too late.
Having them all extended from the same base type would require the driver to be able to handle the transmission based solely on the base type.