Re: BIRD #61 -- Characterization of Receivers

"C. Kumar" wrote:
>
> Simulators are not designed for slope evaluation. The calculated slope
> at any time can have substantial errors even though the overall
> voltage/current changes will be accurate.
>
> Tables which depend on slope are asking for trouble.

The problem is that the physical *inputs* are dependent on slope,
and system function (as in, "does it?") depends on the input timing.
We can't just tell ourselves, "slope is hard to deal with in simulaiton,
so we'll ignore its effects." Mostly because the kind of extreme
conservatism that let us do that in the past would eat all of our
timing budgets and leave nothing for minor details like output delay,
skew, flight, setup, and hold time.

Besides which, I think you're misunderstanding the intent of the tables.
They aren't intended to be used directly; like the VT curves they're
for simulator companies to use in building internal timing estimators
which adjust input timing (offsets only, please note) based on input
waveforms which bear no noticable resemblance to the pretty trapezoids
that we invent to convey characterization.

I suppose that this is a good time to mention that there is a companion
proposal that we discussed to define "golden input waveforms" which are
anything BUT pretty, accompanied by their consequent timing responses.
These will be almost certainly useless for building models, for comparison
to real-world waveforms, and almost everything else EXCEPT providing a
check for the simulator that its inferred timing model isn't too far off
from the manufacturer's characterization.

Watch This Space.

> --- "D. C. Sessions" <dc.sessions@vlsi.com> wrote:
> > 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.
> > > |
> >
> === message truncated ===
>
> _____________________________________________________________
> Do You Yahoo!?
> Bid and sell for free at http://auctions.yahoo.com

-- 
D. C. Sessions
dc.sessions@vlsi.com