Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PC I & PCI-X

From: "Muranyi, Arpad" <[email-masked]>
Date: Thu, 10 May 2001 16:43:59 -0700

Stephen,

I have seen some specs (system bus on P4 platforms) which also
include transmission lines and series inductors, and other
elements (describing a package at the ends of the T-line) in
the reference or test load.  Even though I strongly disagree
with such test loads, I feel we should address these too in
the IBIS spec.  Do you think that this BIRD could be used to
extend the variety of load circuits?

Arpad
=================================================================

Date: Mon, 30 Apr 2001 15:19:51 -0700
From: Bob Ross <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PCI &
PCI-X

To IBIS Committee:

Stephen Peters is submitting BIRD71 for consideration in IBIS Version 4.0.

Bob Ross
Mentor Graphics

****************************************************************************
**
****************************************************************************
**

BIRD ID#:       71
ISSUE TITLE:    Timing Test Loads in [Model Spec] to Support PCI & PCI-X
REQUESTER:      Stephen Peters, Intel Corp.
DATE SUBMITTED:  April 30, 2001
DATE ACCEPTED BY IBIS OPEN FORUM: Pending

****************************************************************************
**
****************************************************************************
**

STATEMENT OF THE ISSUE:

    The IBIS specification lacks a way to specify minimum and maximum values
for timing test load parameters.  In addition, the current set of timing
test
load parameters (Cref, Rref) are applied to both edges of an output
waveform,
thus making them inadequate for describing the timing tests loads used by
the PCI-X bus specification.

****************************************************************************
**

STATEMENT OF THE RESOLVED SPECIFICATIONS:

The following additional subparameters are added to the [Model Spec]
keyword:
Cref, Rref, Vref_rising, Vref_falling, Cref_rising, Cref_falling,
Rref_rising,
Rref_falling, Vmeas_rising, Vmeas_falling.

Changes and additions to the [Model Spec] keyword are shown by the |* lines

