AnsweredAssumed Answered

iMX6UL timing parameters issues

Question asked by Wouter Stapper on Dec 8, 2015
Latest reply on Aug 16, 2016 by Preetesh Rathod

When creating a DDR3-800MT controller timing model for Mentor HyperLynx I found some issues with the timing parameters found in the IMX6ULCEC data sheet starting on page 54.

Next I will try to explain the issues and hopefully somebody can help me.

 

We aim to run the DDR3 interface at 800MT/s (400MHz). This gives a full clock cycle of 2500 ps and one bit is 1250 ps.

uncertainties.jpg

Data Write

The values DDR17 and DDR18 show the output valid times (output setup and output hold) for DQ.  This is showing up as 175ps for the setup and 200ps for the hold.  This is the output “valid” eye of 375ps.  Subsequently, 1250-375, or 875ps (70%!!) of the UI budget is consumed by the controller itself.  So given the 375ps valid eye, and the 125ps setup and 150ps hold requirement at the DRAM (See JEDEC JESD79-3F), it does leave only 375 – 125 – 150 = 100ps for everything else.  This seems highly unlikely. 

 

DQS-CK

The data sheet shows timing DDR21, tDQSS as being +/- 0.25 tCK.  Now, the DRAM has an input requirement with suspiciously the same name, tDQSS with the same requirement, +/- 0.25 tCK.  This is the requirement at the DRAM from the low-going DQS to the high going CLK. This means that the low going DQS can be no earlier than 0.25tCK from the high going tCK.  However, the controller’s uncertainty spec of DDR21 can only guarantee that the DQS can be within a quarter clock of the tCK.

 

So imagine the situation where the DQS is launched a quarter clock cycle late.  This means that the falling edge of the DQS is a quarter cycle before the CLK rising edge – at the output of the controller.

 

ideal_DQS-CK.png

 

 

delayed_DQS-CK.png

 

In this case, the DQS of the controller can be as little as a quarter cycle before the clock.  However, the tDQSS requirement at the DRAM is that the falling edge of the DQS is *at least* a quarter cycle before the rising clock.  This means that in the extreme situation, the controller gives the user zero margin for any PCB or other effects for a standard JEDEC compliant DRAM part!

My suspicion is that the data sheet has either been padded excessively, or has not been reviewed quite thoroughly.

 

Similar calculations for the address and read situation don’t seem as unreasonable.

For a read situation, the DRAM provides a valid eye-window of 750ps.

tDQSQ=200ps, and

tQH is 0.38tCK=950ps,

so tQH-tDQSQ = earliest invalid – latest valid

=950 – 200 = 750ps

Controller window requirement = 450ps

Margin = 750-450 = 300ps for PCB effects

 

For the address case,

Output window = DDR6 + DDR7

= 515 + 425 = 940ps

 

DRAM requirement = tIS + tIH

= 200 + 275 (800MT/s speed grade part)

= 475ps

Margin = 940 – 475 = 465ps for PCB effects

 

The question is; Can NXP/Freescale provide more reasonable numbers for Data Write Setup (tDS/DDR17) and Hold (tDH/DDR18) time? And for the DQS to CK (tDQSS/DDR21) timing as well.

Attachments

Outcomes