cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
14,490 Views
Registered: ‎05-17-2013

Block RAM latency is 10 clocks in simulation, should be 1 clock

Jump to solution

In simulations I am seeing the Block RAMs take 10 clock cycles to return data. I am using Vivado 2013.2 with a Kintex-7 and Block RAM generator 8.0. The IP Catalog output claims that the latency should be 1 cycle. The attached waveform is the 10 cycle latency we see in simulations. I haven't probed the signals within the FPGA with the ILA yet but I am seeing an identical failure from simulation on the output of the FPGA where we send out the wrong data due to the slow timing.

 

I saw an almost identical post way back in 2009 but the previous poster's resolution doesn't fix the behavior I'm seeing. The previous poster had mistakenly set the clock period to 10ps instead of 10ns, but as you can see in this waveform I have 10ns clock periods.

http://forums.xilinx.com/t5/Virtex-Family-FPGAs/BRAM-read-latency-too-long/td-p/31126 )

 

 Any ideas?

block_ram_latency.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Professor
Professor
23,438 Views
Registered: ‎08-14-2007

All of the memory models I've seen for Xilinx have 1 ps / 1 ps timescale, so overriding it with 1 ns / 1 ps

would do exactly what you see.  The models include either a 100 ps (read 100 time units) # delay, or

a 100 ps specify block.  Either way, changing the timescale to 1 ns / 1 ps will cause these to become

100 ns instead.  If you globally change the timescape to 1 ps / 1 ps, then you need to change the

clock in your test bench to change state every 5000 ps instead of every 5 ns.

-- Gabor

View solution in original post

5 Replies
Highlighted
Professor
Professor
14,447 Views
Registered: ‎08-14-2007

Are you doing this in VHDL or Verilog?  I'm wondering if this is using a Verilog simulation

model that is possibly missing a timescale directive?  Theoretically a purely behavioral

model with no time delays in it would work at any clock frequency and show the same

results.  Given that the old thread showed that a 10 ps clock cycle made the latency

appear to be too long, I'm wondering if the Vivado model has time delays in picoseconds,

but without a timescale directive they become nanoseconds due to the inherited timescale

from some other module.  If you were using ModelSim you would get a warning about this.

-- Gabor
0 Kudos
Highlighted
Visitor
Visitor
14,440 Views
Registered: ‎05-17-2013

I am using Verilog and instantiating the memories using the BRAM_xxx_MACROs. I've previously tried using Vivado's IP Catalog, "create_ip" from TCL, and the blk_mem_gen_v8_0 simulation model. They all give the 10 clock cycle latency result. 

http://forums.xilinx.com/t5/Design-Entry/Instantiating-block-RAMs-from-within-Verilog/td-p/336759

 

I checked further into the timescale. I'm simulating with Cadence NC-Verilog and am overriding the timescale globally:

+ncoverride_timescale +nctimescale+1ns/1ps

 

There aren't any warnings related to time in the simulation logs, just the fact that the override has been set.

 

There are a lot of different memories in this design and they all have the same timing issue. When I turn on the output register (with DO_REG(1)) then the latency goes to 11 clock cycles.

 

0 Kudos
Highlighted
Visitor
Visitor
14,439 Views
Registered: ‎05-17-2013

I also tried 1/ns/1ns, and 1ps/1ps, and the result is always the same. The latency is 10 clock cycles, even when the clock period is 10ps.

 

ram_latency_ps.png
0 Kudos
Highlighted
Professor
Professor
23,439 Views
Registered: ‎08-14-2007

All of the memory models I've seen for Xilinx have 1 ps / 1 ps timescale, so overriding it with 1 ns / 1 ps

would do exactly what you see.  The models include either a 100 ps (read 100 time units) # delay, or

a 100 ps specify block.  Either way, changing the timescale to 1 ns / 1 ps will cause these to become

100 ns instead.  If you globally change the timescape to 1 ps / 1 ps, then you need to change the

clock in your test bench to change state every 5000 ps instead of every 5 ns.

-- Gabor

View solution in original post

Highlighted
Visitor
Visitor
14,423 Views
Registered: ‎05-17-2013

Unfortunately our simulation environment needed quite a bit of hacking to get to this point, but I can confirm that you are correct Gabor. I now have single cycle memory read latency. Now I just have to put our environment back together!

 

Thank you (again)!

Dave

0 Kudos