iMX6UL timing parameters issues

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMX6UL timing parameters issues

Jump to solution
3,977 Views
woutersintecs
Contributor II

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.

Labels (1)
1 Solution
2,879 Views
LPP
NXP Employee
NXP Employee

> Data Write

Your consideration is correct. The only remark is that you can legaly increase the margin by using a DRAM bin or mode with less setup/hold time required.

- JEDEC JESD79-3F (DDR3-800, AC175)

  tDS + tDH = 75 + 150 = 225 ps -> 150ps margin.

- JEDEC JESD79-3F (DDR3-1066, AC175)

  tDS + tDH = 25 + 100 = 125 ps -> 250ps margin.

- JEDEC JESD79-3F (DDR3-1600, base)

  tDS + tDH = 10 + 45 = 55 ps -> 320ps margin.

> DQS-CK

Unfortunately, at the moment we can't provide more "friendly" specs.

In general : even through some parameters, specified in i.MX6 datasheet, do not provide margins, if a DDR design follows recommendations

(in Hardware Development Guide for i.MX6), problems should not take place.

DDR21 is a marginal parameter. The actual DQSS skew can be tuned by calibration and made less than specified (625ps @ 800Mbps). For example, see real results measured on a customer board:

(Combination): [Before] - [Calibration result] = [After]

(CLK1-DQS0): [780ps] - [0x2F(490ps)] = [290ps]

(CLK1-DQS1): [630ps] - [0x30(450ps)] = [180ps]

(CLK0-DQS2): [440ps] - [0x22(320ps)] = [120ps]

(CLK0-DQS3): [410ps] - [0x1D(260ps)] = [150ps]

Rereference document "i.MX 6 Series DDR Calibration"

http://cache.freescale.com/files/32bit/doc/app_note/AN4467.pdf


Have a great day,
Pavel

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

6 Replies
2,879 Views
BiyongSUN
NXP Employee
NXP Employee

The test result is after you finished the DDR caliration?

0 Kudos
2,879 Views
woutersintecs
Contributor II

This issue was found during DDR timing analysis.

0 Kudos
2,879 Views
BiyongSUN
NXP Employee
NXP Employee

How is the timing after you appy the cabliration result?

i.MX6/7 DDR Stress Test Tool V2.30

0 Kudos
2,878 Views
woutersintecs
Contributor II

Write leveling/calibration was performed. But that does not change the Data Write valid eye of 375 ps.

Please note that there is no physical board yet. Only a design that is currently being analyzed for optimal Signal Integrity, Power Integrity and Timing performance.

0 Kudos
2,880 Views
LPP
NXP Employee
NXP Employee

> Data Write

Your consideration is correct. The only remark is that you can legaly increase the margin by using a DRAM bin or mode with less setup/hold time required.

- JEDEC JESD79-3F (DDR3-800, AC175)

  tDS + tDH = 75 + 150 = 225 ps -> 150ps margin.

- JEDEC JESD79-3F (DDR3-1066, AC175)

  tDS + tDH = 25 + 100 = 125 ps -> 250ps margin.

- JEDEC JESD79-3F (DDR3-1600, base)

  tDS + tDH = 10 + 45 = 55 ps -> 320ps margin.

> DQS-CK

Unfortunately, at the moment we can't provide more "friendly" specs.

In general : even through some parameters, specified in i.MX6 datasheet, do not provide margins, if a DDR design follows recommendations

(in Hardware Development Guide for i.MX6), problems should not take place.

DDR21 is a marginal parameter. The actual DQSS skew can be tuned by calibration and made less than specified (625ps @ 800Mbps). For example, see real results measured on a customer board:

(Combination): [Before] - [Calibration result] = [After]

(CLK1-DQS0): [780ps] - [0x2F(490ps)] = [290ps]

(CLK1-DQS1): [630ps] - [0x30(450ps)] = [180ps]

(CLK0-DQS2): [440ps] - [0x22(320ps)] = [120ps]

(CLK0-DQS3): [410ps] - [0x1D(260ps)] = [150ps]

Rereference document "i.MX 6 Series DDR Calibration"

http://cache.freescale.com/files/32bit/doc/app_note/AN4467.pdf


Have a great day,
Pavel

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

2,879 Views
preeteshrathod
Contributor I

I had raised similar concerned over timing parameter of IMX6 w.r.t DDR3 AC timings. I restricted discussion for DDR17 and DDR18 parameters of the datasheet. I had not started new thread but added my questions in below thread which was already present before.

https://community.nxp.com/message/636173?et=watches.email.thread#comment-636173 .

It is really surprising that NXP has mentioned DDR3 JEDEC timing specifications in their DDR3 controller timing specifications.

What NXP has finally informed that they will remove such timing parameters and instead provide Design guidelines which when followed properly will be enough to ensure that no timing violations will occur.

Recently I happened to see one of the QorIQ Processor Electrical Specifications. P4040EC.pdf. I can say that timing parameters (on page number 65 of P4040EC.pdf) tDDKHDS,tDDKLDS are similar to DDR17 of IMX6 DDR3 timing specification and tDDKHDX,tDDKLDX are similar to DDR18 of IMX6 timing specification. These paremeters (tDDKHDS,tDDKLDS,tDDKHDX,tDDKLDX) look more consistent from timings point of view. If this is the case then why NXP should have any trouble to provide consistent timing specification for IMX6.

0 Kudos