Updating UVM Component properties via Field Automation Macros

UVM
, , ,
1

Hi All,

In my current project I have multiple instances of AXI Master UVC.

Within the UVC there exists Write and Read driver which has the following properties

// typedef integer unsigned uint
// typedef enum bit { TRUE = 1 , FALSE = 0 } boolean_t;

// Within class mst_rd_driver `PARAM extends uvm_driver#( txn); 
    uint       fwd_progress_timeout_value = 5000;
    int        verbosity = UVM_HIGH;
    boolean_t  objections_enabled = TRUE;
    string     STR = "RD_DRIVER";
    vintf `PARAM  vif_proxy;


`uvm_component_param_utils_begin( mst_rd_driver `PARAM )
  `uvm_field_object(vif_proxy,UVM_ALL_ON)
  `uvm_field_int(verbosity,UVM_ALL_ON)
  `uvm_field_int(fwd_progress_timeout_value,UVM_ALL_ON|UVM_DEC)
  `uvm_field_enum(boolean_t,objections_enabled,UVM_ALL_ON)
  `uvm_field_string(STR,UVM_ALL_ON)
`uvm_component_utils_end

// Within build_phase() the component calls super,build_phase(phase);

Given that there exists write & read driver within each of the UVC instance, how do I set the above properties for specific instances ?

Assuming I am performing a config_db::set from my Tb and I am trying to configure all the above 5 properties to instance “uvm_test_top.axi_uvc0.agent.rd_agent.rd_driver”

// Configuring  :: uint fwd_progress_timeout_value to ‘1 ( all ones )

uvm_config_db#(integer unsigned)::set(null,“uvm_test_top.axi_uvc0.agent.rd_agent.rd_driver”,"S1",A1);

[1] What should be the actual to arguments S1 ( string type ) and A1 ( integer unsigned type ) ?

On replacing A1 with ‘1, would I achieve all ones ?

// Configuring UVM_VERBOSTY within the Read Driver to UVM_LOW
uvm_config_db#(int)::set(null,“uvm_test_top.axi_uvc0.agent.rd_agent.rd_driver”,"S2",UVM_LOW);

[2] What should be the actual to argument S2 ( string type ) ?

[3] Can I replace the int specialization with UVM_VERBOSITY ?

// Configuring STR within the Read Driver to "UVC0_RD_DRVR"
uvm_config_db#(string)::set(null,“uvm_test_top.axi_uvc0.agent.rd_agent.rd_driver”,"S3","UVC0_RD_DRVR");

[4] What should be the actual to argument S3 ( string type ) ?

// Configuring objection_enabled within the Read Driver to FALSE
uvm_config_db#(boolean_t)::set(null,“uvm_test_top.axi_uvc0.agent.rd_agent.rd_driver”,"S4",FALSE);

[5] What should be the actual to argument S4 ( string type ) ?

// Assuming my Tb has an instance of vintf (called 'my_vintf') with the same specialization as mst_rd_driver 
uvm_config_db#(vintf `PARAM)::set(null,“uvm_test_top.axi_uvc0.agent.rd_agent.rd_driver”,"S5",my_vintf);

[6] What should be the actual to argument S5 ( string type ) ?

2

I would consider this agent to be poorly written and recommend that you rewrite it to better follow UVM recommendations:

  1. Don’t use field macros.
  2. Create an agent configuration object to encapsulate all controllable parameters
  3. Pass the configuration object from the test to the environment to the agent using the configuration DB.
3

I am aware that the topic of field macros has a difference of opinion across the industry ( Eg: what-ever-you-do-dont-use ).

In my current project I have to make use of the available UVC ( which unfortunately does use the field macros ). As the UVC is in a central path and is sourced across multiple projects I can’t edit it.

An alternative to the above uvm_config_db :: set is hierarchically assigning the respective properties ( fortunately these aren’t local / protected type )

However I am still curious to know the respective way to set each of the above properties

4

If this is a UVC provided by another party, then I would expect that there are examples provided for you to reference. These examples should provide the appropriate methods to set the desired properties.

5

Any modification caused by field macros can be overwritten by an explicit implementation, because this has the precedence.

6

@chr_sue , I am not clear on your comment

Do you suggest that I should have an explicit uvm_config_db :: get ( after calling super.build_phase() ) for the parameters of interest ?

7

I mean there is another option to update your class properties. You don`t have to use the field macros.

8

Since the UVC modeling the AXI Master has the field macros I can’t remove them ( even if I were to perform instance override of the write , read driver components )

Yes I could also possibly add an API to assign these properties within my extended class