[SI-LIST] Re: Timing Methodology (renamed from Question about Simulation in Spectraquest)
- From: Jonathan Dowling <jdowlin2@xxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Mon, 13 Aug 2001 18:41:35 -0700 (PDT)
Scott,
Your proposal sounds similar to the standard/legacy
methodology in use today for driver and receiver
characterization.
What is the difference between the standard/legacy
reference load and the one that you propose? It sounds
like you want to calculate a crosstalk/SSO budget for
the package that is separate from the rest of the
net and report a delay/skew/Tco at the package pin.
That's not the goal of Chris's methodology as I
understand it. If there is a reference load,
wouldn't it have to essentially model the entire
network?
What is the difference between the "de-embedding" of
silicon timing you mention relative to the standard/legacy
way that we think about Tsu/Thold? De-embedding timing
is not the goal of the methodology either.
What would you propose to add to the DDR-II spec to
help support a logic-to-logic timing methodology?
The legacy Flight Time Methodology will be King as long
as there are no crisp answers to the simple questions
I have posed regarding the application of the proposed
alternative logic-to-logic timing methodology to current
and future industry standard interface specifications.
Any timing method which aims to dislodge the Flight Time
method as a standard must be widely integrated into
industry specs. Puffing up and claiming superiority
alone will not be sufficient.
-jd
--- Scott McMorrow <scott@xxxxxxxxxxxxxxxx> wrote:
> Jonathan,
> > In that vein, I would like to "up the ante" so to speak
> > and move from DDR-I, which is a frozen spec, to the DDR-II
> > spec which is still somewhat malleable. After all, it doesn't
> > matter what we say about the DDR-I timing methodology anyway,
> > it's too late to change.
> > If applying a Flight Time Methodology to a 266MT/s DDR-I
> > interface sounds "dinosaurish", cover your eyes...
> >
> > I am willing to wager that there is a 99% chance that the
> > 400-600MT/s DDR-II DRAM spec will define:
> >
> > a) VIH/VIL, Tsu/Thold, etc. at the DRAM package pin
> > b) tAC, tDQSQ, tDQSCK, etc. into a reference load
> >
> > Even if the 30pF cap is removed from the reference load
> > we're implicitly talking about a Flight Time Methodology
> > here. So, the questions I have posed regarding DDR-I in
> > yr2001 will be recurring in yr2003.
> >
> > My question for you is:
> > Are you willing to wager that these "legacy" parameters
> > will be redefined in such a way that they are only valid
> > at the input of the driver and output of the receiver?
> > If not, how would the logic-to-logic timing methodology be
> > applied in conjunction with the DDR-II spec?
> >
> > -jd
>
> I believe that unless changed in some realistic way, the timing
> specs will remain similar to legacy specifications. Unfortunately,
> we cannot decouple specifications from simulation and characterization
> methodology.
>
> I agree that for memory devices it is unlikely that we will be able
> to obtain timing numbers at internal nodes of devices. However,
> for a 600 MT/s bus, we cannot just stand by and allow timing to
> be specified at the pin only, without some bounds on the package,
> simulation and testing environment. 30pf or even 0pF loads do
> not cut it.
>
> I can design two parts which meet the same Tco specifications in
> a tester environment, yet have significantly different in-system performance.
> DDR-I places a bound on the timing and on the capacitance of the
> device. It places no bounds on package inductance or coupling coefficients.
> This makes it quite possible to design devices that have significantly bad
> signal integrity and timing performance in a real system, and no
> way to characterize these "things" in simulation.
>
> If we cannot specify the timing back to the internal nodes of a device,
> (at least for commodity parts), we can better specify the method for
> measurement and the bounds on the packages being used. (Or we
> can specifiy that accurate coupled package models must be supplied
> by all vendors.) With this sort of data, we can then back-out the
> package contribution to timing.
>
> I guess what I would advocate is a more complex test load, which
> accurately specifies the package, the test load on the package
> (which I would advocate being 50 ohms to Vtt or whatever) and a
> series of worst case test scenarios that will be used to characterize
> the device in the package. If these are specified, then it is quite
> possible to deembed the actual silicon timing.
>
> As a straw man, I would suggest:
>
> 1) 50 ohm loads at the package balls(pins) into the standard termination
> reference.
>
> 2) Specific data switching patterns across the entire device that min and
> max timing parameters are specified against. (For example, even mode
> aggressor switching, odd mode aggressor switching, all I/O's on device
> switching, only one I/O on a device switching, only a specific number
> of I/O's on a device switching ... etc.)
>
> Worst case crosstalk pushout will normally occur when a small group of
> adjacent I/O pads switch, while the remainder of the device is quiescent.
> This causes minimal power and ground colapse on the I/O rail and fastest
> driver slew rate.
>
> Worst case SSO pushout will normally occur when all I/O pads on a device
> switch simultaneously in the same direction.
>
> There is often a combination of SSO and crosstalk conditions that are
> even worse in terms of jitter and noise.
>
> 3) A coupled model of the package which has been correlated to measurements.
>
> With the above 3 items specified, it is then possible to calibrate timing
> condtion at the package ball to the measured and guaranteed performance of
> the device.
>
> Regards,
>
> scott
>
>
> --
> Scott McMorrow
> Principal Engineer
> SiQual, Signal Quality Engineering
> 18735 SW Boones Ferry Road
> Tualatin, OR 97062-3090
> (503) 885-1231
> http://www.siqual.com
>
>
>
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
