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  

Sequence Layering in UVM

What is Sequence Layering? Sequence layering is refered to as running sequences inside sequences.  So whats the big deal. There are virtual sequences we will use to run multiple sequences. A generic example of sequence layering. you have two sequences  Interrupt sequence register read write sequence. Generally when you have interrupt, we generally enter into interrupt service routine, which can be implemented as an interrupt sequence. So when you run an interrupt sequence, you might end up running register read /write sequence like polling or clearing interrupts. Well thats easy, just run one sequence in another. class top_seq extends uvm_sequence#(txn_item); //Two sequencers say.. sub sequences. sub_seq1 seq1; sub_seq2 seq2; ... task body(); seq1.start(some_seqr); seq2.start(some_seqr2); endtask endclass Killing sequences: That was great you are running nested sequences. But how to kill them when needed. UVM provides method cal

SystemVerilog: Mailboxes and Queues

Mailboxes and queues are couple of basic data constructs of system verilog language. Lets get to the definition of them: Queue: A Queue in system verilog function as the name suggests. But with a twist. Queue in system verilog is a list of similar elements. Queue is built on top of an array. Delcaration of a queue. < TYPE > < que_name >[ $ ]; Default Behaviour: The default size of the queue in system verilog is " Infinite ". The above declaration will create a que of infinite length. You can add elements to the que until your simulator crashes :) What if you want to create a queue of finite length. Just look at the declaration below: < TYPE > < que_name >[ $ :< LIMIT >]; The above declaration will create a queue of size " LIMIT+1 " Initializing queue with elements Accessing elements of a queue Methods in queue Inserting elements into queue Reoving elements from queue http://www.project-veripage.com/queue_1.ph