Re: BIRD #61 -- Characterization of Receivers

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
dc.sessions@vlsi.com