I wonder which is the best approach to randomize configuration and to propagate it to the DUT registers and to configure the verification environment.
Could you tell me if this approach is correct:
UVM RAL.
Convenient class where some convenient functions/tasks are declared such as: set/reset reg model, read/write register, read/write field… and a configure DUT task (talked later).
Configuration class with parameters which are representing features rather than registers. Eg: “data_if_mode” which is randomized to be Ethernet or LVDS, and a different set of registers are then configured.
Configure DUT task (discussed before) to propagate the randomized configuration to the DUT registers.
Verification environment is relying on the configuration class parameters to generate/predict/check results.
For an initial configuration I don’t have issue, but when it come to make my tests more dynamic then I need to ensure that my configuration class is up to date with the register and vice versa. This part is a bit tricky and open the door to errors.
What could be a better approach? Or a more common way with examples if possible?
I hope I am clear enough. Thanks in advance!
Martin
Your question is quite complex and not completely clear to me.
I’m trying to answer your question as I understand it.
If you have more than 3 or 4 configuration registers in your design it is useful to employ the UVM RAL. This is completely independent from any specific configuration mechanism.
It seems you have different legal sets of configuration registers, right?
You can randomize complete register content but also only register fields. Yopu do not need any configuration objects with respect to this.
But you can use configuration objects to randomize the data members of these objects.
After randomization you can write these configuration data to your configuration registers.
Does this answer your question?
Hi chr_sue, thanks for your answer.
My question doesn’t seem to be as clear as I though :)
I’ll try to clarify.
I am employing the UVM RAL already, the 5 points I mentioned in my first post are the mechanism I have in place currently but I am not quite happy with that.
“But you can use configuration objects to randomize the data members of these objects. After randomization you can write these configuration data to your configuration registers.” this is what I am doing basically. This is working fine as long as my tests don’t need to change any register value after the DUT initialization. Trouble will come when:
the test writer is writing into a register without updating the configuration object.
the test writer is changing the configuration object without propagating this change to the actual registers.
Is there a (common) way to ensure that this configuration object and the RAL/DUT registers are kept in line?