RE: BIRD #61 -- Characterization of Receivers

*Some* simulators have problems with slopes evaluation. I can agree with
that. I understand the waveforms that don't look "pretty" will be tough. So
be it. However there is a LARGE class of buses that we can get a little more
"kick" out of. Modeling and simulation is not reality but just tools to help
us understand our designs so that we can get the most performance and best
reliability. Simulation techniques, methods, and tools need to adapt to meet
technology needs. I have a need. In the past few year I've seen much
innovation by my colleagues. They all are pushing the capabilities of older
(and present) tools. This is really neat stuff. Guess what? We may use a
simulation tool suite and not just one tool. Also... about accuracy... Yes I
*need* to understand the limitation of the tools I use. Its that
understanding that helps define to me what tool to use.

Simple background case:

Some newer busses have receivers that have very high gain differential
amplifiers. Characteristically these have slew rate sensitivities in the ps
range. A couple of years ago, I could care less about few hundred ps.
Source synchronized busses and higher speed changed all that. The beauty of
this proposal is that you can start simple and, at least for some designs,
really gain some reliable performance.

Richard Mellitz, Senior Staff Hardware Engineer
Intel

-----Original Message-----
From: C. Kumar [mailto:kumarchi@yahoo.com]
Sent: Tuesday, August 10, 1999 1:30 PM
To: ibis@eda.org
Cc: ibis-users@eda.org
Subject: 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 21:28:33 1999