by Jason Sprott
Jason Sprott is CTO at Verilab.
Often times we find ourselves with some configurable RTL to verify. The amount of configuration can vary from a few bus width parameters, or a configurable IP block with optional features and performance related control parameters, to a whole chip with optional interfaces. This can make our life as verification engineers that bit more complicated. We not only have to verify the multitude of scenarios for a specific implementation, we have to somehow handle building and running a testbench for the various RTL configurations. Especially in the case of standalone IP, it’s often the case that different configurations are included in our verification space.
Configurations may affect the physical interface between the testbench and RTL, for example: • Bus widths • Number of interrupts • Number of instances of an external interfaces such as USB or Ethernet
Or, the configurations might control internal behavior, which doesn’t affect the physical interface, but does affect the way the test bench has to interact with the DUT functionally. Examples might include: • FIFO Depth – which may affect data pattern generation to hit corner cases, or performance related water marks • QoS algorithms – where different algorithms implementations are selected depending on requirements, which could affect traffic generation, checking, or functional coverage
The VMM has a new RTL configuration feature which can make life a bit easier. RTL configurations can now be encapsulated in a testbench object that can be used to generate an output file. This output file can be shared between the RTL and testbench. The steps in the process go something like this:
STEP 1: Compile the RTL (with some default configuration) and testbench. This is needed to run the configuration file generation only. Tests will not be run in the simulation.
STEP 2: Run simulation to generate configuration file
./simv +vmm_rtl_config=<PREFIX> +vmm_gen_rtl_config …
The format of the output file can be customized by extending a companion format class. This determines the output format written and also the parsing of the file back into the testbench. The (simple) format that comes out of the box looks like this:
num_of_mems : 4 has_buffer : 1
This obviously isn’t RTL code, so if we want our Verilog to understand it, for example converting it to assign parameter values, we have to perform the next step.
STEP 3: Convert output configuration file to verilog params file (or format of your choice, such as IP-XACT)
A script is provided as a demonstration, in the memsys_cntrlr std_lib VMM example.
./cfg2param <config_file>
STEP 4: Re-compile the RTL using the new parameters generated by the configuration, e.g. using -parameters switch in VCS.
STEP 5: Run the simulation executing tests, passing the configuration into the testbench
./simv +vmm_rtl_config=<PREFIX> …
The code encapsulating the configuration parameters in the testbench is encapsulated using the vmm_rtl_config class. The code that implements output to the configuration file for each variable is done using macros. The example below shows implementation for class member variables.
class my_cfg extends vmm_rtl_config; rand int num_of_mems; rand bit has_buffer; constraint valid_c { num_of_mems inside {1,2,4,8}; }
`vmm_rtl_config_begin(my_cfg) `vmm_rtl_config_int(num_of_mems,num_of_mems) `vmm_rtl_config_boolean(has_buffer,has_buffer) `vmm_rtl_config_end(my_cfg) … endclass:my_cfg
On the testbench side the configuration is set using the vmm_opts::set_object() in the initial block of the program block of your testbench and can be retrieved through the vmm_opts::get_object().
The beauty of using this method for RTL configuration is that constrained randomization and functional coverage collection can be used for RTL configurations. In projects where highly configurable IP has to be verified, it’s a convenient way to control and observe progress of verification across, not only the modes of operation, but also those modes relating to specific RTL configurations.
ShareThis
Posted in
