[SI-LIST] Re: DDR3 Slew Rate derating.
- From: "QU Perry" <Perry.Qu@xxxxxxxxxxxxxxxxxx>
- To: "Moran, Brian P" <brian.p.moran@xxxxxxxxx>
- Date: Mon, 1 Mar 2010 09:30:36 -0600
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 ?
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]"
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.
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:
