Skip to main content

VCS dynamic reconfiguration for pre-compiled IPs

VCS® MX/VCS® MXi™ LCA Features Guide > Dynamic Reconfiguration at Runtime > Pre-compiled IP Use Model with Dynamic Reconfiguration at Runtime > Test Case

Test Case

In this test case, the top-level module named top instantiates a module named test with the instance names inst_test and a module another module named dut with the instance name inst_dut. The module dut which instantiates twice a module named pe_main with the instance names inst_pe_main1 and inst_pe_man2. This source file also has a substitute module named pe_sub as shown in the following code:
//basic.v
module pe_main;
bit b;
logic l;
endmodule
 
module dut;
pe_main inst_pe_main1();
pe_main inst_pe_main2();
bit out;
endmodule
 
module top;
dut inst_dut();
test inst_test();
endmodule
 
 
module test;
initial begin
#10 top.inst_dut.inst_pe_main1.b=1'b1;
#10 top.inst_dut.inst_pe_main2.l=1'b1;
#100 $finish();
end
endmodule
 
module pe_sub;
endmodule
 
Figure 23-4 Test Case
In this test case, the compile-time configuration file is named config.txt:
//config.txt
replace module {pe_main} with module {pe_sub};
 
This configuration file specifies the possible replacement of an instance of module pe_main with an instance of module pe_sub.
The compile-time command lines are as follows:
% vlogan –sverilog basic.v –work lib1
% vcs –genip lib1.dut -allxmrs +optconfigfile+config.txt
% vcs –integ lib1.top -allxmrs +optconfigfile+config.txt
 
VCS MX displays the following information message from dynamic reconfiguration:
DYNAMIC RECONFIG> Replacing tpe_main With pe_sub Enabled
 
At runtime, write another configuration file by specifying the hierarchical name and the module instances that you want to replace. In this test case, the configuration file is named runconfig.txtas shown:
//runconfig.txt
top.inst_dut.inst_pe_main2
 
This configuration file specifies that you want the module instance with the hierarchical name to be top.inst_dut.inst_pe_main2 replaced. The other instance of module pe_main, with the hierarchical name top.inst_dut.inst_pe_main1 is not replaced.
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 simulation VCS MX displays the following information message:
DYNAMIC RECONFIG: Instance top.inst_dut.inst_pe_main2 is replaced with module (pe_sub)

Comments

Post a Comment

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  
Post a Comment
Read more

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 m...
2 comments
Read more

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...
1 comment
Read more