[SI-LIST] Timing Methodology (renamed from Question about Simulation in Spectraquest)
- From: Scott McMorrow <scott@xxxxxxxxxxxxxxxx>
- To: "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>,Jonathan Dowling <jdowlin2@xxxxxxxxx>
- Date: Sat, 11 Aug 2001 22:08:04 -0700
Jonathan,
> 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?
>
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
>
> Regards,
> -jd
>
>
>
> --- Scott McMorrow <scott@xxxxxxxxxxxxxxxx> wrote:
> > Jonathan,
> >
> > In my experience, there is still the problem that the "standard methodology"
> > for timing does not make the conditions under which timing is specified
> > explicit. Worst case timing specs assume and are characterized in
> > a particular package with a particular switching environment. This
> > is never fully specified. Then ... when we do system simulations we
> > include (some) package and power effects. In many cases, "standard
> > methodology" duplicates jitter, noise and timing effects which are
> > actually already incorporated in to the worst case timing numbers
> > for a device. Here, we double count these effects. In other
> > cases, many manufacturers do not perform a thorough device and
> > package characterization. Many "standard" behaviorial simulation
> > environments do not correctly simulate package crosstalk, power
> > and ground effects. Again, we miss the mark in actual performance.
>
> >
> > Jonathan Dowling wrote:
> >
> > > All,
> > >
> > > This all sounds good until its time to design to the DDR-DRAM spec.
> > > The legacy flight time methodology applies well here to integrate
> > > the spec numbers into a timing budget.
> > >
>
> > > It seems to me that for parallel interfaces involving separate strobes
> > > and data (no embedded clock), defining timing/voltage parameters at
> > > the pin boundary is inescapable for production components even if
> > > your company owns the entire network. The simulation-only methodology
> > > works great until something breaks. After that, diagnostic means are
> > > needed which do not require an E-BEAM.
> > >
> > > -jd
> > >
>
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.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
>
------------------------------------------------------------------
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:
