Constrained Random Control using the OVM Command Line Package

 Advanced Verification environments contain a lot of model attributes that can be randomized. OVM data items and sequences provide the industry-leading mechanisms for easily defining and controlling the randomization of stimulus as transactions to randomly exercise a DUT. This is generally accomplished by defining random data members and creating sequences of transactions using the OVM sequence base classes. Behaviorial models (e.g. reactive stimulus) often contain randomizable attributes as well. The models are often randomized once at the beginning of simulation and the values for the model are used throughout the simulation since they often can't change (or change infrequently) during simulation.

The functionality needed to define and create basic sequences is already built into the OVM library so users can write simple random sequences with very little effort. When more complex scenarios are needed, users can add constraints to derived classes and/or define their own sequences that hit the scenarios of interest. Models often have constraints in derived classes. Instancing the derived class can be done in the testcase using the OVM factory.  This requires a user to define a new derived model class and a new testcase each time they want to change the way a model is randomized (i.e. the setting of the "knob" values).

There's another option to vary the "knob" values that may be less obvious. If users define constraints to the values selected for a random variable using state variables within their class (e.g. min/max values), testcase writers can use the OVM Command Line Access package from Cadence (see ovmworld.com) to then set or override values of state variables from the command line.   Lets look at a simple example:

class MyModel extends ovm_component;

  rand bit[3:0] wait_states;
       bit[3:0] max_wait_states=-1;
       bit[3:0] min_wait_states;

  constraint min_max_wait_states_c {
    wait_states >= min_wait_states;
    wait_states <= max_wait_states;
  }

  `ovm_component_utils_begin(MyModel)
    `ovm_field_int(min_wait_states, OVM_ALL_ON | OVM_UNSIGNED)
    `ovm_field_int(max_wait_states, OVM_ALL_ON | OVM_UNSIGNED)
  `ovm_component_utils_end

  virtual function void build();
    super.build();
    if (get_config_int("set_wait_states", max_wait_states)) begin
      min_wait_states=max_wait_states;
    end
    ...

endclass : MyModel

The code shown above provides a huge amount of flexibility that may not be obvious. First, under normal conditions the min_max_wait_states_c constraints will have no affect because the min and max limits are set to the natural limits for the randomized wait_states variable. However, the few additional lines of code that were added above, allow the user to for the 'wait_states' to a specific value from the command line or establish a lower limit, upper limit or both. Lets look at few examples:

> irun MyModel.sv // waits_states is randomized between 0...15
> irun MyModel.sv +ovm_set_config_int=*,max_wait_states,9 // waits_states is randomized between 0...9
> irun MyModel.sv +ovm_set_config_int=*,min_wait_states,4 // waits_states is randomized between 4...15
> irun MyModel.sv +ovm_set_config_int=*,min_wait_states,4 +ovm_set_config_int=*,max_wait_states,9 // waits_states is randomized between 4...9
> irun MyModel.sv +ovm_set_config_int=*,set_wait_states,6 // wait_sets is forced to be randomized to a value of 6

As we can see it now becomes simplistic to write more tightly constrained (i.e. even directed) testscases just by adding a few runtime arguments to the command line. Another  advantage of this technique is that it doesn't require the design to be recompiled or even elaborated just to create another test. More complex testcases can also be defined this way using state variables (that are set from the command line ) within implication operators. Here's a short example:

int compute_algorithm=-1; //must include this field in OVM automation macro

constraint compute_wait_states_c  {
  (compute_algorithm > -1) -> wait_states == function_to_compute_wait_states(compute_algorithm);
}

Another powerful feature of the command-line package is its ability to specify which ovm components in the object hierarchy receive the command-line values. This means if the model class is instanced within a hierarchical tree, the state variables for any component within the tree can be set from the command line. Here's a short example that requires no changes to our code above, it just assumes the class is instanced with a specific hierarchy:

> irun mycode.sv +ovm_set_config_int=top.side*.*,set_wait_states,3 +ovm_set_config_int=top.sideA.*,set_wait_states,4 +ovm_set_config_int=top.sideB.*,set_wait_states,6

The command line arguments above forces the default wait_states for all instances to 3 but overrides the wait_states for sides A and B to 4 and 6 respectively.

Finally, the command line package allows run time arguments to be placed in files using the '-f' option. This provides a very powerful technique for defining and managing 'base' values which are then overridden in other testcase specific '-f' files making it easy for the user to create libraries of unique testcases that don't require the design to be recompiled.

As usual with OVM, adding a few additional lines of code to the testbench opens up a whole new world of flexibility and control to get verification done more quickly and efficiently.

See the attached file for a complete working example.