|===========================================================================
==
|     Keyword:  [Model Spec]
|    Required:  No
|  Sub-Params:  Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, S_overshoot_high,
|               S_overshoot_low, D_overshoot_high, D_overshoot_low,
|               D_overshoot_time, Pulse_high, Pulse_low, Pulse_time, Vmeas
|*              Vref, Cref, Rref, Cref_rising, Cref_falling, Rref_rising,
|*              Rref_falling, Vref_rising, Vref_falling, Vmeas_rising,
|*              Vmeas_falling.
| Description:  The [Model Spec] keyword defines four columns under which
|               specification subparameters are defined.
|
|               The following subparameters are defined:
|               Vinh               Input voltage threshold high
|               Vinl               Input voltage threshold low
|               Vinh+              Hysteresis threshold high max Vt+
|               Vinh-              Hysteresis threshold high min Vt+
|               Vinl+              Hysteresis threshold low max Vt-
|               Vinl-              Hysteresis threshold low min Vt-
|               S_overshoot_high   Static overshoot high voltage
|               S_overshoot_low    Static overshoot low voltage
|               D_overshoot_high   Dynamic overshoot high voltage
|               D_overshoot_low    Dynamic overshoot low voltage
|               D_overshoot_time   Dynamic overshoot time
|               Pulse_high         Pulse immunity high voltage
|               Pulse_low          Pulse immunity low voltage
|               Pulse_time         Pulse immunity time
|
|       Vmeas              Measurement voltage for timing measurements
|       Vref               Timing specification test load voltage
|*       Cref               Timing specification capacitive load
|*       Rref               Timing specification resistance load
|*       Cref_rising        Timing spec capacitive load for rising edges
|*       Cref_falling       Timing spec capacitive load for falling edges
|*       Rref_rising        Timing spec resistance load for rising edges
|*       Rref_falling       Timing spec resistance load for falling edges
|*       Vref_rising        Timing spec test load voltage for rising edges
|*       Vref_falling       Timing spec test load voltage for falling edges
|*       Vmeas_rising       Measurement voltage for rising edge timing
|*                             measurements
|*       Vmeas_falling      Measurement voltage for falling edge timing
|*                             measurements
|
| Usage Rules:  [Model Spec] must follow all other subparameters under the
|               [Model] keyword.
|
|               For each subparameter contained in the first column, the
|               remaining three hold its typical, minimum and maximum
values.
|               The entries of typical, minimum and maximum be must be
placed
|               on a single line and must be separated by at least one white
|               space or tab character.  All four columns are required under
|               the [Model Spec] keyword.  However, data is required only in
|               the typical column.  If minimum and/or maximum values are
not
|               available, the reserved word "NA" must be used indicating
the
|               typical value by default.
|
|               The minimum and maximum values are used for specifications
|               subparameter values that may track the min and max operation
|               conditions of the [Model].  Usually it is related to the
|               Voltage Range settings.
|
|               Unless noted below, each subparameter does not require
having
|               any other subparameter.
|
|               Vinh, Vinl rules:
|
|               The threshold subparameter lines provide additional min and
|               max column values, if needed.  The typ column values are
still
|               required and would be expected to override the Vinh and Vinl
|               subparameter values specified elsewhere.  Note: the syntax
|               rule that require inserting Vinh and Vinl under models
remains
|               unchanged even if the values are defined under the [Model
|               Spec] keyword.
|
|               To mimic a hysteresis effect, the values of Vinh and Vinl
may
|               be interchanged such that the Vinl value is larger than the
|               Vinh value.  However, simulators may process this
information
|               differently or report an error.
|
|               Vinh+, Vinh-, Vinl+, Vinl- rules:
|
|               The four hysteresis subparmeters must all be defined before
|               the hysteresis threshold rules become effective.  Otherwise
|               the standard threshold subparameters remain in effect.  The
|               hysteresis thresholds shall be at the Vinh+ and Vinh- values
|               for a low-to-high transition, and at the Vinl+ and Vinl-
|               values for a high-to-low transition.
|
|               S_overshoot_high, S_overshoot_low rules:
|
|               The static overshoot subparameters provide the voltage
values
|               for which the model is no longer guaranteed to function
|               correctly.
|
|               D_overshoot_high, D_overshoot_low, D_overshoot_time rules:
|
|               The dynamic overshoot values provide a time window during
|               which the overshoot may exceed the static overshoot limits
|               but be below the dynamic overshoot limits.  D_overshoot_time
|               is required for dynamic overshoot testing.  In addition, if
|               D_overshoot_high is specified, then S_overshoot_high is
|               necessary for testing beyond the static limit.  Similarly,
if
|               D_overshoot_low is specified, then S_overshoot_low is
|               necessary for testing beyond the static limit.
|
|               Pulse_high, Pulse_low, Pulse_time rules:
|
|               The pulse immunity values provide a time window during which
|               a rising pulse may exceed the nearest threshold value but
|               be below the pulse voltage value and still not cause the
|               input to switch.  Pulse_time is required for pulse immunity
|               testing.  A rising response is tested only if Pulse_high is
|               specified.  Similarly, a falling response is tested only if
|               Pulse_low is specified.  The rising response may exceed the
|               Vinl value, but remain below the Pulse_high value.
|               Similarly, the falling response may drop below the Vinh
value,
|               but remain above the Pulse_low value.  In either case the
|               input is regarded as immune to switching if the responses
|               are within these extended windows.  If the hysteresis
|               thresholds are defined, then the rising response shall use
|               Vinh- as the reference voltage, and the falling response
shall
|               use Vinl+ as the reference voltage.
|
|*             Vmeas, Vref, Cref, Rref rules:
|*
|*             The Vmeas, Vref, Cref and Rref values under the [Model Spec]
|*             keyword override their respective values entered elsewhere.
|*             Note that a Vmeas, Vref, Cref or Rref subparameters may not
be
|*             used if its edge specific version (*_rising or *_falling) is
|*             used.
|*
|*             Cref_rising, Cref_falling, Rref_rising, Rref_falling,
|*             Vref_rising, Vref_falling, Vmeas_rising, Vmeas_falling rules:
|*
|*             Use these subparameters when specifying separate timing test
|*             loads and voltages for rising and falling edges.  If one
|*             'rising' or 'falling' subparameter is used, then the
|*             corresponding 'rising' or 'falling' subparameter must be
|*             present.  The values listed in these subparameters override
any
|*             corresponding Cref, Vref, Rref or Vmeas values entered
|*             elsewhere.

