We have the need to create a DUT configuration sequence that sets different register values (or a different set of values) every time is started. The test goes in a “loop” and runs the same steps to perform a ‘configure’ → ‘measure’ → ‘check’ type of logic.
Clearly we can define two different sequences and have the test start the second one at the second iteration, but if we have dozens of iterations we might want to find a different solution.
One idea could be to store the randomized variables in a dynamic array in the post_randomize() and then make sure to use it in the constraint. But I’m not sure if that’s a valid approach. This approach forces to create the sequence only once and then be randomized for the other iterations.
Any idea on how to tackle the problem?
You need to clarify a number of things. When you say "different "do you mean “unique” for each iteration? Let’s say you had 4 registers. If one of them was different, but the other three were the same is that still considered different?
Normally one would put these register values in a configuration object and randomize them for each iteration. Your constraint would simply be to make the register values equal to the value values in the configuration object.
Apologies for my loose definition of the problem, I was trying to think of it while writing and some details have gone missing.
What I meant by “different” was indeed the set of registers, therefore having one out of the four values different would still be a different set. On some cases we may want some of the registers to change from one value to another (e.g. sweeping through a range) while keeping the other random, in some other cases we don’t want to repeat the same set.
We are using policy classes for constraints (inspired by J. Dickol’s famous piece and further developed by J. McNeal and K. Vasconcellos) and I guess we could randomize those policies again, possibly with additional inline constraints:
// pseudo code: test build_phase adds/removes policies for config
function build_phase(uvm_phase phase);
env.seq_cfg.policy_list.rm(env.seq_cfg.blockApcy);
env.seq_cfg.policy_list.add(env.seq_cfg.blockBpcy);
env.ser_cfg.policy_list.add(env.seq_cfg.BlockCpcy);
endfunction : build_phase
// test main_phase
function main_phase(uvm_phase phase);
// iteration keeps track of jumps through main_phase
if (iteration == 0)
env.randomize() with {env.seq_cfg.regA == 3;};
elsif (iteration == 1)
env.randomize() with {env.seq_cfg.regA == 4;};
endfunction : main_phase
The seq_cfg object contains all the policies and is passed to the sequence which will have a different constraint when started during the second iteration.
A little bit more complex would be if the test needs to maintain the list of the already used values, but I guess that’s equivalently achievable with an array that is populated after every randomization call.
// pseudo code: add values to dynamic array to constraint confg
function main_phase(uvm_phase phase);
// sarray is a static array to keep values we don't want to repeat
env.randomize() with {env.seq_cfg.regA not in sarray;};
sarray[iteration] = env.seq_cfg.regA;
endfunction : main_phase
Clearly it would have been even better if the config object had a way to store the already used data ‘somewhere else’, and don’t bother the user with bookkeeping. We could potentially use the “strategy pattern” to implement constraints on successive iterations, similarly to how the uvm_sequence_library chooses what to run next… just thinking.