Subject: Re: BIRD #61 -- Characterization of Receivers

From: "D. C. Sessions" <[email-masked]>
Date: Tue, 10 Aug 1999 09:42:25 -0700

Stephen Peters wrote:
> 
> Hello All:
> 
>    Following is the first in a series of BIRDS that aim to enhance
> IBIS's ability to specifying and characterizing receivers.  Comments
> appreciated.

Clarification:
Because these sections are totally meaningless without the Vmeas
parameter, all of the voltages specified are to be considered relative
to Vmeas (or at least that's the way I remember it.)

That breaks the examples, but I think we can deal with that.

> ===================================
> 
>                  Buffer Issue Resolution Document  (BIRD)
> 
> BIRD ID#:   61
> ISSUE TITLE: Enhanced Characterization of Receivers
> REQUESTOR: D.C Sessions (Philips), Richard Mellitz, Stephen Peters,
>            Arpad Muranyi (Intel Corp)
> DATE SUBMITTED: August 9, 1999
> DATE ACCEPTED BY IBIS OPEN FORUM:
> 
> *******************************************************************************
> *******************************************************************************
> 
> STATEMENT OF THE ISSUE:  The current specification allows the user to
> describe the static Vinh and Vinl thresholds of a receiver.  However, these
> parameters specify only the DC input thresholds at which the output of
> a receiver switches state.  They do not describe a digital logic receiver's
> dynamic performance.  Dynamic performance includes such items as how a
> device's setup or hold time varies with input overdrive, or how a receiver
> behaves when an input waveform rings back into the area between Vinh and
> Vinl.  In addition, the current specification does not support simulation
> methodologies that rely on specifying the total delay from the input of an
> output buffer to the output of the receiver.  This bird offers a way for the
> user to specify a receiver's propagation delay and dynamic characteristics in
> enough detail so that a simulation tool can model a receiver's response to
> any arbitrary waveform.
> 
> *******************************************************************************
> 
> STATEMENT OF THE RESOLVED SPECIFICATIONS:
> 
> 1) The following new keyword is defined, and is placed in the
> specification just below the [Rising Waveform] and [Falling Waveform]
> keyword descriptions
> 
> |=============================================================================
> |      Keyword: [Receiver Delay]
> |     Required: No
> |   Sub-Params: Start_point, End_point, Slope
> |  Description: This keyword specifies how the propagation delay of an
> |               input receiver varies as a function of input overdrive or
> |               input waveform slope.
> |
> |  Usage Rules: The [Receiver Delay] keyword is followed immediately by the
> |               three subparameter names and their arguments. The Start_point
> |               and End_point subparameters define the starting and ending
> |               voltage points of a linear ramp while the Slope parameter
> |               specifies the slope of that ramp.  Slope is given in units of
> |               volts per second (V/S).  All three subparameters are required.
> |
> |               Subparameter Usage:
> |               The intent of the subparameters is to specify a set of linear
> |               ramps that vary only in starting point, ending point, or
> |               slope.  Therefore, when assigning values to the subparameters,
> |               two of the three subparameters must be assigned fixed values,
> |               while the third subparameter uses as its argument the reserved
> |               word TABLE.  The use of the word TABLE indicates that this
> |               subparameter is the independent variable in the associated
> |               receiver delay table.  The subparameter that uses the TABLE
> |               argument must appear after the other two subparameters and
> |               before the receiver delay table.
> |
> |               Numerical arguments are separated from their associated
> |               subparameter by an equals sign (=); white space around the
> |               equals sign is optional.  The TABLE argument is separate
> |               from its associated subparameter by white space.
> |
> |               Receiver Delay Table:
> |               Following the subparameters is the receiver delay table itself.
> |               This table consists of four columns.  The first column lists
> |               either the starting voltage, ending voltage or slope of the
> |               linear ramp (i.e. the independent variable) as determined by
> |               the subparameter with the TABLE argument. The second thru
> |               fourth columns list the change in the receiver's propagation
> |               delay. This "change in delay" is relative to the receiver's
> |               delay when it is stimulated using the same overdrive and edge
> |               rate conditions used to specify the device's setup and hold
> |               times.  The delay columns are arranged in the standard typ,
> |               min, max format.  All four entries must be placed on the same
> |               line and must be separated by at least one white space.  All
> |               four columns are required.  However, data is required only for
> |               the typical column. If minimum or maximum data is not available
> |               use the reserved word NA.  Each receiver delay table is limited
> |               to 100 rows and only one receiver delay table is allowed per
> |               [Receiver Delay] keyword.  However, there are no restrictions
> |               on the number of [Receiver Delay] keywords per [Model] keyword.
> |               Note that the [Receiver Delay] keyword is not allowed unless
> |               the Model_type of the [Model] is one of the Input or I/O
> |               models types.
> |
> |               Use of INF as a Receiver Delay:
> |               When building a receiver delay table the user may specify an
> |               input condition that does not result in the receiver's output
> |               changing state.  In that case, the receiver delay is considered
> |               infinite, and the reserved word INF is used in the delay
> |               column.  See the examples below.
> |
> |               Other Notes:
> |               It is expected that the user will provide enough [Receiver
> |               Delay] keywords (i.e. characterization data) to allow a CAE
> |               tool to build a model of the input receiver.  It is expected
> |               that at least four [Receiver Delay] keywords will be required;
> |               two low to high going ramps and two high to low going ramps.
> |               However, the exact number of ramps and there content is up
> |               to the user and recommendations provided by the various
> |               simulation vendors.
> |
> | An example table showing how receiver delay varies vs. overdrive.
> | Note the use of the reserved word INF.
> |
> [Receiver Delay]
> Start_point = 0.8v
> Slope = 1v/1ns
> End_point  TABLE
> |variable      typ     min    max
> 1.4            INF     7.0ns  INF
> 1.5            INF     5.0ns  INF
> 1.51           INF     3.0ns  10.0ns
> 1.53           7.0ns   0.0ns  7.0ns
> 1.55           2.0ns   0.0ns  1.0ns
> 1.6            0.0ns   0.0ns  0.0ns
> 1.7            0.0ns   0.0ns  0.0ns
> 2.0            0.0ns   0.0ns  0.0ns
> 2.1            0.1ns   0.1ns  0.1ns
> 2.5           -0.2ns  -0.1ns -0.5ns
> |
> | A second table that characterizes receiver delay vs. the slope of the
> | input waveform.
> |
> [Receiver Delay]
> Start_point = 0.8v
> End_point = 2.0v
> Slope  TABLE
> |variable      typ     min    max
> 0.05/1ns      -1.0   -3.5    -1.0
> 0.25/1ns      -0.75  -2.0    -0.05
> 0.50/1ns      -0.01  -0.5    -0.0
> 0.60/1ns       0.0    0.25    0.0
> 0.75/1ns       0.0    0.0     0.0
> 1.00/1ns       0.0    0.0     0.0
> 2.00/1ns      +0.5   +0.2    +1.0
> |
> |
> |2)  Item 2 under General Syntax Rules and Guidelines is modified to include
> |the following reserved words
> 
>    INF   - used when a data value is so large it is considered infinite
>    TABLE - used to indicate that a subparameter's value(s) are part of a
>            table.
> *******************************************************************************
> 
> ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:  This bird originated from
> discussions held at the January '99 IBIS summit regarding the lack of a
> way to accurately and realistically specify the input thresholds and
> dynamic performance of a digital logic receiver.  At the mid year '99 IBIS
> summit D.C. Sessions, Stephen Peters, Richard Mellitz and Arpad Muranyi
> agreed to meet to hammer out a proposal.  This bird is one of the results.
> The technical basis of this bird derives from simulation work done by
> Richard Mellitz.
> 
> *******************************************************************************
> 
> ANY OTHER BACKGROUND INFORMATION:
> 
> *******************************************************************************