|---------------------------------------------------------------------------
--
[Model Spec]
|   Subparameter          typ        min        max
|
| Thresholds
|
Vinh                      3.5        3.15       3.85    | 70% of Vcc
Vinl                      1.5        1.35       1.65    | 30% of Vcc
|
| Vinh                    3.835       3.335     4.335   | Offset from Vcc
| Vinl                    3.525       3.025     4.025   | for PECL
|
| Hysteresis
|
Vinh+                     2.0        NA         NA      | Overrides the
Vinh-                     1.6        NA         NA      | thresholds
Vinl+                     1.1        NA         NA
Vinl-                     0.6        NA         NA      | All 4 are required
|
| Overshoot
|
S_overshoot_high          5.5        5.0        6.0     | Static overshoot
S_overshoot_low          -0.5        NA         NA
D_overshoot_high          6.0        5.5        6.5     | Dynamic overshoot
D_overshoot_low          -1.0       -1.0       -1.0     | requires
|                                                       | D_overshoot_time
D_overshoot_time          20n        20n        20n     | & static overshoot
|
| Pulse Immunity
|
Pulse_high                3V         NA         NA      | Pulse immunity
Pulse_low                 0          NA         NA      | requires
Pulse_time                3n         NA         NA      | Pulse_time
|
| Timing Thresholds
|
Vmeas                     3.68       3.18       4.68    | A 5 volt PECL
|                                                       | example
|
| Timing test load voltage reference example
|
Vref                      1.25       1.15       1.35    |  An SSTL-2 example
|
|*  BEGIN ADDED EXAMPLE
|*
|*  rising and falling timing test load example (values from PCI-X spec)
|*
Cref_falling              10p        10p         10p
Cref_rising               10p        10p         10p
Rref_rising               25         500         25  | typ value not
specified
Rref_falling              25         500         25  | typ value not
specified
Vref_rising               0          1.5         0
Vref_falling              3.3        1.5         3.6
Vmeas_rising              0.941      0.885       1.026 | vmeas = 0.285(vcc)
Vmeas_falling             2.0295     1.845       2.214 | vmeas = 0.615(vcc)
|*
|*
|*   END ADDED EXAMPLE
|===========================================================================
==

****************************************************************************
**

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

BIRDxx is issued because of a long standing problem with specifying PCI
compliant drivers.  In PCI 2.2, minimum timing values are specified into
a 0pF load, while maximum timing parameters are specified into a 50pF
load.  There was no way to specify this cleanly in IBIS.

In addition, the PCI-X specification goes even further in specifying
separate
timing test loads for maximum rising and falling edges, and a single test
load for the minimum case.  In order to satisy the PCI-X spec all eight
variations of Cref, Vref, Rref and Vmeas has to be included.  Note that the
PCI-X minimum test load is represented by it's Thevinen equivalent.

****************************************************************************
**

ANY OTHER BACKGROUND INFORMATION:

****************************************************************************
**

---End of forwarded mail from Bob Ross <[email-masked]>

---

From: "Reid, Chris" <[email-masked]>
Date: Thu, 10 May 2001 17:40:54 -0700

Arpad,

