I’m new to OVM but is there a way to access parameters in our DUT after elaberation of the module. We would like our Testbench to reconfigure based on the parameters used to compile the DUT.
Thanks,
Troy
I’m new to OVM but is there a way to access parameters in our DUT after elaberation of the module. We would like our Testbench to reconfigure based on the parameters used to compile the DUT.
Thanks,
Troy
This is kind of an open ended question, so I’ll give you an open ended answer: yes.
A lot will depend on how you structured your DUT parameter settings. The ideal way is to have a common package with all your parameters defined that can be used to override parameters in both your DUT and Testbench. You will have to do something like this for parameters that are needed at elaboration to specify buswidths. For other DUT settings that can be dynamically set in your testbench, you can use a hierarchical reference to the setting as an argument to set_config_int() from a module that represents your testbench.
By the way, I presented a paper at DVCon09 that discusses issues with parameters in testbenches that may be of interest. http://www.mentor.com/products/fv/techpubs/request/using-parameterized-classes-and-factories-the-yin-and-yang-of-object-oriented-verification-49111
Dave Rich
Dave, Here is basically what I’m trying to do. Sorry this is just psuedo code the best I can do from memory.
module DUT #(NUM_X) ( );
input [NUM_X-1:0] z;
endmodule
class env;
typedef someclass#(.NUM_X(NUM_X) someclass_t
someclass_t someclass_handle;
function build();
someclass_handle = someclass_t::type_id::create(“”,)
endfunction;
endclass;
I would like to (After Elaboration of the DUT) access DUT.NUM_X to get the parameter value and then use it or pass it into the class so that someclass can be configured correctly. I don’t have complete control of the DUT build/compile scripts but if I can get hold of the value later I can configure for it.
Thanks for you help
Hi,
Dave, Here is basically what I’m trying to do.
I would like to (After Elaboration of the DUT) access DUT.NUM_X to get the parameter value and then use it or pass it into the class so that someclass can be configured correctly. I don’t have complete control of the DUT build/compile scripts but if I can get hold of the value later I can configure for it.
Thanks for you help
I don’t see any issue with that - have you tried something like the following?
function build();
if (`PATH_TO_DUT.NUM_X_PARAM == 4)
// Build according to NUM_X==4
else
// Build it otherwise
endfunction
If you are also talking about DUT settings/configurations (not Verilog/SV parameter), then it is better to have a config_class with those settings, autho-generate them, program it to DUT etc.
HTH
Srini
www.cvcblr.com
Srini,
I think what you say is correct. However, I need the value before the build to put in the typedef someclass#(.NUM_X(NUM_X). Please see my earlier post.
Srini,
I think what you say is correct. However, I need the value before the build to put in the typedef someclass#(.NUM_X(NUM_X). Please see my earlier post.
Sorry I missed that earlier. AFAIK the answer is NO, not within single tool. We had a similar requirement several years back and a smart team member wrote a comprehensive PERL code to digest all our Verilog code, spit out a params.v file (took care of expressions for sure, I believe even parameter overrides too). Then we converted it to params.e and used it (back then we were using E). Now with CVER/ICARUS and other available free tools it may be easier to do similar thing. But you need some way to “prepend” to your build/make flow (scripts). I was maintaining the scripts for few projects and learnt the need for “callbacks/hooks” inside script the hard-way :o
Srini
www.cvcblr.com
Troy,
If your DUT is instantiated with parameters at the top level, then you can instantiate your testbench with the same parameters. For example
module top;
parameter NUMBER = 4;
DUT #(.NUM_X(NUMBER) (...);
TEST #(NUM_X(NUMBER)(...); // These are normally connected with an interface
endmodule
module TEST #(int NUM_X=0) (...);
import my_pkg::*;
my_env #(NUM_X) e; // could also use a factory override - see paper
initial begin
e = new();
e.run_test();
end
endmodule
If the parameters are buried in the DUT, what mechanism is there in your environment to modify them from a lower level?
Dave
Dave,
A rather ugly (In my opinion) defparam with a full path on the command line currently modifies the parameter. Our issue is complicated by the fact that the Top level of our DUT can not pass Parameter arguments because it has to be “OLD” style verilog for other tools in the tool chain. This forces us to reach down and change the param deep in the hierarchy.
Troy
Troy,
Although ugly, that’s good news you have access to the parameters from the command line or top level defparams. You’ll gust have to modify your scripts to provide the same parameter values through the top level of your testbench instance…
Dave