Possible ways to make "set/get_config_*" assignments?

Hi All,

I would like to know possible ways to make “set/get_config_*” assignments like:

  1. Inside initial block of test bench
  2. Inside class methods
    3…
    4…

Whether I can make this assignment inside test bench module body?

What are the restrictions in using this factory setting?

Can anyone fill the above list?

thanks in advance.

regards
TVAR

As far as I can tell the set_config_… and get_config_… functions can be called at any point during the simulation.

But the intention I think is pretty clearly that they are suposed to be used as semi-static configurations and as such should be applied before object construction. It’s probably ok, for the strings and ints to change the config after construction, but certainly doesn’t make sense for objects. As for heirachy, they can aren’t static functions, so must be called heirachically from rtl modules, but other than that I don’t think there is a restriction.

The methodology basically recommends that the place do do all these configurations is in the very top level ovm_test class. In general I think this is what the config stuff was put in for, getting specman like “aspect orientation” to tweak test constructs, without going through the hassles od aspect ortientation.

Does that help?

Andrew is mostly correct, but there’s a bit more.
When considering configuration, there are two types of information about which one needs to be concerned.

  1. Static build-time configuration[LIST]
  2. The number and type of components that should be instantiated
  3. Default settings for run-time behavior

[*]Dynamic run-time configuration[/LIST]The keys to successful configuration are that 1) each component is responsible for getting its own configuration information at the appropriate time and 2) configuration can be overridden hierarchically.

Key #1 means that an agent will get configuration for active/passive during build to determine whether to instantiate the driver (which only gets instantiated in active mode). Once instantiated, the driver can get configuration for behavioral parameters during its idle cycle, for example.

Key #2 means that the environment could set configuration values for its children, but then the test that instantiates that environment could override those settings if desired.

Build() is executed top-down so parents can set build-time configuration for children before the children execute build() to get the configuration.

-Tom

Hi tom & andrew,

Thanks for your details.:)
It really helps me to understand the factory configuration usage.

Would you please elaborate on whether to call get/set_config* in build or end_of_elaboration functions?

I do face some issues due to this.:(

Thanks in advance:D

TVAR

Personally I would do it in the build() stage, applying them to any children of the object being built.

I think this is just a personal preference as you can put them along side the set_inst_… and set_type_… configuration functions, which aren’t possible once the object is built. I think if you restrict yourself to having the one place where config overrides are used you can save yourself some confusion.

Would you please elaborate on whether to call get/set_config* in build or end_of_elaboration functions?

Where to use get/set_config depends on what you are configuring. For build-time information that will affect the build behavior of children, the set_config should be called in parent.build() and the corresponding get_config would be called in child.build(). This works because build() is called top-down, so parent.build() will be called before child.build(). Actually, in 1.0.1, build() is *[I]effectively*[/I] called top-down because it gets called on children after they are constructed, which happens top-down. In 1.1, build will *[I]actually*[/I] be called top-down. For run-time configuration, it is best to call child.get_config() in end_of_elaboration to establish default behavior, with the option of also calling get_config() in the run phase at appropriate times (assuming the parameter is something that it makes sense to change at run-time). Parent components, including ovm_test, ovm_env and other ovm_threaded_components should call set_config() in the configure() method, which is guaranteed to execute before end_of_elaboration. Note, in 1.0.1, configure() only gets called for ovm_threaded_components (and extensions thereof). In 1.1, configure() will be a proper phase, as will build().

Hi,

I am trying to configure env class’ variable, say “num_of_trans” from test class using set_config int. This variable has it’s own default value in env class and also registered in the same class through field macros. When i pass some values through test_class, it is not configured and always take default value.

In test class

class sv_test extends ovm_test;
      env m_env;

   `ovm_component_utils(sv_test);
   
   function new(string name = "sv_test", 
		ovm_component parent=null);
      super.new(name,parent);
   endfunction : new

   virtual function void build();
      
      set_config_int("m_env.*", "rand_tst_max_cycle_cnt", 100);
      $cast(ahb_env, create_component("nvs_ahb_sv_env", "ahb_env"));
      ahb_env.build();
   endfunction : build
   
endclass

In env class

Code:
class env extends ovm_env;
int unsigned rand_tst_max_cycle_cnt=50;

// Provide implementations of virtual methods such as get_type_name and create
ovm_component_utils_begin(env) ovm_field_int(rand_tst_max_cycle_cnt, OVM_DEFAULT+OVM_DEC)
`ovm_component_utils_end

task run;

  void'(get_config_int("rand_tst_max_cycle_cnt", value));
  $display("%s In run: rand_tst_max_cycle_cnt=%d",
       get_full_name(), value ); ///////This value is displayed 0 always:confused:

endtask : run

Possibly the problem i can figure out is, when i print the heirarchy from test class, i can see “test_class” and “env class” as 2 different heirarchy components, but i think “env” class should have been a part of test_class only (assuming from xbus example heirarchy). Here the field “rand_tst_max_cycle_cnt” is displayed 50 (default) but on get_config_int it is displayed 0

Code:


Name Type Size Value

---------------------------------------------------------------------------

urm_command_line_processor ovm_object - @{urm_command_line+

---------------------------------------------------------------------------

---------------------------------------------------------------------------

Name Type Size Value

---------------------------------------------------------------------------

ovm_test_top sv_test - @{ovm_test_top} {r+

---------------------------------------------------------------------------

---------------------------------------------------------------------------

Name Type Size Value

---------------------------------------------------------------------------

env m_env - @{ahb_env} {ref to+

Could you throw some light where i missed, while registering or something else.

Thanks,
Saurabh Sharma

Hi,

One potential problem I see is that you are setting the config entry with the path “m_env.*”. This path means that the entry is applied to all children of m_env, but not to m_env itself. (You said that you want to set a configuration entry for m_env)

You can use “m_env*” to apply it to both m_env and all children, or you can leave the existing set_config and add a second call to set_config with the path string “m_env”.

Also, you need to make sure your given string names match. In the example you gave, you named you environment “ahb_env” in the second argument to create_component. Was that the environment component you wanted to configure? If so, then that second argument string should match what you specify in the set_config path.

-Kurt

Hi Kurt,

One potential problem I see is that you are setting the config entry with the path “m_env.". This path means that the entry is applied to all children of m_env, but not to m_env itself. (You said that you want to set a configuration entry for m_env)
You can use "m_env
” to apply it to both m_env and all children, or you can leave the existing set_config and add a second call to set_config with the path string “m_env”.

I even tried “*” heirachical path but that too didn’t worked. I can figure out that there is some problem with heirarchy generation and not heirachical reference. I am unable to find out how come the “m_env” and “ovm_test_top” became the two seperate heirachy and not the single one as expected.
I think set_config_int(“*”,“xyx”,some_value) sets the integer, if matched, whitin it’s own heirarchy. But the issue still is 2 seperate heirarchy legs:confused:

Also, you need to make sure your given string names match. In the example you gave, you named you environment “ahb_env” in the second argument to create_component. Was that the environment component you wanted to configure? If so, then that second argument string should match what you specify in the set_config path.

I changed the exact instances name, I am using “ahb_env” at my end ,but changed to “m_env” for pasting example here. Also just the interesting code snippets as shown here.

Best Regards,
Saurabh

Any suggestions:(