I don't think the IBIS specification should allow these test
loads.  It is a mis-understanding of the purpose of these
test loads that results in these abuses.  IBIS should lead
by explaining to the community the real purpose of test
loads and why it is important.  Adding this capability
to the IBIS specification would definitely be in the wrong
direction.

Chris

-----Original Message-----
From: Muranyi, Arpad [mailto:[email-masked]]
Sent: Thursday, May 10, 2001 4:44 PM
To: [email-masked]'
Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support
PC I & PCI-X

Stephen,

Arpad

To IBIS Committee:

Bob Ross
Mentor Graphics

BIRD ID#:       71

STATEMENT OF THE ISSUE:

---

From: "Ingraham, Andrew" <[email-masked]>
Date: Fri, 11 May 2001 12:06:11 -0400

> loads and why it is important.
 
I haven't been paying full attention lately (too much stuff going on!), but
thought I'd chime in at this point.

In digital logic, most real loads look like unterminated transmission lines,
with some capacitance sprinkled in.  The old lumped C or R-C load right on
the DUT pin is unrepresentative, and may be inadequate as a test load.

That is, in fact, why PCI 2.1 (not PCI-X, by the way) changed from the
ancient 50pF test load, to the two 25 ohm loads (for 3.3V PCI parts), each
representing a pair of 50 ohm traces in parallel; one case with the lines
previously in the low state, the other in the high state.  This test load
emulates infinitely-long transmission lines, which is somewhat unrealistic
(but more representative than the lumped load).

Not only that, but there are times when a few nanoseconds of transmission
line, is a partciularly useful "test" load, such as when comparing
simulations of an IBIS model to a SPICE model.  And it's a good, quick way
to visually see how a part behaves when its output "rattles around," quickly
exercising how the output transistors both source and sink current (as the
outputs go beyond the rails), as well as ESD clamping, reflection
coefficient, die capacitance, and package impedance.  You can reveal a lot
about a part ... or its model ... in one quick test, which the old lumped
R-C model can never show.

Regards,
Andy

---

From: "Peters, Stephen" <[email-masked]>
Date: Fri, 11 May 2001 10:00:20 -0700

Hi Andy:

  I agree that a testing a model with something other than a simple RC is
necessary to test the goodness of a model.  I wish more folks would validate
their models with realistic transmission line type loads before releasing
them.  However, the purpose of the timing test load is not to test a buffers
response in an environment with reflections, etc. -- it's to measure Tco.
For that, the timing test load should be something that produces a clean,
full-switching edge at the nominal impedance of the intended application.  I
think that is what Chris was getting at, and I tend to agree.

  Regards,
  Stephen Peters
  Intel Corp.

-----Original Message-----
From: Ingraham, Andrew [mailto:[email-masked]]
Sent: Friday, May 11, 2001 9:06 AM
To: [email-masked]'
Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support
PC I & PCI-X

Regards,
Andy

---

From: "Reid, Chris" <[email-masked]>
Date: Fri, 11 May 2001 10:07:27 -0700

Andrew,

Using the 25 ohm loads makes a lot of sense.  Allowing a timing
test load for a rising edge that is different from the falling edge
may also be a good idea.

Testing a model with a real transmission line network is useful
to see if the IBIS model really captures the behavior of the model
under these conditions (with reflections coming back.)  There is
an IBIS effort to define how to measure the accuracy of IBIS models
and that group is considering various transmission line loads.

However, the purpose of the timing test load is very specific and
important.  The delay through the component, as specified by the IC
vendor, is the time from the logic switch of a receiver to the time
a driver reaches vmeas in response.  That is the value the timing
analysis tools work with.  The SI tools deliver the interconnect
delays which is the time that the receiver on the other end of
the interconnect switches minus the time-to-vmeas for the driver.
Thus the timing tools and the SI tools can work together.

More complex timing test loads would just make it more difficult
for timing tools and SI tools to cooperate.  For example if the
reflection from the transmission line causes multiple crossings
of the Vmeas threshold, which one is the right one?

