Randomize dut parameters in system verilog

Question

I am writing a test bench in system verilog for a dut, and in the field it is possible for the parameter DEPTH to change and so I have been trying to figure out how to randomize a parameter. It is currently set at 20 but it has a range of 7 to 255. Any suggestions and help would be greatly appreciated.

I know you cant directly in the script randomize it but ive heard of others do it by creating a package that they run along side the test that can insert random values as parameters.

Thank you for the useful answers but it seems we are going the route of linearly decreasing through all of the parameter sizes instead of randomizing them. — Liam P, Jul 21 '15 at 17:57

score 3 · Answer 1 · answered Jul 20 '15 at 21:31

It isn't possible to randomize parameter values, as these need to be fixed at elaboration time and randomization is a run-time task.

What I think you mean is that you can create a small SystemVerilog program that can model your parameters inside a class, randomize that and then write a package based on that.

class my_params;
  rand bit [7:0] depth;

  constraint legal_depth {
    depth inside { [7:255] };
  }

  function void write_param_pkg();
    // open a file
    // start writing to it based on the randomized values
  end
endclass

You can then instantiate this class in some dummy top module and use it to dump a package:

module param_randomizer;
  initial begin
    my_params params = new();
    if (!params.randomize())
      $fatal(...)
    params.write_params_pkg();
  end
endmodule

The output of writing the package could be:

package my_params_pkg;
  parameter DEPTH = 42;
endpackage

This you need to call before you start compiling your real testbench. The testbench will import this package and set the DUT's parameter to this one:

module testbench;
  my_design dut #(my_params::DEPTH) (...);
endmodule

If you only have one parameter (as opposed to multiple which are related to each other), it might not make sense to do the randomization in SystemVerilog, as scripting should be enough.

score 2 · Answer 2 · answered Jul 20 '15 at 21:34

Here is some solution I found, not sure if it's what you're looking for:
https://verificationacademy.com/forums/ovm/randomizing-module-parameters

In a nutshell:
You can create a class with fields inside representing values of parameters that are to be randomized. Then you instantiate it in a new module, which randomizes that class and outputs a new package file with random values for parameters. Finally, you compile that package with the rest of your modules.

score 2 · Answer 3 · answered Jul 22 '15 at 14:05

As has been stated by the other answers, parameter values have to be resolved at elaboration time. Typically they are passed in to the simulator command line:

vsim -gDEPTH=42

I don't think there's any advantage to using the SystemVerilog constraint solver to randomise your parameters. The hassle of writing out a package from SystemVerilog to feed into a subsequent compilation suggests something is wrong. Ideally all of the SystemVerilog code should be picking up the chosen parameter from the elaborated DUT so a package isn't required*. It's probably easier to update your build scripts, for example:

vsim -gDEPTH=$(shuf -i 7-255 -n 1)

Obviously this can be made more generic as part of an overall test harness. If you need constrained randomisation for parameters (unlikely but possible) then you could always use a more powerful scripting language.

This has the added advantage that if you have other configuration values (for example for non SystemVerilog software that is executed as part of the test) these can all be set from a single place and passed into the simulation.

* although it seems people often do use a package to share parameters because it can be awkward to access DUT params. Again for generating code and writing to files, you may find that using a standard scripting language will be more powerful easier to maintain.

The advantage of using the SystemVerilog constraint solver is that you don't get into the troubles dealing with multiple random parameters with dependencies that are not present with the SV solver. That is when you start picking a value for one random variable and then fund out that there is no solution for the second random variable. — dave_59, Jul 22 '15 at 14:27
@dave_59 that's an argument for constraint solving rather than SystemVerilog per se. For example we have many external dependencies (C++ or QEMU settings) so all parameter options need resolving outside the simulator and passing into to various subsystems by the test harness. — Chiggs, Jul 22 '15 at 15:10

Randomize dut parameters in system verilog

3 Answers3