Output IO Buff is too large; DDR3

[Altera_Forum]

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]

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]

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]

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]

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]

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?

[Altera_Forum]

The interface of my project is different than the ALTMEMPHY. So I cannot use this ALTMEMPHY.

[Altera_Forum]

In what way is it different?

[Altera_Forum]

I'm not looking at the document, but from what you pasted I would have gotten those numbers from running a compile and looking at the slacks. If using a different version of Quartus or anything different about the design, and you may see different numbers.

[Altera_Forum]

Thanks. I also think the different is from version of Quartus