Hi Folks.
Allow me to chime in. DDR3 output specs are ridiculously conservative. As
covered nicely here, the data valid window is (tQHmin - tDQSQmax) further
derated by the negative peak input period jitter. These tQH and tDQSQ specs
are for every conceivable PVT corner, from every manufacturing lot from every
DRAM manufacturer that makes JEDEC compliant parts, plus margin built into the
specs to increase manufacturing yields. If you are implementing any sort of
deskew, the static skews will train out. Some OCV effects may train out as
well, depending on the number of ranks on the interface and the sophistication
of the deskew algorithm.
DDR4 is addressing some of this conservatism, but the spec is still TBD for
many of these items. Some memory vendors have posted datasheets on their
websites that are almost completely populated with values. These are very
likely what the JEDEC spec will say when it is released. This is very helpful
for writing DDR4 timing budgets. There are two new output specs for DDR4,
tDVWd and tDVWp. These are data valid window specs for the device and for the
pin. These are built around the concept that no individual device will have a
minimum tQH and a maximum tDQSQ. tDVWd has a data valid window spec in terms
of UI that is a bit bigger than what you would get if you were to calculate
tQH-tDQSQ. tDVWp is a per pin specification. This has an even wider data
valid window because it removes package and predictable circuit skews. The
assumption is that the user is implementing deskew. If you are not using
deskew, use the per device window. As above, these values must be derated by
the input CK/CK# jitter.
John Ellis
Principal Engineer
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of Hermann Ruckerbauer
Sent: Wednesday, August 26, 2015 11:45 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR3 output timing uncertainty question.
Hi,
the original question was on output timings, but it seems it is related to a
timing budget calculation.
The DRAM output timings are defined when driving into a test load and should
consider Rise/fall mismatch and Package/on die SSO effects.
Vref uncertainty would be a don't care for the output timings (but is still a
question when measuring output timings on a special testboard).
Even the output timings should not be measured in a real system this would be
the starting point to consider the uncertainty of the DRAM output during reads.
So for a timing budget you should use these values as discussed.
But here there already is the next problem .. when talking about a timing
budget you would do die to die simulation. But in this case you have the DRAM
package included in the simulation .. and in the output timings as well, as
these are defined at the ball .. so you have some double counting of the DRAM
package effects (same might be true on the controller side).
So for an accurate timing budget there are many more things things to be
considered (e. g. is a duty cycle error already considered in the output
timings, how to calculate a timing budget, if the output timings are Vref
based, but input timings are AC/DC based, ... )
My personal opinion is, that the DDR3 spec is not really accurate enough to do
a solid timing budget calculation at speeds >1600. And the DDR4 spec is quite
old, but has many "tbd" in, and if the new methodology really improves things
is another questions.
and BTW: if we talk about measurements you should be aware, that the compliance
applications usually mix up "DRAM output" and "Read" test.
I'm complaining about this all the time when talking to the scope vendors, but
so far i have not seen that this would have been changed.
The DRAM compliance application will do "DRAM output" tests under the name of
"Read" tests. But DRAM output tests need to be done on a special testboard into
a testload, not in a system. The DRAM vendor is responsible for spec compliant
DRAM output parameters, not the system designer.
If you want to verify your system Read performance with the compliance app you
might need to use some tricks in order to use the "Write tests"
as "Read tests".
Best regards
Hermann
Our next Events:
Seminar "Open the Black Box of Memory" (27.-28.10.2015) in Aarhus, Denkmark
Senunar "Open the Black Box of PCIe PHY Test" (29.08.2015) in Aarhus, Denmark
EKH - EyeKnowHow
Signal Quality made in Bavaria
Hermann Ruckerbauer
www.EyeKnowHow.de
Hermann.Ruckerbauer@xxxxxxxxxxxxx
Itzlinger Strasse 21a
94469 Deggendorf
Tel.: +49 (0)991 / 29 69 29 05
Mobile: +49 (0)176 / 787 787 77
Fax: +49 (0)3212 / 121 9008
Am 26.08.2015 um 16:09 schrieb Ken Patterson:
This gets deeper if you consider things like rise-fall delay mismatch,
SSO effects, vref uncertainty, etc. All of these eat away at timing
margin and must be considered especially at higher data rates such as
2133MT/s.
Ken
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Hermann Ruckerbauer
Sent: Wednesday, August 26, 2015 2:47 AM
To: Nitin_Bhagwath@xxxxxxxxxx; DBanas@xxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR3 output timing uncertainty question.
Hi,
just one comment in addition to the timings below:
The output timings in the datasheet are given based on ideal input
clock and need to be derated with the incoming clock jitter.
The DLL on the DRAM does not clean up the jitter, but only delays it
(and add it's own jitter on top of it, but this part should be
considered in tDQSQ and tQH).
Hermann
Our next Events:
Seminar "Open the Black Box of Memory" (27.-28.10.2015) in Aarhus,
Denkmark Senunar "Open the Black Box of PCIe PHY Test" (29.08.2015) in
Aarhus, Denmark
EKH - EyeKnowHow
Signal Quality made in Bavaria
Hermann Ruckerbauer
www.EyeKnowHow.de
Hermann.Ruckerbauer@xxxxxxxxxxxxx
Itzlinger Strasse 21a
94469 Deggendorf
Tel.: +49 (0)991 / 29 69 29 05
Mobile: +49 (0)176 / 787 787 77
Fax: +49 (0)3212 / 121 9008
Am 26.08.2015 um 02:34 schrieb Bhagwath, Nitin:
Hello Dave,time of a DQ with respect to its strobe. tQH gives the earliest that
During read transactions, tDQSQ gives the latest valid output
transition
the output DQ can go invalid with respect to its DQS.
These two together should describe the output valid (and invalid)between DQ and DQS, and hence the output uncertainty between them.
timing
Regards,and DQS, for a DDR3 SDRAM part, from its data sheet?
-Nitin
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of David Banas
Sent: Tuesday, August 25, 2015 4:05 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] DDR3 output timing uncertainty question.
Hi all,
How does one estimate the relative output timing uncertainty, between
DQ
Thanks,
-db
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
