Re: BIRD #61 -- Characterization of Receivers

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.

--- "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
Received on Tue Aug 10 10:35:23 1999