Beyond simple thresholds - adjusting flight time measurements

During last Friday's IBIS committee meeting, the issue of
correcting/adjusting signal quality
simulations based on receiver behavior came up. The issue is that current
SI tools typically
use simple thresholds (VIL/VIH) when performing flight time measurements,
and the more subtle
issues of input-receiver hysteresis are left unaddressed.

For instance, if the signal at the receiver's input buffer crosses the VIL
threshold on a rising
edge, goes "flat" for a long period of time, then rises again and crosses
VIH, how should the
flight time be measured? Similarly, once the signal rises significantly
above VIH, receivers
may be immune to negative voltage "spikes" that cause the signal at the
receiver input to dip
below VIH (or, for that matter, VIL), as long as the "spikes" are
sufficiently short in duration.
As long as the spike is fast enough, it represents insufficient energy to
cause the receiver's
buffer to change state (this is the classic "area-under-the-curve" problem).

For IBIS's purposes, how does one go about quantifying these effects, and
go about setting guidelines
for simulation?

Intel developed a set of guidelines for dealing with these issues when
simulating the Pentium Pro(R)
processor. The flight time measurement guidelines for the GTL+ bus can be
found at:
 
ftp://download.intel.com/design/pro/manuals/24269001.PDF

Interested readers can download this Adobe Acrobat document, where GTL+
flight time measurement issues
are addressed in Chapter 12.

In the past, some customers have automated these types of measurements with
custom modeling and scripting.
Many of these techniques call for establishing two different sets of logic
thresholds, usually referred
to as the "logic thresholds" and the "SI thresholds". Depending on the
simulator used, multiple "phantom"
receivers can be placed in the circuit to measure the signal's behavior at
different points and
voltage levels.

What happens next is also simulator-specific. Depending on the nature and
detail of the post-simulation
reports produced by the simulator, many of the characteristics of the
waveform can be deduced, and the
application of signal-quality-driven timing correction criteria can be
automated. The advantage of
post-processing text reports (instead of waveforms) is that the
post-processing task is simplified,
therefore faster. The risk is that much of the actual waveform data is
lost by reducing the simulation
to reports, and not all issues can be detected/corrected.

Alternatively, the simulation results can be saved as pure waveforms, which
can be post-processed to
apply arbitrary correction criteria. This provides improved accuracy, at
the expense of greater programming
efforts (graphic waveform post-processing) and greater data storage
requirements.

Hopefully, this will serve as a starting point for discussions.

Todd.
Received on Mon Aug 10 14:49:49 1998