Hello,
please excuse: the following is just a quick'n'dirty thinking about BER
definition in DDR4 DRAM (If I do not get any response I know it is
bullsh... ;-) )
As there is just a discussion on BER of DRAM interfaces .. (even this
was triggered by DDR5 discussion):
Yes, we had some Random jitter considered in the DDR4 Spec, but so far I
never thought about what the definition really meant!
So far I was thinking: I can measure Deterministic jitter and can add
some TX Random jitter on top of this to Calculate the BER of my system!
(maybe this assumption was just stupid).
As mentioned by Vinu below: The spec is a DRAM input Spec.
What does this mean for the Random jitter definition in the Mask with
Random and Deterministic jitter ?
Is this Random jitter really what can be provided as input to the DRAM?
or is this the margin for the random jitter required by the Receiver to
ensure you will get 1e-16 ?
As this is a Device input specification I would assume the second one.
So any kind of Transmit jitter is still to be considered separately.
But this discussion might be anyhow obsolete:
I just compared JESD79-4B vs. JESD79-4A: while in the 4A you still find
the Random and deterministic separation in the 4B the spec only talks
about tdiVW as "RX timing windows" required to achieve a BER 1e-16.
No separation of Deterministic Vs. Random jitter any more (so ... what
have we discussed the last 5 years (since the release of the initial
DDR4 Spec) ?)
Excerpt to tdiVW (RX Timing window) parameter from JESD79-4B Spec:
1. Data Rx mask voltage and timing total input valid window where VdIVW
is centered around Vcent_DQ (midpoint) after VrefDQ training is
completed. The data Rx mask is applied per bit and should include
voltage and temperature drift terms. The input buffer design
specification is to achieve at least a BER = e-16 when the RxMask is not
violated. The BER will be characterized and
extrapolated if necessary using a dual dirac method from a higher BER(tbd).
What seems to support my assumption above: The spec was talking about
RECEIVER Random jitter and have to deal with TX Random jitter anyhow
independent and we need to ensure, that we do not violate the RX mask
with a specific amount of Random jitter from the Transmitter.
Maybe this is clear to others on the List.. I have to admit, after
thinking now for an hour on this one .. the meaning of the spec is still
not really clear to me (but 4B spec at least simplifies this one)..
Best regards
Hermann
P.S.
Maybe the Deterministic Jitter is as well defined as the CA timing was
in JESD-79-4A.
on several places the spec refers to de-rating tables .. but there are
none. In the 4B spec at least up to DDR4-2400 values are given .. all
above is TBD.
How mature is this spec? Initial release was 2012!
I also like e. g. overshoot definitions with overshoot above VDD
absolute max (this was spec 4A .. but 4B did not really improve).
... and then having a drawing in, that equipment vendors take serious
and calculate the area of a triangle.
It seems industry does not need the accuracy that we talk about ?!?
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 30.10.2017 um 22:53 schrieb Vinu Arumugham (Redacted sender vinua for
DMARC):
1) Looking at the DDR4 spec., BER of 1e-16 is specified only for the
DRAM input timing. For DDR4-3200, that's an error every 36 days. That
error rate is acceptable when CRC is enabled and data is retransmitted
on error. But the read direction has no CRC. So it must be "error-free",
which in practice means a BER requirement of 1e-18.
2) Stephen wrote:
"Our recommendation is that since the SSO is a deterministic jitter, simulate
with transient with an ideal power supply, then simulate with the real PDN,
and note the change in amplitude noise, and jitter. You only need a few
thousand bits to capture the spread of this effect."
The PDN "pulse response" has to settle in 10 to 12 bit times for "a few
thousand bits" to be sufficient. That may not be true.
Thanks,
Vinu
On 10/30/2017 08:25 AM, Todd Westerhoff wrote:
Chris,------------------------------------------------------------------
Sorry for the delay in response - was off watching college hockey on
Friday.
As always, you raise good points. I'm not going to take a position here,
other than to say we'll be figuring this stuff out as an industry. EQ for
DDR5 is coming straight at us, and we need to figure out how we design /
simulate / verify this stuff. No method is going to be perfect, but there
is going to be considerable debate of what is good enough, what is
accurate but unattainable in a practical sense, and what is wishful
thinking / marketing bunk.
The British Statistician George Box was known to say "All models are
wrong. Some models are useful." I think that applies to much of what we do
in SI - we need to quantify where our models are off and by how much, so
we can decide how to use them productively in our decision making process
- or whether to use them at all. I take simulation results with a grain of
salt - and I've been using simulators since before the term EDA was
coined. I trust simulation results only when I think I have a good reason
to do so - and try to make sure I'm aware of what assumptions those
results are based on.
To the AMI point - you're quite right, the assumption of output driver /
channel / receiver termination linearity and time invariance is baked into
the fundamental architecture of IBIS-AMI. The paper I posted touches on
that but sidesteps the whole debate of SSO and I/O drivers - not as a
dodge, but simply to keep the paper within a reasonable length. The debate
of whether or not statistical methods and AMI can be applied to DDR5 is a
real one and will continue for a while. It will be ... interesting. Yeah -
I'm going with interesting.
There's no easy out here. Traditional SPICE / SSO won't get us to the
statistical coverage we need ( ... and I don't mean 1e-16; I'm not even
touching that one), and AMI is based on strict assumptions that we've
never applied to DDR analysis before.
And ... by way of a pre-emptive assertion, using AMI with an impulse
response derived from SSO analysis is just as bad as using an impulse
response based on ideal power modeling. One's pessimistic, one's
optimistic, and while they probably bracket the problem, it's really hard
to say where in the middle the answer lies.
So - it's gonna be interesting. But that's a good thing - because that's
how we advance the state of the art.
Thanks for your comments!
Todd.
Todd Westerhoff
VP, Semiconductor Relations
Signal Integrity Software Inc. . www.sisoft.com
6 Clock Tower Place . Suite 250 . Maynard, MA 01754
(978) 461-0449 x124 . twesterh@xxxxxxxxxx
"I want to live like that"
-Sidewalk Prophets
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Cheng, Chris
Sent: Sunday, October 29, 2017 12:09 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EQ for DDR5
I have publicly presented our view of deep BER analysis for multiple times
and privately talked to multiple tool companies. I will not use this
thread as a platform to do so.
I will sent out the links to one of my presentation once it is uploaded in
a separate thread.
To focus back on statistical and BER16 for DDR. If you drink that koolaid
of 10-16, you are talking about 50+ bits sequences. Do you even think a
50+ bit sequence driven by a single driver ever exist in real DDR
read/write access ?
Or is it bursts of 4x,8x,16x driven by multiple drives at multiple
locations on a read (different ranks, DIMM) or even mingled between read
or write bursts ? How do you construct your "worst case patterns" under
realistic protocol access condition with multiple drives at different
locations and random burst length and timing ? Is your statistical BER16
analysis by a single driver just some pretty pictures that will never
happen in real life ?
You either believe every read/write transection is properly set up and
terminated by the protocol and focus on the limited burst length or you
have to scare yourself to packed in all the transections possible under
multiple drivers and driven locations (even at the receiving location for
a read follow by a write) within the BER depth you are told to reach.
What truly scare DDR designers are the protocol misses the DDR specs made
because the device community never factor in real life system
implementation. A real example was the DDR3 strobe pre/postamble timing
that everyone got burnt and end up violating the spec to make the system
work. Does leveling even work under limiting cases ? Those will be the one
keeps us awake at night.
If I want a good dish of Kung Pao Chicken, I don't need a better wok, I
need to work on my cooking.
Chris Cheng
Distinguished Technologist , Electrical
Hewlett-Packard Enterprise Company
+1 510 344 4439/ Tel
chris.cheng@xxxxxxx / Email
4209 Technology Dr
Fremont, CA 94538
USA
-----Original Message-----
From: slater@xxxxxxxxxxxx [mailto:slater@xxxxxxxxxxxx]
Sent: Saturday, October 28, 2017 1:35 AM
To: Nitin_Bhagwath@xxxxxxxxxx; Cheng, Chris <chris.cheng@xxxxxxx>;
si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: EQ for DDR5
Hi Chris,
I'll chime in again. DFE does not easily have a representation in
Transient (i.e. SPICE) simulation, since the DFE is applied after the
latch.
If you had the full transistor level circuitry for the EQ you could
simulate it with a transient solver, but that is not what is available to
a system designer. It would also be much slower to simulate the full
SPICE level circuitry than any IBIS (or IBIS-AMI) model representation of
the same.
The EQ can be more easily applied in statistical because mathematically
you can calculate what the impact of the CTLE and DFE will be on the
impulse responses (one for rising, one for falling) and compute the final
eye.
The point Nitin makes about when statistical analysis becomes important
really has to do with the worst case bit pattern. At lower speed grades
you could simulate a few thousand bits and feel comfortable you've
captured the worst case bit pattern. As the data rate increases, the
number of bits 'in flight' in the channel increases (the channel is
electrically longer, and reflections affect many future bits). To make
things worse, the same is true for every neighboring line, which means
crosstalk also has impact on many future bits. The number of possible
permutations for bit patterns increases exponentially; One of which is the
worst case.
At DDR4 and DDR5 rates, the BER is specified... and it is very low
(1e-16). Statistical channel simulations calculate down to this level
very quickly. It always captures the worst case eye closure. That is the
point of using it (well that and the case that statistical sim is fast).
However you also mentions SSO... that is a time-varying affect.. It can
only be captured by a transient simulation. In that respect transient and
statistical channel simulation are very much complementary. Our
recommendation is that since the SSO is a deterministic jitter, simulate
with transient with an ideal power supply, then simulate with the real
PDN, and note the change in amplitude noise, and jitter. You only need a
few thousand bits to capture the spread of this effect.
That change needs to be fed into the channel simulation either as a Dj
variable, or by simply increasing the Rx BER mask by the same amounts,
effectively giving yourself less margin. There's a DesignCon 2017 paper on
this topic and it correlates well to measurement.
I hope this helps.
Best regards,
Stephen.
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Bhagwath, Nitin
Sent: Friday, October 27, 2017 6:51 PM
To: chris.cheng@xxxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EQ for DDR5
in DDR ?Why do you think equalization can only be done by statistical analysis
I don't.
As in my first sentence, we need to separate equalization from
statistical. For DDR5, DFE Equalization is needed. Discussions are
ongoing about whether/how IBIS-AMI can be used as a solution, given some
limitations. I think it's a bit premature to call out any methodology as
standard yet.
At what datarate statistical analysis becomes really useful for DDR (maybe
because it takes too many UI to get all combinations in) is a separate
interesting topic. Maybe an interesting Designcon paper someday.
So as in my last sentence, I'm still a bit confused about what the
question is...
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Cheng, Chris
Sent: Friday, October 27, 2017 6:01 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EQ for DDR5
Why do you think equalization can only be done by statistical analysis in
DDR ?
Chris Cheng
Distinguished Technologist , Electrical
Hewlett-Packard Enterprise Company
+1 510 344 4439/ Tel
chris.cheng@xxxxxxx / Email
4209 Technology Dr
Fremont, CA 94538
USA
-----Original Message-----
From: Bhagwath, Nitin [mailto:Nitin_Bhagwath@xxxxxxxxxx]
Sent: Friday, October 27, 2017 5:30 PM
To: Cheng, Chris <chris.cheng@xxxxxxx>; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: EQ for DDR5
We need to separate the need for statistical analysis from the need for
equalization analysis. Both have been used for Serial links with
IBIS-AMI, but DDR5 really only needs support for DFE. If this involves
requiring IBIS-AMI, well, that's the fun conversation in the IBIS-AMI
committee to make sure that SSO, DQS, non-asymmetric and other limitations
are worked around. An industry-standard support is still a
work-in-progress.
If you're talking only about being able to do SSO and incorporate DQS,
well, many tools support that today (including HyperLynx). Simply do a
time-domain simulation with a few thousand bits. The ringing should die
down within a couple of round-trips.
There's the answer. What's the question again?
Regards,
-Nitin
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Cheng, Chris
Sent: Friday, October 27, 2017 5:00 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EQ for DDR5
Single end source synchronous bus like DDR is very difficult to do
statistical analysis.
Single ended driver with active termination is most likely non-LTI. SSO is
a worst case analysis with odd and even mode SSO impact. Also, strobe
placement is different between read and write so SSO impact is different
between the two conditions. While protocol guarantee only 50% bus
switching, nearby bit switching will saturate the SSO impact within a few
local bits. You always simulate only the worst case impact because you're
like to run into it in real life.
DDR bus is very different from serial bus. The burst is mostly limit to
4x, 8x bit for random cache line access. Deep BER analysis is really
meaningless in real life. Just pretty pictures.
However, protocol corner cases like strobe pre/postamble timing analysis
is important also. Leveling training is notoriously problematic.
Anyone who claim there is a package for DDR bus analysis better have
answers to the above.
Chris Cheng
Distinguished Technologist , Electrical
Hewlett-Packard Enterprise Company
+1 510 344 4439/ Tel
chris.cheng@xxxxxxx<mailto:chris.cheng@xxxxxxx> / Email
4209 Technology Dr
Fremont, CA 94538
USA
[hpe-logo-sm]
------------------------------------------------------------------
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:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeli
sts.org%2Fwebpage%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da6
753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdata
=kC3MTS3RbyXVFDBcR29CjU5KIk%2FWS1jsYyBzcSCnS9o%3D&reserved=0
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftech.group
s.yahoo.com%2Fgroup%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d51d
a6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sda
ta=gh2kFp1e6lDaj4N9jVp6%2B0f1TDAAMW1D%2BFM98ptD1uc%3D&reserved=0
List archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeli
sts.org%2Farchives%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da
6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdat
a=3heFaY39B8WtM8GB4C9R1OksLkRtNUwDUbCnbDwJFD0%3D&reserved=0
Old (prior to June 6, 2001) list archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.qsl.ne
t%2Fwb6tpu&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da6753f%7C63545f2732
324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdata=4l37el%2F4qDyOzh
5GYpPPPkz5fYWGvGPr2XhBk25tVZw%3D&reserved=0
------------------------------------------------------------------
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:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeli
sts.org%2Fwebpage%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da6
753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdata
=kC3MTS3RbyXVFDBcR29CjU5KIk%2FWS1jsYyBzcSCnS9o%3D&reserved=0
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftech.group
s.yahoo.com%2Fgroup%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d51d
a6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sda
ta=gh2kFp1e6lDaj4N9jVp6%2B0f1TDAAMW1D%2BFM98ptD1uc%3D&reserved=0
List archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeli
sts.org%2Farchives%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da
6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdat
a=3heFaY39B8WtM8GB4C9R1OksLkRtNUwDUbCnbDwJFD0%3D&reserved=0
Old (prior to June 6, 2001) list archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.qsl.ne
t%2Fwb6tpu&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da6753f%7C63545f2732
324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdata=4l37el%2F4qDyOzh
5GYpPPPkz5fYWGvGPr2XhBk25tVZw%3D&reserved=0
------------------------------------------------------------------
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:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeli
sts.org%2Fwebpage%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da6
753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdata
=kC3MTS3RbyXVFDBcR29CjU5KIk%2FWS1jsYyBzcSCnS9o%3D&reserved=0
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftech.group
s.yahoo.com%2Fgroup%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d51d
a6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sda
ta=gh2kFp1e6lDaj4N9jVp6%2B0f1TDAAMW1D%2BFM98ptD1uc%3D&reserved=0
List archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeli
sts.org%2Farchives%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da
6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdat
a=3heFaY39B8WtM8GB4C9R1OksLkRtNUwDUbCnbDwJFD0%3D&reserved=0
Old (prior to June 6, 2001) list archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.qsl.ne
t%2Fwb6tpu&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da6753f%7C63545f2732
324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdata=4l37el%2F4qDyOzh
5GYpPPPkz5fYWGvGPr2XhBk25tVZw%3D&reserved=0
------------------------------------------------------------------
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
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
