Randomize dut parameters in system verilog - random

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.