[SOLVED] Distributed RAM from coregen not cycle accurate?

[capitan]

Hello everyone!

I'm having a problem with the behavioral simulation of a single port distributed ram component in isim. It appears that the output of the ram is not clock accurate, but comes 100ps after the clk rising edge . The thing that confuses me is that the output is registered...

I'm using Xilinx 12.1 along with isim. Possibly a tool bug?

**broken link removed**

ps: please ignore all the other signals. Only clk and everything under nnet_mem1 are relevant

 

[FvM]

I guess, a transport delay is built-in to the simulation model, you can check the source. What's your problem with it? The actual hardware delay will be considerable larger.

 

[capitan]

Not a problem exactly... it introduces glitches because my brams don't have such a delay so the two memories are a bit off-sync. Synchronous multipliers and other components also propagate this delay (although somehow they do the right computations even though their inputs are a little screwed due to the delay).

I was under the impression that behavioral model doesn't include this kind of delays, only cycle-scale latencies...

 

[FvM]

I was under the impression that behavioral model doesn't include this kind of delays, only cycle-scale latencies...

The delta cycle may be 1 ps, depending on the simulator settings. No gate level delays are considered, but each behavioral model can introduce arbitrary delays, also a testbench often does for external signals. I only guessed, that it's in the RAM model, but I don't have another plausible explanation.

 

[permute]

it could also be in the code. If the same model is used for the sync and async case. There is an issue if you have an internal "rd_clk <= clk" assignment. This is because events for clk are evaluated fully before events for rclk are evaluated. Thus if some elements (like registering the address) are updated by clk, and other elements (like registering the output) are updated by rclk, BOTH will occur on the same clock edge. clk causes the address to be registered and rclk to rise concurrently. the events for rclk now use the updated address register to resolve the value for the output register. Its possible the node in question is delayed a small amount to avoid this issue in a different use case.

 

[capitan]

I have one global clk signal in my design, no gated clocks or clock assignments.

@ Fvm:
indeed you were right. In the simulation model I found

-- Register delay
CONSTANT C_TCQ : time := 100 ps;

and

qspo_int <= spo_int after C_TCQ;

So the delay comes from there. Thanks for your help