Output IO Buff is too large; DDR3

Question

Hello,

I downloaded and ran the altdq_dqs example from Altera literature webside.

The example claimed these IO BUFFs could handle up to 333.333 MHz (3ns), but I found that their output BUFFs, IOOBUFFs, delay time is very large (2.1ns).

I tried to set D5 and D6 to 0, maximum current drive, but not improve.

Are there otherway to reduce this large delay?

I am planning to use the fastest Stratix FPGA for my 400 MHz - DDR3 project. Are there any thing faster than Stratix iii speed 2?

altera_forum · Answer

Are you sending a source-synchronous clock and doing timing analysis? The buffer delay time shouldn't matter(and 2.1 is actually very fast), as you'd never meet timing just sending data. DDR3 sends a clock alongside the data. Since the clock will have a similar 2.1ns output buffer delay, they "cancel out" and it's really the skew between the two interfaces you need to be concerned about.

For the record, building a DDR3 interface from the basic components is probably a pretty large undertaking.

altera_forum · Answer

thanks Rysc.

I got your point. Since I only design a simple DDR3 interface; therfore, I have to avoid using the DDR3-Phy IP.

The altdq_dqs example which use pll, dll, dq_dqs, and dq_iobufs are perfect for my simple application.

However, the report timing from this example showed many timing violations. Are there any example or app notes cover the timing interface for DDR3?

I only found the app notes that cover the tco and tpd (register to pin delay).

I am searching one that could cover the DQ Out Buff compansation by DQS Out Buff.

altera_forum · Answer

No, there won't be anything DDR3 related. Altera has their own altmemphy for DDR3, which has constraints(although deciphering the scripts that write the constraints is painful), so they don't have constraints for do-it-yourselfers. (You say it has to be simple, but DDR3 just isn't simple, and that's why I would recommend using the Altera core). If you want to do your own, you'll want to start with being able to do source-synchronous double-data rate interfaces(note I don't put DDR, since people always assume it's the memory interface), as that's an integral part of transmitting and receiving data in relationship to a clock. But for DDR3, it's just a start. Look at the documentation on altera.com, and I just put a document I put together on the topic up...

http://www.alteraforum.com/forum/showthread.php?p=19264#post19264

altera_forum · Answer

Your document is very useful. It is great. Thanks.

I followed your document instruction, but cannot figure out where you come up 0.927ns setup slack and 0.861ns hold slack from the below statements.

if we look at case# 3. our clock is 5ns (200mhz), so we know our setup and hold requirements are +/-1.25ns. if i enter all set_output_delay constraints as 0ns, i get a worst setup slack 0.927ns and a worst hold slack of 0.861ns. taking the smaller of these two, i set my constraints to:

altera_forum · Answer

Note that interfacing DDR3 DIMMs requires automatic calibration to deal with the fly-by clock/address/command termination.    What is wrong with the Altera-supplied Altmemphy?

Forum Discussion

Output IO Buff is too large; DDR3

9 Replies

Recent Discussions

Request for Alternate Part Recommendation for EPCQ64ASI16N

CPRI F-Tile Dynamic Reconfiguration

Quartus Programmer detects Agilex 7 AGFA014R24B device as AGFA014R24A

Agilex 5 PWRMGT IO pin connections

Shipping package information for 10M25DAF256C8G