Disabling randomization for some ovm_component from top level

ujjal.bose · December 21, 2009, 7:16am

Hi,

I could not understand a good way of doing this in OVM , from my reading so far, hence this question. If we have rand variables declared somewhere deep inside a component , but a particular test needs to disable randomization of that particular variable , is there an easy way to do this.

For e.g. , in pre-OVM (pure SV) world , we may have done in the test code :

initial begin
//some other code
top.A.B.C.var.rand_mode(0);
top.A.B.C.var = 5; //overriden value
//some other code
end

This would have ensure that when somebody gave a call to randomize() for object C , var will be constrained to value 5.

Now, with OVM, is there a way to do this without hierarchical access ? I know that set_config* methods can set variables hierarchically without having to type in the whole path, but they donot disable randomization.

Further, there are macros like `ovm_do which can be used to constrain the randomization, but they also work in sequence objects and not general purpose components (which are extensions of ovm_component), right ?

Any help would be appreciated.

Thanks,
Ujjal

dave_59 · December 21, 2009, 5:58pm

Ujjal,

Unfortunately, the OVM does not take advantage of the SystemVerilog feature. It would be a nice enhancement, but in the meantime you will just have to deal with the modes on your own. You can call get_config_int using your fields names appended with “_rand” and use that to set the rand_mode of your field. For example

if (get_config_int(“var_rand”,value)
var.rand_mode(value);

Dave

sri.cvcblr · December 22, 2009, 4:11am

Hi Ujjal,
Perhaps you are looking for some sort of a callback within the ovm_do* macros. Nice to have enhancement! Meanwhile here are some suggestions.

If you are using sequences, then you can potentially use a derived object of your transaction (ovm_sequence_item) and do this in post_randomize(). You could then swap it with factory object. (To be fair - once gain here is a key application for AOP extensions…I know not everyone in the SV-committee agrees with me, but if you have every used E, this is next to natural thing to do with great ease… Ujjal - recall our ACL validation times :-) )?
If you use ovm_do macro and have only a few such vars to constrain, you can use "ovm_do_with var == 5" (pseudo code/with syntax error). Not a great idea if there are many such vars as you are wasting constraint solver, but it maybe OK for few cases.
If your tool supports AOE for SystemVerilog (atleast one vendor does, but it is BEYOND LRM), you may want to try it out and give the SV-committee a real user feedback on the requirement.

Now a few nit-picky stuff, hope you don’t mind me saying them:

Hi,
For e.g. , in pre-OVM (pure SV) world , we may have done in the test code :

initial begin
//some other code
top.A.B.C.var.rand_mode(0);
top.A.B.C.var = 5; //overriden value
//some other code
end

This would have ensure that when somebody gave a call to randomize() for object C , var will be constrained to value 5.

Not really - basically var will be left in its initial value/prev value with no randomization done. You are simply assigning a value (not “constrained”).

Further, there are macros like `ovm_do which can be used to constrain the randomization, but they also work in sequence objects and not general purpose components (which are extensions of ovm_component), right ?
Thanks,
Ujjal

You need to be careful if you are doing “randomization” of ovm_component - I generally don’t recommend that. You are better off passing a config class containing the randomization and let your ovm_component “adopt” to the config chosen.

Good luck with your OVM journey!

Srini
www.cvcblr.com/blog

ujjal.bose · December 22, 2009, 10:36am

Thanks Dave and Srini for your replies.

I cannot use an ovm_sequence object for this as it is a configuration object (for which I was thinking of having such an override). So using `ovm_do* macros are not possible I think.

Normally configuration objects within an environment are static in nature and hence they are more suited as ovm_component (is what i thought). And many a times, you may want some randomization of some variable within a configuration object, but there has to be a way to disable/override the randomization from within a test. For e.g. :

class C;

rand bit var; //0 = 8 bit PCIE lane, 1 = 16bit PCIE lane

endclass

and if you have a C.randomize() call somewhere within your testbench sequencing, then every test will come up with a random value of “var”. But if you want some directed test to come up with 8bit configuration only, then you can :

potentially extend class C inside the test and then have a factory override in the test for that class. But this would mean redefining code for every such class (may be in class E,F,G etc.) where you need to constrain randomization, right.
Else, we can just have a call similar to set_config* and set the bit as well as disable randomization, and that would have ensured that even if somebody gave a call to C.randomize() from within the testbench sequence (which is not known to test writer) , “var” will still hold a value of 0. This will be just a one line code from user and will be neat too. For e.g.

function void end_of_elaboration();
  set_config_whatever(var,0); //arbitrary non-OVM code for illustration
endfunction

can be inside the test.

So, (2) really was my question, and looks like OVM does not support it directly as of now.

I am a new user to OVM, so any more comments/suggestions also welcome.

Now to the nit-picking :)

Not really - basically var will be left in its initial value/prev value with no randomization done. You are simply assigning a value (not “constrained”).

Well, as I explained above, this will be equivalent to overriding the randomization without rewriting constraints or using ‘randomize() with’ constructs. Remember that this “overide” is before somebody in testbench will give a call to C.randomize(). Only thing is that some care needs to be taken so as to select legal values for such an override. Whenever somebody in testbench does call the C.randomize(), constraint solver will correctly compute value of other variables based on this (overriden) value of “var”. Another way of achieving the same is to do this “override” in post_randomize, but then if I have multiple variables being overriden in test code at different places, it may not work.

And yes, i do remember the ACL validation times with you Srini :)

-Ujjal

sri.cvcblr · December 23, 2009, 4:24am

Ujjal,

Thanks Dave and Srini for your replies.
I cannot use an ovm_sequence object for this as it is a configuration object (for which I was thinking of having such an override). So using `ovm_do* macros are not possible I think.
Normally configuration objects within an environment are static in nature and hence they are more suited as ovm_component (is what i thought). And many a times, you may want some randomization of some variable within a configuration object, but there has to be a way to disable/override the randomization from within a test. For e.g. :

I would still use ovm_sequence_item/ovm_transaction/ovm_object than an ovm_component for config class. This is my 2 paisa addition to OVM/VMM - I fail to see good recommendation on clean way of handling configurations - or maybe I didn’t read through well enough. They are not as static (or what we call as pseudo-static) as the components/transactors are - such as Driver/monitor etc. There are designs requiring dynamic reconfigs (we had a very interesting work on this with a customer a while ago, got dropped in bet’n), config being reloaded from files etc. And config save-restore is another broad topic.

potentially extend class C inside the test and then have a factory override in the test for that class. But this would mean redefining code for every such class (may be in class E,F,G etc.) where you need to constrain randomization, right.

Correct, this is how it works with OOP. This is what I have a problem too - with lack of AOP style features - call it a different name if you don’t like AOP - say “in-place-extension”?

So, (2) really was my question, and looks like OVM does not support it directly as of now.
I am a new user to OVM, so any more comments/suggestions also welcome.

If you are brave enough to go beyond LRM (also understand the long term implications of it) and use VCS, you can get around it using SV-AOE features. I didn’t try it with OVM in VCS, but should work.

And yes, i do remember the ACL validation times with you Srini :)
-Ujjal

Glad you recall, and there we extensively used AOP to do such little tweaks in tests all the time - of-course we used E, it had almost AOP alone (with some flavor of OOP too). So if you are in need of getting things done at testcase level without reuse (throw away code, debugging something etc.) - explore AOP.

Srini
www.cvcblr.com/blog