Skip to main content

VCS dynamic reconfiguration of modules

Test Case

In this test case, the top-level module named top instantiates a module named test twice with the instance names test_inst and test_inst1. This source file also has a substitute module named test_sbst as shown in the following code:
// basic.v
 
module test(input bit bm,logic  lm,output bit bto,logic lto);
endmodule
 
module top();
bit bt,bto,bt1;
logic lt,lto,lt1;
test test_inst( .bm(bt),.lm(lt),.bto(bto),.lto(lto));
test test_inst1( .bm(bt1),.lm(lt1),.bto(bto1),.lto(lto1));
endmodule
 
module test_sbst(input bit bm,logic lm,
                 output bit bto,logic lto);
endmodule
 
Figure 23-2 Test Case
The compile-time configuration file lists the modules whose instances you might replace along with their corresponding substitute modules.
In this test case, the compile-time configuration file is named as config.txt:
//config.txt
 
replace module {test} with module {test_sbst};
 
This configuration file specifies the possible replacement of an instance of module test with an instance of module test_sbst.
The compile-time command-line is as follows:
% vcs basic.v +optconfigfile+config.txt
 
VCS MX displays the following information message from dynamic reconfiguration:
DYNAMIC RECONFIG> Replacing test With test_sbst Enabled
 
You have enabled replacing instances of module test with instances of module test_sbst at runtime.
So at runtime, you must first write another configuration file specifying, by hierarchical name, the module instances you want to replace. In this test case, the configuration file is named as runconfig.txt:
//runconfig.txt
 
top.test_inst
 
This configuration file specifies that you want the module instance with the hierarchical name top.test_inst to be replaced. The other instance of module test, with the hierarchical name top.test_inst1, is not replaced.
Figure 23-3 Diagram of the Dynamically Reconfigured Test Case
The runtime command-line for this dynamic reconfiguration is as follows:
% simv -dynaconfig runconfig.txt
 
Before simulation, VCS MX replaces this instance with an instance of the substitute module specified in the compile-time configuration file, an instance of module test_sbst.
Also, before the simulation, VCS MX displays the following information message:
DYNAMIC RECONFIG: Instance top.test_inst is replaced with module (test_sbst)
 

Comments

Popular posts from this blog

Verdi Uses - I

COVERAGE While going through some of the blog posts, i found that the Verdi supports even coverage right out of the box, but from the 2014 Version. Well till now, we relied on the URG reports and the DVE to review the coverage and apply waivers and create exclusion files. Looks verdi supports all the features.. I did not get any hands on the features of this option, soon i will find some time to play around with this option of coverage in Verdi. How to launch the verdi with coverage. $> verdi -cov -covdir <PATH_TO_TB>.simv.vdb -covdir <PATH_TO_TEST1>.simv.vdb -covdir <PATH_TO_TEST2>.simv.vdb...  You can pass multiple covdirs, where in all the results will be merged. References: SYNOPSYS SITE Think Verification  

Virtual Sequence and Virtual Sequencer in UVM

Virtual sequences and sequencers in UVM are just virtual containers of multiple sequences and sequencers. Using virtual sequencers and sequences can be done in these three ways: Using only virtual Sequence and handles of sequencers inside the virtual sequence. Using Virtual sequencer to hold the sequencers Same as step 2, by using uvm_declare_p_sequencer. Virtual Sequencer does not create any sequencer objects, rather it points to other physical sequencers in different agents.  Virtual Sequencer extends from uvm_sequencer. Virtual sequence will create its sequences and start them. Running sequences can be controlled by user in the body() task. virtual sequence extends from uvm_sequence. METHOD-1: In this method, we will have one base virtual sequence which will hold the handles to different sequencers. Here we dont use any virtual sequencer. We just use the nested seqeunces with handles ot sequencers inside sequence itself. //This is the base virtual se...

Good uses of System Verilog DPI..

What is DPI?? Well, The easiest answer is Direct Programming Interface. The DPI is used to communicate the system verilog/ Verilog code to any other language. Well DPI has its own advantages over PLI.  You can check out the differences between the DPI and PLI   HERE . With DPI, you can directly call the c-functions from system verilog code and vice versa. With lot of SOCs and complicated chips in the silicon industry, sometimes you cannot completely live with the generic UVM/System verilog to write complete stimulus for complete chip.  Basics of DPI, Basics of DPI can be found when you google it.  There are some interesting cases where you will find the uses of DPI. I will get through some advanced take aways from IEEE 1800.2012 LRM. You cannot export the objects with in class. You can export only from static objects. exporting the tasks/functions should be in a module/program/interface scope.[or any static scope] . ..... Bear with me as th...