Hi all,
I want to accelerate my simulation, so I try to shut down some useless modules(instances) in DUT during the simulation. Usually, I force the clock signal to be inactive.
However, this method will not work when all modules share the same clock, beacuse the modules that are necessary will also be shut down.
Also, I have other choices like controlling compilation with macros or substituting an useless module with an empity module. These methods are not very convenient to manage testbenches because we need to modify DUT sources or create many empty modules.
Please tell me if there is any better method, thanks!
You may want to look at Verilog configurations using the config construct. You can use different definitions of the same module and choose a specific definition for a particular instance. You can also choose a specific definition for all instances (same as if there is only one instance) of a module. You may use your tool’s library mechanism as well by compiling different definitions into separate libraries, and then selecting the library you want to use for a particular test.
In any of the cases above, you still need to create empty module definitions, but you will not have to modify the existing RTL source code.
In reply to dave_59:
Hi Dave,
Can you help understand more about this?
“You may want to look at Verilog configurations using the config construct”.
Is verilog configuration a way to implement the multiple modules (default/limited functionality/dummy etc) concept you specified above?
Or, is this config construct approach a completely different one?
A pointer to a paper/example would be of help to understand this completely.
Currently, to implement the multiple module concept we use different compile time switches based on which we select different files in the filelist?
Thanks,
Rajkumar.
In reply to S.P.Rajkumar.V:
I’m talking about Section 33. Configuring the contents of a design of the 1800-2012 LRM. This is actually a Verilog-2001 construct. Unfortunately, I haven’t been able to find any examples with any more detail than what is already in the LRM; Config is so heavily used by the UVM that it is hindering my search.
As far as tool flows are concerned, this requires a multi-step flow. This is where you compile modules into a separate design libraries, and compiling into each library requires a separate step, and then another step to elaborate the design for simulation. You will need to look in your tools User Manual for Verilog compilation flows, but you should contact your vendor for more specific help.
In reply to dave_59:
Thank you. I shall go through the same to understand further.
In reply to S.P.Rajkumar.V:
Thanks Dave! is there any way to force the clock of a particular instance without interfering other instances?
In reply to Wanglj:
Yes, you can control the clock directly at the instance level from do file that is passed to the vsim command (ex: vsim top -do dofile.do)
force top.dut.i1.a1.clk = 1’b0 -time “”
(I don’t remember the exact syntax though. And I assume you are using Questasim.)
You can use the verilog force/release as well to achieve the same from your TB.
In reply to S.P.Rajkumar.V:
Thanks S.P.Rajkumar.V!
But when I force the clock of a module, modules which share the same clock will not work either.
In reply to Wanglj:
Don’t force the clock at the common point, instead force it at the particular instance level right.
i.e., in the above example let us say there are two instances a1, a2 under top.dut.i1
And, assume top.dut.i1.clk is going to both a1, a2 directly.
Now, you force the clock at top.dut.i1.a1.clk so that instance top.dut.i1.a2 clock (clk) wouldn’t get effected.
You will face a problem only if you force the clock at top.dut.i1.clk directly.
In reply to S.P.Rajkumar.V:
Hi S.P.Rajkumar.V,
I have tried your method both in verilog and GUI, both cases show that forcing clock in one module will affect clock in the other module. Can you tell me which tool you are using, I am using Questasim.
In reply to Wanglj:
Hello Wanglj,
I have forced clock and other signals before, but I have not got a change to notice how the other module instances got impacted because of this. Right now, I don’t have access to Questa to try this.
You are saying that forcing top.dut.i1.a1.clk is effecting top.dut.i1.a2.clk as well? Correct?
It can happen if your RTL is something like below, as all the instances clocks(i1.a1.clk, i1.a2.clk) are directly connected to the top clock (i1.clk) during instantiation. So, forcing i1.a1.clk would force i1.clk and inturn forces i1.a2.clk.
Hope that’s your case and as per my analysis thats the correct behavior.
module i1 (clk, in, out);
input clk;
…
…
…
wire in_a, in_b;
…
a1 a1(.clk(clk), in(in_a),…);
a2 a2(.clk(clk), in(in_b),…);
…
endmodule
In reply to S.P.Rajkumar.V:
If you use variables for ports, then SystemVerilog respects the specified port direction and a force on an input port will not affect the higher level signal it is connected to. Similarly, the lower level output port variable will not be affected by a force on the higher level signal it is connected to.
module moda(input var logic clk, ...);
If you are stuck in Verilog, then you will have to create a clock buffer tree to isolate the clocks feeding the individual modules.
In reply to dave_59:
Thanks Dave!
Does ‘var’ affect synthesis? If it doesn’t, I can modify my DUT source.
In reply to Wanglj:
var declarations should not effect synthesis as long as tools support that SV syntax.
In reply to dave_59:
Thanks Dave, really a good idea!