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: 
Adventurer
Adventurer
9,833 Views
Registered: ‎11-07-2007

100 ps delay for Block Memory Generator 6.3

Jump to solution

hi, I'm seeing a 100 ps delay between the rising edge of the clock and the output of the block memory.

 

the block ram is configured as a simple dual port ram.  the clock speed is 160 mhz.  it is a behavioral simulation in ISIM. 

 

why is my output not aligned with the clock?  I've even tried adding a pipeline stage from the core generator and there is still a 100 ps delay. 

 

does anyone else have this problem?  what can I do?

0 Kudos
1 Solution

Accepted Solutions
Observer joryte
Observer
12,778 Views
Registered: ‎09-21-2011

Re: 100 ps delay for Block Memory Generator 6.3

Jump to solution

If you are using a block ram primitive in your design instead of inferring block ram, then it is very feasible the simulation model for the primitive includes a signal assignment delay.  100 ps does not sound too unreasonable for such a delay.  If your design is going to work in hardware, it should never assume that synchronous data is available instantaneously with the active clock edge.

 

If you assert the enable on the active clock edge, the block ram model will read the asserted value on the next active clock edge (1 clock).  Some delta after that (100 ps), the data has propogated through the logic delays and is valid at the output to be read on the following clock active edge.  Thus, since the block ram is synchronous, and if your enable assertion is synchronous, you should not attempt to read the data until at least 1 clock period + delta after asserting the enable and not more than 2 clock periods - delta.

 

If you are dealing with phase alignment between clock and data on output ports, it is useful to work on the opposite polarity of the clock from the circuit.  If this data synchronization error is internal to the FPGA, then the issue is probably that you are not allowing the necessary latency of the BRAM (1 delta after the active edge of the clock on which the enable has been asserted).  In other words, the data will not be valid until the 2nd clock cycle after you assert enable.  Try reading the data on the next active clock cycle.

 

 

Good luck,

JoRyTe

0 Kudos
6 Replies
Teacher eteam00
Teacher
9,832 Views
Registered: ‎07-21-2009

Re: 100 ps delay for Block Memory Generator 6.3

Jump to solution

In what context are you seeing this 100pS delay?  Logic simulators are not timing simulators.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Adventurer
Adventurer
9,830 Views
Registered: ‎11-07-2007

Re: 100 ps delay for Block Memory Generator 6.3

Jump to solution

the output of a block ram is supposed to occur 1 clock after the enable is asserted.  Instead, I'm seeing it occur (1 clock + 100 ps) in my behavioral simulation in ISIM.  This causes an error in my design because the 100 ps delay is causing the wrong data to be read. 

 

I hope this clearly describes my problem.

0 Kudos
Observer joryte
Observer
12,779 Views
Registered: ‎09-21-2011

Re: 100 ps delay for Block Memory Generator 6.3

Jump to solution

If you are using a block ram primitive in your design instead of inferring block ram, then it is very feasible the simulation model for the primitive includes a signal assignment delay.  100 ps does not sound too unreasonable for such a delay.  If your design is going to work in hardware, it should never assume that synchronous data is available instantaneously with the active clock edge.

 

If you assert the enable on the active clock edge, the block ram model will read the asserted value on the next active clock edge (1 clock).  Some delta after that (100 ps), the data has propogated through the logic delays and is valid at the output to be read on the following clock active edge.  Thus, since the block ram is synchronous, and if your enable assertion is synchronous, you should not attempt to read the data until at least 1 clock period + delta after asserting the enable and not more than 2 clock periods - delta.

 

If you are dealing with phase alignment between clock and data on output ports, it is useful to work on the opposite polarity of the clock from the circuit.  If this data synchronization error is internal to the FPGA, then the issue is probably that you are not allowing the necessary latency of the BRAM (1 delta after the active edge of the clock on which the enable has been asserted).  In other words, the data will not be valid until the 2nd clock cycle after you assert enable.  Try reading the data on the next active clock cycle.

 

 

Good luck,

JoRyTe

0 Kudos
Adventurer
Adventurer
9,822 Views
Registered: ‎11-07-2007

Re: 100 ps delay for Block Memory Generator 6.3

Jump to solution

thanks joryte.  Is this a new behavior?  I've been using simulators for several years and I've always seen the output data ready on the rising edge 1 clock from the enable when using block rams.  

0 Kudos
Observer joryte
Observer
9,819 Views
Registered: ‎09-21-2011

Re: 100 ps delay for Block Memory Generator 6.3

Jump to solution
I don't know if the latency of the block ram models has changed. I always infer block rams instead of instantiating them. However, it is not new for ISim to treat signals assigned on an active clock edge as being a delta after the clock edge, causing the block ram not to read your asserted enable until the following active clock edge. However, even with synchronous assignments ISim will not show a measurable delay between the clock and the data transition unless a delay is specifically stated in the signal assignment. If you don't specifically delay the assignment, they will look like they occurred instantaneously, but they don't. I have seen delayed signal assignments in many Xilinx simulation models, so this would not surprise me at all.


JoRyTe
0 Kudos
Highlighted
Historian
Historian
9,812 Views
Registered: ‎02-25-2008

Re: 100 ps delay for Block Memory Generator 6.3

Jump to solution

@mvalvo wrote:

thanks joryte.  Is this a new behavior?  I've been using simulators for several years and I've always seen the output data ready on the rising edge 1 clock from the enable when using block rams.  


The 100 ps delay is there just to make clear the clock-to-out delay inherent in all flip-flop models. It is for simulation convenience. I will argue that it's not only not necessary, it sows confusion. (Hence your post.)

 

Without that explicit delay, you'll still have the simulation delta delay, which looks like the output changes simultaneously with the clock edge, but in fact it changes ever so slightly afterwards. In a functional simulation, the two delays are effectively irrelevant.

 

Consider a 100 MHz clock (10 ns period). With the explicit 100 ps delay, the input is set up to the next edge of the clock by 9900 ps. Without that delay, the input is set up to the next edge of the clock by 10 ns minus a delta. So if you are expecting to use the output of the memory on this clock instead of the next clock, then you should recalibrate your expectations.

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