开发者

Accessing Verilog genvar generated instances in simulation code

开发者 https://www.devze.com 2023-04-03 03:08 出处:网络
This is a Verilog releated question. I am working with XILINX ISE as a dev environment. I am trying to access variables in the simulation that are automatically generated using genvar but I am receiv

This is a Verilog releated question. I am working with XILINX ISE as a dev environment.

I am trying to access variables in the simulation that are automatically generated using genvar but I am receiving the following error -> HDLCompiler:71

Problem Example:

genvar i;

generate

for(i=0; i < N; i=i+1)

begin:Sys_Modules

  TypeXModule #(.width(10)) xmod(.dataY(dataY)));

end

endgenerate 

When I ran synthesis or simulation I can see that Sys_Modules[0..N-1].xmod instances are created.

When I try to add a line to the simulation accessing the Sys_Modules array:

Sys_Modules[i].xmod.dataY

I get the following error:

HDLCompiler:71 dataY is not declared under prefix xmod

Is there any way to access a开发者_JS百科utomatically generated values in the simulation?

Thanks!


You cannot use cross-instance hierarchical references in synthesized Verilog.


It is legal to write a hierarchical reference to a generated instance. The functionality is described in sections 2.7.2 and 12.1.3 of the IEEE Verilog standard. However, the instance subscript must be a constant so that it can be resolved at compile time.


I think you're out of luck. Simulators don't seem to like out-of-module references (OOMRs) pointing into generated blocks as you've discovered.

I encountered a similar problem recently when making a parameterizable testbench monitor. I'd a variable number of sub-blocks instantiated depending on a parameter. Within this, I needed to have a toplevel .start() task that called the .start() tasks in each of the instantiated modules. I couldn't use a for loop to do this because of this OOMR problem.

So I ended up having to:

  • define a reg that the toplevel .start() task toggled
  • write an always @ block triggered on this reg
  • write another generate section within this always block to call .start() on each of the sub-modules.

If you really need to peek into your generated modules, maybe you could try a workaround like above? For instance, have a bus at the toplevel, and use agenerate statement to peek inside your original generated instantiations to copy/assign interesting signals on to this toplevel bus.


I have found and used another solution, posting it here in case someone will find it useful. Worked for me in Vivado 2020.

Steps:

  1. in tb: declare all data you need to print (declare wires)

    ex:for Sys_Modules[0..N-1], wanting Sys_Modules[i].xmod.dataY =>

    tb: wire [0:N-1][`DATA_SIZE-1:0] tb_Sys_Modules_dataY;

  2. generate all connections using a generate block

    ex: (N should be a define/parameter)

    for(i = 0 ; i < N ;i = i + 1) assign tb_Sys_Modules_dataY[i] = Sys_Modules[i].xmod.dataY;

  3. $display wire from tb:

    ex:

    $display("%d",tb_Sys_Modules_dataY[i]);

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号