The IBIS accuracy work may add complex loads to the IBIS spec
for the purposes of validating models, but such complex loads
are not desirable for timing test loads.

Thanks,

Chris

-----Original Message-----
From: Ingraham, Andrew [mailto:[email-masked]]
Sent: Friday, May 11, 2001 9:06 AM
To: [email-masked]'
Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support
PC I & PCI-X

Regards,
Andy

---

From: "Reid, Chris" <[email-masked]>
Date: Fri, 11 May 2001 10:09:04 -0700

Stephen,

Yes!  Your response came in at the same time I sent my
own response.  I believe we are saying the same thing.

Chris

-----Original Message-----
From: Peters, Stephen [mailto:[email-masked]]
Sent: Friday, May 11, 2001 10:00 AM
To: 'Ingraham, Andrew'; [email-masked]'
Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support
PC I & PCI-X

Hi Andy:

  Regards,
  Stephen Peters
  Intel Corp.

-----Original Message-----
From: Ingraham, Andrew [mailto:[email-masked]]
Sent: Friday, May 11, 2001 9:06 AM
To: [email-masked]'
Subject: RE: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support
PC I & PCI-X

Regards,
Andy

---

From: "Ingraham, Andrew" <[email-masked]>
Date: Fri, 11 May 2001 15:24:04 -0400

I forgot to mention in my earlier reply:  The AGP spec also uses a
transmission line as its Data Sheet Test Load for measuring Tval (Tco) at 4x
mode.  (Section 4.2.3.3: "The timing margins for 4x mode are smaller and a
simple capacitive load is not sufficient to accurately model the load on a
buffer.")  So even with BIRD71, IBIS would be unable to handle Intel's 1998
AGP spec.

> full-switching edge at the nominal impedance of the intended
> application.

Agreed, you need clean edges.  But I also assert that you ideally want the
Data Sheet Test Load (for measuring Tco) to be reasonably similar to the
actual in-use load.  To the extent that the two are similar, you get better
accuracy, when you come to using the Data Sheet delays.

(I don't understand what you mean by "at the nominal impedance of the
intended application."  A 50 pF capacitor isn't anything like a 50 ohm board
trace impedance, except at 63.7 MHz, and even then the magnitude of the
reflection coefficient is unity.)

What is Tco anyway?  Some people interpret it as simply the delay to the
output pin.  So when they plunk the part down on their board, it is the
delay they will get.  They want to "add up the numbers" and get the total
path delay.  (This might have been the purpose of the P4 test load.)  For
this to work, you need the Test Load (for determining Tco) to be similar to
the actual load, don't you?  At one time, 50 pF was close enough to a
typical load (given slow risetimes, a small fanout, and some inches of
trace); now it may not be.
 
Other people use Tco as the delay in the specific case with the Test Load
attached, and run simulations with both the Test Load and the actual load
and calculate their difference.  IN THEORY, this should always give the
correct results.  However, the further the Test Load is from the actual
load, the greater the simulation errors may be.

Then there is the case of a Standard, such as PCI, which specifies
acceptable Tco (Tval) ranges that a part is allowed to have, from any vendor
and with any IC design or process.

Now I'm not a chip designer so I am taking some liberties here.  But I
assume there are some combinations of IC characteristics (drive strengths,
edge rates, etc.) that are good for driving a 50pF load but not a
transmission line; and vice-versa.  So you could take two different ICs,
that have exactly the same measured Tco with the 50pF test load, and they
would have distinctly different delays in your system!

That's the kind of thing you can avoid with the right test load.  With a
50pF Data Sheet Test Load, what pass as acceptable chips, may behave poorly
(well, variably) in the real system, so you need margins to account for
that.  As speeds go up, you may not be able to afford those margins.  You
need to test the chips for how they will perform in the transmission line
environment, and evaluate them for Pass/Fail based on their Tco with the
transmission line load.

Regards,
Andy