-- 
D. C. Sessions
[email-masked]

---

From: Stephen Peters <[email-masked]>
Date: Tue, 10 Aug 1999 08:22:51 -0700

Hello All:

   Regards,
   Stephen Peters
   Intel Corp.

BIRD ID#:   61

---

From: Mike LaBonte <[email-masked]>
Date: Thu, 12 Aug 1999 09:30:13 -0400

From what I have read so far, BIRD #61 specifies a timing *correction* table
mechanism, as opposed to a more sophisticated algorithm for dynamically
determining when a receiver has switched. The way I see it, a simulator would
have to:

1) Determine switch times at a receiver using good 'ol Vmeas.
2) Analyze the waveform around the Vmeas switch point and use the [Receiver
   Delay] info to determine a correction factor.
3) Offset the switch time by the correction factor and use this in timing
   measurements.

This seems OK for signal integrity style simulations, in which propagation of
a signal through interconnect is analyzed, but propagation through components
is not. However, a more functional style of simulation in which the received
signal propagates through a component and into another piece of interconnect
would not be served well by this BIRD. This limitation is OK for analysis of
common clock designs, in which the output buffer transition start times are
governed more by the system clock than anything else.

However, with source synchronous designs we may find ourselves wanting to
analyze some reasonable subset of the design, at least a few nets that
participate in a tight bus protocol, in a functional manner. At this time
the simulator would have to accurately model the propagation time(s) through
the component. The only reason I bring this up is because we seem to agree
that the seemingly endless stream of enhancements that IBIS needs to keep up
with technology, is causing us pain. We can at least try to make our changes
last a little longer. OK, now I can return to discussing what this BIRD *does*
address (steps down from soap box).

Are IBIS models limited to having only one [Receiver Delay] table? If so,
how do we specify separate corrections for rising and falling inputs? I would
expect that at least two tables would be required, one with Start_point less
than End_point (rise), and one with Start_point greater than End_point (fall).
It is not clear to me that this would be allowed, and I would expect the
specification to have an example showing both rise and fall. I would not expect
to use a single table "in reverse" to determine falling switch time corrections.

Mike

> IBIS's ability to specifying and characterizing receivers.  Comments
...