UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
14,850 Views
Registered: ‎11-28-2011

BRAM output delay

Jump to solution

Probably a newbie question, but why is it that when I present an address to the true dual port ram does the output appear at the expected clock cycle plus 100ps?  see attached timing diagram, which shows a read latency of 2 clock cycles plus the small 100ps delay after the rising edge of clkb

 

This is totally messing me up because I want to sample the output of the RAM on the rising edge of the CLKB clock.  but the data changes slightly after that. 

 

I even tried to add an output register

 

I'm running ISE 14.6 (BRAM Gen 7.3) and using VCS MX H-2013.06-SP1-1. My `timescale is set to 1ns/1ps 

My aspect ratio is Port A Wr 32/Rd 32,   Port B Wr32, Rd 16

 

 

bramread.jpg
0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
23,623 Views
Registered: ‎02-06-2013

Re: BRAM output delay

Jump to solution

Hi

 

Have a look at the below link

 

http://forums.xilinx.com/t5/Simulation-and-Verification/100-ps-delay-for-Block-Memory-Generator-6-3/td-p/219073

Regards,

Satish

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
5 Replies
Xilinx Employee
Xilinx Employee
23,624 Views
Registered: ‎02-06-2013

Re: BRAM output delay

Jump to solution

Hi

 

Have a look at the below link

 

http://forums.xilinx.com/t5/Simulation-and-Verification/100-ps-delay-for-Block-Memory-Generator-6-3/td-p/219073

Regards,

Satish

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
Historian
Historian
14,834 Views
Registered: ‎02-25-2008

Re: BRAM output delay

Jump to solution

@polyee13 wrote:

Probably a newbie question, but why is it that when I present an address to the true dual port ram does the output appear at the expected clock cycle plus 100ps?  see attached timing diagram, which shows a read latency of 2 clock cycles plus the small 100ps delay after the rising edge of clkb

 

This is totally messing me up because I want to sample the output of the RAM on the rising edge of the CLKB clock.  but the data changes slightly after that.  

 


This 100 ps delay is an attempt to model the memory's actual clock-to-out time (if the output is registered) or its access time (if it's not). Even if it wasn't there, you'd still be "totally messed up" because the clock-to-out time would shrink to a delta, and then you'd be REALLY confused.

 

Recall how synchronous logic works. For starters, let's assume that the output isn't registered. On a clock edge, your address is captured. (Note that the address has to be valid a setup time BEFORE the clock edge.) The address is decoded in the memory and when the decode completes the result is driven out. Obviously there is some delay associated with the decoding and output driving. This means that, as you should expect, if you drive an address which is captured on clock tick T0, the resulting data will be valid to be clocked in on the next clock T1. You can't clock the output data into the next bit of logic on the same clock edge as its address is captured.

 

Extend this to a pipeline. Now, I'm not sure which BRAM has a latency of two clocks, but if you enable the output register, you add one clock plus the register's clock to out time to the read operation. On T0 you register your address and the array read starts. On T1 the output register clocks in the value read from the array; a clock-to-out time later the output register data are valid. You will then clock the register's output into the following logic on clock edge T2.

 

Now, about clock-to-out time. All synchronous logic has it. In a bus-functional model, you don't care about the actual clock frequency or the actual clock-to-out time, but it has to be there, so there's the notion of a "delta" (or infinitesmal) time delay. It's there to ensure that when you clock something into a register on time T0, that register's output will be available to be latched into the next flop on T1, not T0. (Delta time is also used to account for the combinatorial logic between registers.)

 

Back to the 100 ps. I assume that you're instantiating a BRAM from the library and not inferring it; if you were to infer it, the 100 ps wouldn't be there. BUT THE DELTA DELAY WOULD BE. The reason they add the delay is so that the clock-to-out delay is "obvious." Once you fully understand the implications of delta delays, you won't want to see the 100 ps delay (which is arbitrary).

 

Does this make sense?

----------------------------Yes, I do this for a living.
Xilinx Employee
Xilinx Employee
14,777 Views
Registered: ‎08-01-2008

Re: BRAM output delay

Jump to solution
100 ps delay coming from unsim library which modeled initial delay after the FPGA configuration.
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Explorer
Explorer
14,772 Views
Registered: ‎11-28-2011

Re: BRAM output delay

Jump to solution

The think the clk-out makes sense. But in hardware I'm not getting the same results as in simulation.  It was mentioned that the address is applied and then the data is available 1 clock later. I agree with this however it's 1 clock later plus 100ps. Therefore I have to sample the data two clocks later. I tend not to agree with this because then the sample clock is kind of on the hairy edge, meaning if it's off by 100ps then I get the wrong data.  Could this be happening in hardware? 

bram_read2.png
0 Kudos
Historian
Historian
14,673 Views
Registered: ‎02-25-2008

Re: BRAM output delay

Jump to solution

@polyee13 wrote:

The think the clk-out makes sense. But in hardware I'm not getting the same results as in simulation.  It was mentioned that the address is applied and then the data is available 1 clock later. I agree with this however it's 1 clock later plus 100ps. Therefore I have to sample the data two clocks later. I tend not to agree with this because then the sample clock is kind of on the hairy edge, meaning if it's off by 100ps then I get the wrong data.  Could this be happening in hardware? 


You're missing the point. The 100 ps delay just makes the delta delay "visible" in the simulation waveform.

On clock edge A the address is captured and the memory is read, and some short (and in simulation, this is a delta) time later, the memory output is driven. If there is no output register, you sample the memory read data on clock edge B. If there is an output register, it samples the memory array output on clock edge B and its output changes a delta time later to that memory read value. You capture the memory register's output on clock edge C.

 

That the simulation model puts a 100 ps delay in is not relevant. The timing I describe above remains the same.

 

----------------------------Yes, I do this for a living.
0 Kudos