Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How to Force a generate block signal in System Verilog

Status
Not open for further replies.

rudra@123

Newbie level 3
Joined
Apr 16, 2012
Messages
3
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,309
Hi,
I want to force(in SV) FIFO data_in, which is a Generate block signal. If i force directly with hierarchy path as shown below it is reporting error as "no implicit hierarchy path..............."

force testbench.chiptop.genblk00000001.fifo_data_in=17'b1;
pls can any one find solution ......... help me
Thank u
 

According to the error, you need to check if your hierarchy path is correct. If you probe the signal to waveform and chose Path.Name instead of Name only, it will show you the full hierarchical path of that signal.
 

Did you name your generate block? You cannot use implicitly generated block names from within your source code.
 

According to the error, you need to check if your hierarchy path is correct. If you probe the signal to waveform and chose Path.Name instead of Name only, it will show you the full hierarchical path of that signal.

Hi
yes we probed the signal to waveform and that path only we are trying to force and also we named the generate block and used that name instead of implicitly generated name(genblk000001) , then also it showing "Hierarchical name component lookup failed"
 

force testbench.chiptop.genblk00000001.fifo_data_in=17'b1;

Usually, if the signal is multi-bit, in my waveform viewer, they have bits displayed. Could you try this

force testbench.chiptop.genblk00000001.fifo_data_in[16:0]=17'b1
 

Did you name your generate block? You cannot use implicitly generated block names from within your source code.

Hi
Ya we named Generate block as "mios_ch8" and we used it instead of implicit names, then also it showing "Hierarchical name component lookup failed at mios_ch8"

---------- Post added at 11:50 ---------- Previous post was at 11:45 ----------

Usually, if the signal is multi-bit, in my waveform viewer, they have bits displayed. Could you try this

force testbench.chiptop.genblk00000001.fifo_data_in[16:0]=17'b1

Hi
we tried as you suggested but it showing error with generate block ie "Hierarchical name component lookup failed at mios_ch8"
if we put "genblk0000001" instead of "mios_ch8" then it showing "Implicit name not allowed in hierarchical name, 'genblk0000001' "
 

From my experience, the path should be

testbench.chiptop.mios_ch8[1].instance_name.fido_data_in[16:0]

Thing to note here is, if you have generate block name, you will have to use both generate block name and the instance name used for that block instead of using just implicit block name.

Here is snippet from one of the design

generate
for(genvar g=0; g<CHANNELS; g++) begin: dut_generate
dut dut_inst0 ( ....);​
end​
endgenerate

Now if i have to refer to some signal inside the generate loop, then

top_tb.top.dut_generate[x].dut_inst0.signal_name
 
Hi all,

if I have a for loop in my test and am trying to force signals that reside inside modules instantiated with generate. So for the above example, force top_tb.top.dut_generate[0].dut_inst0.signal_name works but top_tb.top.dut_generate[index].dut_inst0.signal_name does not work. Basically I cannot use a variable while trying to access the hierarchy. Please let me know if there is a way to work around this. Right now I'm making it work by typing this out for each instance but there's lot of lines of code. A way to do this with a for loop would be cleaner..

Thanks in advance!
 

Try this
force testbench.chiptop.genblk00000001.fifo_data_in[16:0]=17'b00000000000000001

Should work.
 

hari_ceg,

That is correct, you cannot use a variable to reference what looks like an array index to the modules instantiated by a generate for/loop. Because each iteration through the loop could instantiate different modules overridden with different parameter values, it may not be a regular array with identical elements. Typically, you need another generate for/loop to access these instances from outside the for/loop that created them.

Code:
for(genvar g=0; g<CHANNELS; g++) begin
  initial wait(for_some_signal) force top_tb.top.dut_generate[g].dut_inst0.signal_name = 0;
end

If you can use SystemVerilog, there are elegant ways to put "handles" to each instance in an array, and then access each handle individually with a variable index. If you are interested, see my DVCon paper for an example of accessing arbitrary instances via class objects or virtual interface handles. **broken link removed**
 
Hi Dave,

Thanks a lot for the reply as well as the pointer to the paper. I can use system verilog for my case though I'm no expert and have not used it extensively. The paper was very informative - I was not aware about abstract classes and how with interfaces they could be used for RTL probing.

I have basic/dumb question about the example in your paper . Please bear with my limited knowledge on this front.

InternalBus is driven inside the RTL based on CS && WE. Then you have the bind with the interface to control the same signal. The set_probe tries to set InternalBus to a specific value from the test bench - does this override the rtl logic of CS&&!WE? I know your test bench only forces when WE=1 but what if I wanted to just force InternalBus to some value irrespective of CS/WE? I guess I'm trying to ask if the bind plus set_probe is equivalent to a force? If not, wouldn't it be a multiple driver kind of case?

For my case, I am trying to force an array inside a RTL signal with hierarchy top_tb.dut.submod_generate[g].submod_inst.sig_name[0][31:0]. Would the method described in the example work for this ? I guess I am still unable to visualize how the force/release would take effect.

Thanks again!
 

The set_probe() works by setting Wdata_reg which is then driven onto the InternalBus via the continuous assign WData = Wdata_reg; statement. The bind statement effectively creates another driver on the bus. If you want to force InternalBus, you will need to create additional methods to force/release Wdata. I generally avoid using force/release statements except as a last resort.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top