[SI-LIST] Re: DDR3 Slew Rate derating.
- From: "Moran, Brian P" <brian.p.moran@xxxxxxxxx>
- To: QU Perry <Perry.Qu@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 1 Mar 2010 23:41:29 -0700
Perry,
Yes, it would be less confusing if the concept of a penalty was included in the
JEDEC documentation, but in the negotiations folks were simply thinking in
terms of the final spec values, and not the math behind it. So noone really
framed it or documenented the concept as a spec plus a penalty. I just did
that myself as a way to make sense of it all, and explain it to people trying
to use the specs and derating tables. Some type of white paper might have been
a good idea back then.
Also note that the penalty is not part of derating process. Rather, its part of
the baseline specification definition, before derating is applied. This is why
its not shown in the derating formula you mentioned. Deraing is done on the
final specs, after you establish tIS(AC) and tDS(AC).
As far as the JEDEC spec, and what Micron shows in their spec, the JEDEC spec
does not have an entry for timing penalty. So you can account for it in two
ways. You can leave tIS(Vref) the same, and add a note explaining that a
penalty is being added in the calculation fo tIS(AC), or you can add the
penalty to tIS(Vref). Either way the value for tIS(AC) ends up the same.
However, in my opinion, the specs at Vref must be constant. When you think
about it, why would the spec at Vref be different, based on which AC threshold
you choose to use. It does not make sense. However, if there is no place to
capture a timing penalty as a separate entity, then the only way to make the
math come out right is to add the penalty to the spec at Vref. This is more of
a specsmanship issue however. It does not change anyone's timing results.
Now, having said all that with respect to tIS, in the case of tDS the penalty
was embedded in tDS(Vref). I would have prefered using the same penalty
concept, however, in this case the penalty is small, and there was only one AC
threshold for tDS. Unlike with tIS, it was not envisioned that people would
choose which AC threshold to use based on some timing trade off. So there was
no need to break out the penalty as a separate entity, or to publish two
versions of tDS(AC). So to avoid confusion the penalty was negotiated directly
into tDS(Vref). At least this was the case in the JEDEC spec. Not sure what
Micron ended up showing in their spec.
Lastly, you are right in that there is no penalty concept for tIH and tDH,
since the DC threshold is constant.
Brian Moran
Signaling Development Group
Client Platforms
Intel Corporation
-----Original Message-----
From: QU Perry [mailto:Perry.Qu@xxxxxxxxxxxxxxxxxx]
Sent: Monday, March 01, 2010 5:06 PM
To: Moran, Brian P
Cc: si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: DDR3 Slew Rate derating.
Hi, Brian:
Thanks for the detailed explanation. Very helpful. I wish these are included in
an Appendix or somewhere so it's easier to understand for those who are not
involved in the standard definitions.
Looking at below and re-read your previous message, I would think that DDR3
derating comes with 3 components:
1. threshold penalty
2. normal sense of slew rate derating based on dv/dt;
3. AC reading vs. Vref reading difference
One difference I find between the table below and Table 54 of Micron datasheet:
on your table, tIS(vref) remains to be constant whether it's AC175 or AC150.
Looking at micron datasheet, the value for "Vref @1V/ns" is different between
AC175 and AC150, and seems have to have included the penalty due to threshold.
Also, for tIH, I did not see any penalty based on the formulae " tIH (DC) = tIH
(Vref) - (DC Threshold / 1V/ns) + penalty", only offset due to reference point
(DC100 vs. Vref). This seems to make sense as there is only one threshold
(DC100) so no penalty should be involved.
Regards
Perry
=======================================
Perry Qu
IPD Design & Qualification, Alcatel-Lucent Canada Inc.
600 March Road, Ottawa ON, K2K 2E6, Canada
Phone: 613-7846720 Fax: 613-5993642
Email: perry.qu@xxxxxxxxxxxxxxxxxx
=======================================
-----Original Message-----
From: Moran, Brian P [mailto:brian.p.moran@xxxxxxxxx]
Sent: Monday, March 01, 2010 11:36 AM
To: QU Perry
Cc: si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: DDR3 Slew Rate derating.
Hi Perry,
I think I can answer your questions. See below.
Brian Moran
Signaling Development Group
Client Platforms
Intel Corporation
-----Original Message-----
From: QU Perry [mailto:Perry.Qu@xxxxxxxxxxxxxxxxxx]
Sent: Monday, March 01, 2010 7:31 AM
To: Moran, Brian P
Cc: si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: DDR3 Slew Rate derating.
Hi, Brian:
I'm reading the JEDEC spec and Micron datasheet and still can't figure out the
following:
I understand the concept to translate AC175/AC150 spec to Vref timing spec
based on the formulae you quoted below, which appears to just account for
different reference point assuming 1V/ns slew rate. However, at 800/1066MHz, we
have both AC175 and AC150 spec, and difference is not what I expected (25ps)
rather more than that, e.g., tDS for DQ setup to DQs is 75ps for AC175 but
125ps for AC150. Shouldn't it be 100ps for AC150 as there is only 25mV
difference and assuming 1mV/ps, that translates into 25ps ?
I can't speak to the Micron spec. I have not seen that spec, but I can provide
some history of the JEDEC spec. The original AC threshold for 800/1067 was
AC175, however, after the AC thresholds for 1333/1600 were set at AC150, there
was a desire to unify the threshold at AC150. However, the SDRAM vendors felt
they needed some timing relief to do this. So an extra 25ps was added to the
setup time at AC150, in addition to the 25ps delta that occurs naturally due to
the threshold change. So the total delta is 50 ps. This is the source of your
confusion.
For address/command, the translation between AC175 and AC150 spec is different
too. Quote from the spec:
"The tIS(base) AC150 specifications are adjusted from the tIS(base) AC175
specification by adding an additional 125 ps for DDR3-800/1066 or 100ps for
DDR3-1333/1600 of derating to accommodate for the lower alternate threshold of
150 mV and another 25 ps to account for the earlier reference point
[(175 mv - 150 mV) / 1 V/ns]"
In the case of CMD/ADR the history is a little different. In this case the
alternate threshold option was negotiated right from the beginning. It was
observed during simulations that in heavily loaded configurations it was not
always possible to reach the AC175 threshold, so since 2T timing is possible
with CMD/ADR, the controller vendors like Intel were willing to accept a larger
penalty on tIS in order to get the lower AC150 threshold. IN this case the
penalty was 125ps at 800/1067, and 100ps at 1333/1600. So when you try to
compare the tIS at AC175 vs tIS at AC150, you have to take these penalties into
account, in addition to the natural delta due to threshold change. So a
detailed spec table would look like the one below.
Baseline Specifications CTRL, ADR, CMD vs CLK
Speed Bin Vcc AC Thres. DC Thres.
tIS(Vref) Penalty tIS(AC) tIH(Vref) tIH(DC)
DDR3-800 1.5V +/-175mV +/-100mV 375ps
0ps 200ps 375ps 275ps
DDR3-1066 1.5V +/-175mV +/-100mV 300ps
0ps 125ps 300ps 200ps
DDR3-1333 1.5V +/-175mV +/-100mV 240ps
0ps 65ps 240ps 140ps
DDR3-1600 1.5V +/-175mV +/-100mV 220ps
0ps 45ps 220ps 120ps
DDR3-800 (note 1) 1.5V +/-150mV +/-100mV 375ps
125ps 350ps 375ps 275ps
DDR3-1066 (note 1) 1.5V +/-150mV +/-100mV 300ps
125ps 275ps 300ps 200ps
DDR3-1333 (note 2) 1.5V +/-150mV +/-100mV 240ps
100ps 190ps 240ps 140ps
DDR3-1600 (note 2) 1.5V +/-150mV +/-100mV 220ps
100ps 170ps 220ps 120ps
Note 1: tIS(AC) at alternate 150mV threshold includes 125ps penalty.
tIS (AC) = tIS (Vref) - (AC Threshold / 1V/ns) + penalty
Note 2: tIS(AC) at alternate 150mV threshold includes 100ps penalty.
tIH (DC) = tIH (Vref) - (DC Threshold / 1V/ns) + penalty
Note 3: Window = tIS(Vref) + Penalty + tIH(Vref).
A more basic question is why we need both AC175 and AC150 specs at 800/1066Mhz
? There are not many wordings on JEDEC spec as to why we need two specs and how
to use them.
As mentioned abopve, for CMD/ADR the two threshold option was intentional with
the idea being we could still hit AC175 with no paenalty in lightky loaded
cases and therefore enable 1T timing for maximum performance, but in heavily
loaded configs, we coud optionally use AC150 threshold and meet overall eye
height requirements, in exchange for running 2T timing.
ON the DQ bus it was not intentional, but evolved in trying to maintain
consistency between 800/1067 and 1333/1600. hope this helps.
Regards
Perry
=======================================
Perry Qu
IPD Design & Qualification, Alcatel-Lucent Canada Inc.
600 March Road, Ottawa ON, K2K 2E6, Canada
Phone: 613-7846720 Fax: 613-5993642
Email: perry.qu@xxxxxxxxxxxxxxxxxx
=======================================
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of Moran, Brian P
Sent: Thursday, February 04, 2010 1:01 PM
To: Moran, Brian P; sreekanth soman; Hermann Ruckerbauer
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR3 Slew Rate derating.
Soman,
I just realized there is another point to be made regarding your question.
The derating values do not stop increasing above 2V/ns. Unfortunately, the
JEDEC spec
stops at 2V/ns. You can calculate the derating values above 2V/ns by using the
formulas
below. These formulas only apply to derating above 1V/ns. Below 1V/ns there is
another
function involved. However, these formulas will address your question.
Fractional
results should be rounded up to next highest integer
Derating @AC175 = 175ps - 175mV/SR, where SR is Slew Rate
Derating @AC150 = 150ps - 150mV/SR
Derating @DC100 = 100ps - 100mV/SR
Brian Moran
Signaling Development Group
Client Platforms
Intel Corporation
-----Original Message-----
From: Moran, Brian P
Sent: Thursday, February 04, 2010 9:48 AM
To: 'sreekanth soman'; Hermann Ruckerbauer
Cc: si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: DDR3 Slew Rate derating.
Derating values can and should be interpolated between slew rate entries.
Otherwise,
use the next highest SR value, but this will result in some incremental loss in
calculated margin.
Brian Moran
Signaling Development Group
Client Platforms
Intel Corporation
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of sreekanth soman
Sent: Thursday, February 04, 2010 9:27 AM
To: Hermann Ruckerbauer
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR3 Slew Rate derating.
Hi,
If the slew rate is above 2 say - 2.5 V/ns,is the derate still the value at
2 V/ns or more than that
I have not found any information regarding this on the web.
I am not sure if the jedec derating values can be extrapolated.
On 28 January 2010 22:29, Hermann Ruckerbauer <
hermann.ruckerbauer@xxxxxxxxxxxxx> wrote:
> Hello,
> as for most parts of the datasheets this data is not adjusted by the
> individual DRAM manufacturers. This kind of number are discussed in
> JEDEC when fixing the Spec, and each company designs it's DRAM to hit
> this target.
> So it's not really that the numbers are defined by the Hardware, but the
> Hardware is designed to hit this numbers. This is true for most of the
> parameters in the Datasheed (e. g. Setup/Hold absolute values).
> Reason for this is, that DRAMs are a commodity product that need to be
> interchanged without thinking. If the DRAMs would have different timing
> definitions it would be a big problem to adjust a system to different
> DRAM vendors. This is something nobody wants to do, and therefore this
> numbers are usually not changed by any DRAM vendor.
> The DRAM vendors also don't want to be better than the spec, because no
> customer will pay for this, and it would cost additional design effort.
>
> Whether a DRAM vendor is doing characterization testing or defining this
> parameter as "guaranteed by design" is up to each DRAM vendor. It is
> definitly no parameter that is checked in a high volume production test.
>
> regards
>
> Hermann
>
> Visit us on Embedded World 2010, 2. - 4. March 2010 in Nuernberg
> Follow our presentation on Tuesday, March 2nd, 11:00 a.m.
> "Signal Integrity in embedded computer systems"
>
> EKH - EyeKnowHow
> Hermann Ruckerbauer
> www.EyeKnowHow.de
> Hermann.Ruckerbauer@xxxxxxxxxxxxx
> Veilchenstrasse 1
> 94554 Moos
> Tel.: +49 (0)9938 / 902 083
> Mobile: +49 (0)176 / 787 787 77
> Fax: +49 (0)3212 / 121 9008
>
>
> schrieb Heyfitch:
> > Brian,
> > I tried "to de-embed" the threshold compensation from the total derating
> > tables so that to compare the SDRAM receiver timing at Vref from
> different
> > vendors.
> > However, a quick look at datasheets vendor from at least 3 vendors
> showsed
> > that they simply reprint JESD79-3C derating tables. Hence, there is no
> way
> > to infer any vendor specific info from their datasheets. Which brings me
> to
> > my question: do SDRAM vendors actually test their IOs for compliance with
> > the jedec derating table? Is this ATE testing or just spice simulations?
> > Thank you.
> > Vadim
> >
> >
> > On Mon, Jan 25, 2010 at 5:50 PM, Moran, Brian P <brian.p.moran@xxxxxxxxx
> >wrote:
> >
> >
> >> Surita,
> >>
> >> Let me try to give you a quick tutorial on derating, which should answer
> >> your question. Please follow up if I don't answer your question fully.
> >>
> >> Derating consists of two components. There is the reciever derating at
> >> Vref,
> >> which tends to be 0ps at 1V/ns and above, and then increases as slew
> rate
> >> slows.
> >> This accounts for the fact that the SDRAM reciever timing starts to
> degrade
> >> as
> >> slew rate drops below 1V/ns. It's a function of the reciever design, and
> >> this
> >> derating at Vref curve is defined by the SDRAM vendors. It has not
> chnaged
> >> significantly since DDR2. The second component of derating is threshold
> >> compensation.
> >> This only comes into play when you measure flight times to AC or DC
> >> thresholds.
> >> Measuring to the AC or DC thresholds tends to distort the flight time
> >> measurements.
> >> This type of derating is dependent on threshold level, which si why you
> get
> >> different
> >> derating tables as speed bin increases. Its not the speed the matetrs,
> but
> >> the AC
> >> abd DC thresholds. So what the JEDEC task group did was to apply a fixed
> >> adjustment
> >> to the tSU and tHD specs at Vref, to account for this distortion at AC
> and
> >> DC.
> >> This adjustment is based on an input slew rate of 1V/ns. So if your tSU
> at
> >> Vref was
> >> 500 ps, and your AC threshold is 175 mV, the tSU at AC is 325 ps. ON
> the
> >> hold side,
> >> if your tHD was 500 ps at Vref, then tHD at DC is 400 ps. They have
> >> pre-biased
> >> the tSU by 175ps to compensate for the additioanl flight time caused by
> >> measuring
> >> to AC175, vs Vref.
> >>
> >> One quick thought exercise is to note that the margin calculated at Vref
> >> and that
> >> calculated at AC threshold, for the same linear non-ledging signal
> should
> >> be equal.
> >> This goes back to when you had the option of measuring to Vref or to
> AC/DC.
> >>
> >> Ok, since they pre-biased the tSU spec by 175ps to account for AC
> threshold
> >> distortion
> >> in your flight time, what happens if your slew rate was actually 2V/ns.
> >> That means they
> >> pre-biased too much and have to take some back. This is where the +88ps
> >> comes from. If
> >> the slew rate was 0.5V/ns then they did not compensate enough and you
> will
> >> get negative
> >> numbers in the threshold compensation table at SRs less than 1V/ns.
> >>
> >> The composite derating table shown in the JEDEC spec is the sum of the
> >> reciever derating
> >> at Vref plus the threshold compensation. Threshold compensation is a
> purely
> >> algebraic
> >> formula, which is; 175ps - 175mV/SR for an AC threshold of 175mV. The
> final
> >> derating table
> >> is characterized by having 0 at 1V/ns, then increasingly positive
> numbers
> >> at SRs above 1V/ns
> >> and increasingly negative at SRs below 1V/ns. This trend is beginning to
> >> break as we get to
> >> smaller and smaller AC thresholds, but for now it's a simpe rule of
> thumb.
> >>
> >> Also note that a positive number in the derating tbale always reduces
> >> margin, and visa versa.
> >>
> >> Like I said, follow up with another emial if its not clear. I consider
> >> myself pretty
> >> knowledgable on derating and can provide some supporting docs if needed.
> >>
> >>
> >> Brian Moran
> >> Signaling Development Group
> >> Client Platforms
> >> Intel Corporation
> >>
> >> -----Original Message-----
> >> From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx
> ]
> >> On Behalf Of Surita Chandani
> >> Sent: Monday, January 25, 2010 2:15 PM
> >> To: si-list@xxxxxxxxxxxxx
> >> Subject: [SI-LIST] DDR3 Slew Rate derating.
> >>
> >>
> >>
> >>
> >> I am trying to understand DDR3 slew rate derating. Let
> >> us say we are working with a differential DQS with a fixed slew rate of
> 2.0
> >> V/ns.
> >>
> >>
> >>
> >> When the DQ slew rate is 1.5 V/ns the setup time is 59
> >> ps. When the DQ slew rate increases to 2.0 V/ns, the setup time
> increases
> >> to 88
> >> ps. I thought the setup time would go down with a faster signal.
> >>
> >>
> >>
> >>
> >>
> >> ------------------------------------------------------------------
> >> 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 technical documents are available at:
> >> http://www.si-list.net
> >>
> >> 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 technical documents are available at:
> >> http://www.si-list.net
> >>
> >> 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 technical documents are available at:
> > http://www.si-list.net
> >
> > 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
> >
> >
> >
> >
> >
> > Eingehende eMail ist virenfrei.
> > Von AVG überprüft - www.avg.de
> > Version: 9.0.733 / Virendatenbank: 271.1.1/2651 - Ausgabedatum: 01/28/10
> 08:36:00
> >
> >
>
>
> ------------------------------------------------------------------
> 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 technical documents are available at:
> http://www.si-list.net
>
> 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
>
>
>
--
sreekanth@ti
------------------------------------------------------------------
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 technical documents are available at:
http://www.si-list.net
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 technical documents are available at:
http://www.si-list.net
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 technical documents are available at:
http://www.si-list.net
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
Other related posts:
