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

From: "D. C. Sessions" <[email-masked]>
Date: Wed, 11 Aug 1999 11:38:36 -0700

[email-masked] wrote:
> 
> Hi All,
> 
> Can't anyone clarify this new spec. about receivers for me
> and what the intention is?

> Qestions:
> 
> *********
> *   1   *
> *********
> 
> 1. What is a receiver? Is it
>    a) A part of output buffer which receives controlloing
>       signal (in other words, input of output type buffer).
>       In this case it can be extended to enable node
>       of 3-state and I/O buffers.
>    b) That part of Input buffer, which is looking into
>       a transmission line and receives signals from
>       some output type buffer through the transmission line.

(B)

> I would expect the unswer should be b). However, the spec.
> says:
> 
> ===begin===
> 
> 1) The following new keyword is defined, and is placed in the
> specification just below the [Rising Waveform] and [Falling Waveform]
> keyword descriptions
> 
> === end ===
> 
> But Input buffer has no [Rising Waveform] or [Falling Waveform].
> I/O buffer does have, but Input buffer does not have and
> we have no place to place [Receiver Delay] keyword.

Keep in mind that IBIS specifications are relatively free-form.  Within
a given [Model] there are few constraints on where you place a given
keyword; the paragraph you quoted is purely editorial and describes the
location where the new text will appear in the revised IBIS standard
document.

> *********
> *   2   *
> *********
> 
> 2) Examples are confusing. The should give receiver delay.
>    What we have in example 1:
> 
> ===begin===
> 
> [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

NB: SP got caught by the usual gotcha and has max=slow instead
of max=fast

> === end ===
> delay is about 1ns, ok

No, delay isn't specified at all here.  What this table says is that if
your input waveform rises at 1v/ns from 0.8v to 2.0v (the databook
test condition) then there is no change in the input delay from the data
book timing (DUH!)  OTOH, if the input rises from 0.8v to 1.55v at 1v/ns
then the input delay under slow conditions is unchanged, the delay under
typical conditions is 2.0ns longer than databook, and the delay under
fast conditions is 1.0ns slower than databook.  (OK, so these are mixed up.
See above.)

> example 2:
> 
> ===begin===
> 
> [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
> 
> === end ===
> 
> is it a delay about 1s, or data are in Volts,
> or Nano is missing, or what is it?

Again, these are relative rather than absolute delays.
And you're correct that the dimensions in the table entries
should be nanoseconds.

> *********
> *   3   *
> *********
> 
> 3) Some delays are negative. This is very very bad.
>    Should be always positive. Just from stand point of
>    causality. You apply a signal and then 1ns BEFORE that event
>    your receiver tells you the signal has arrived.
>    Simulators have to add some 'base' delay.
>    Simulator_A will add 1ns, Simulator_B will add 10ns, etc.
>    Why not IBIS spec add this 'base' delay and all have
>    less headahe?

The delays are adjustments to databook timing, so negative numbers are
not a problem.  As for 'base', IBIS is not intended to contain an
entire part data sheet.  If we were to try THAT, we'd need to specify
the setup time to arbitrary signals (eg setup to end of RESET) and so
forth, which is far, far, farther into the functional space than we
can go.  Not gonna happen.

Instead, this BIRD just applies signal-integrity adjustments to the
timing already described in some other format (eg databook).  For
instance, DDR SDRAM devices are characterized with input waveforms
swinging from Vil(ac) to Vih(ac) at 1v/ns (or the reverse).  In real
applications, though, some inputs could actually slew faster and this
might result in a hold-time violation.  The proposed BIRD allows system
designers to refine their timing analyses based on input wave SHAPE as
well as threshold crossing.

> *********
> *   4   *
> *********
> 
> 4) Input buffer has Vinl, Vinh. If [Receiver Delay]-s
>    are specified, then Vinl, Vinh should be discarded. Right?
>    If ONLY 1 [Receiver Delay] is given, say for rising ramp,
>    then we still use Vinl, Vinh, right ?
>    Vinl, Vinh MUST be always given and BE CONSISTENT with
>    [Receiver Delay] if the last is given. Right?

Vinh and Vinl are holdovers from TTL data sheets.  They have some minor
utility as extreme-worst-case noise margin specs; they are quite
useless for timing analysis.  Vmeas is much more relevant, and in
these tables have no effect on its use.  In fact, they depend on it.

We would hope that based on the information in these tables simulator
companies would refine their noise analysis models to recognize that
a transient that (e.g.) rang back to 200mV above a Vinl of 800mV for
250ps in reality has no chance of causing a logic violation.

> *********
> *  end  *
> *********
> 
> ----- Begin Included Message -----
> 
>                  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:
> 
> *******************************************************************************
> 
> ----- End Included Message -----

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

---

From: [email-masked]
Date: Wed, 11 Aug 1999 10:44:47 -0700 (PDT)

Hi All,

THanks

Nik
[email-masked]

Qestions:

*********
*   1   *
*********

===begin===

=== end ===

If the answer is a), then, hey, how we can apply ramp
signal to input of the output buffer, if we do not know
its impedance, Capacitance, etc. ??

*********
*   2   *
*********

===begin===

[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

=== end ===

delay is about 1ns, ok

example 2:

===begin===

[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

=== end ===

*********
*   3   *
*********

*********
*   4   *
*********

*********
*  end  *
*********

----- Begin Included Message -----

BIRD ID#:   61

----- End Included Message -----

---

From: Stephen Peters <[email-masked]>
Date: Wed, 11 Aug 1999 13:31:25 -0700

Hello Nik:

   My comments are below, prefixed by >>>

     Regards,
     Stephen Peters
     Intel Corp.

   >>> it's b).  A receiver can be connected to an input-only pin, or
       it can be the 'input' part of an I/O pin.

   >>>  The above refers to where the keyword is placed textually within
        the specification document itself, not within a particular
        model.  

    >>> Again, the [Receiver Delay] is used to build a receiver model-- it 
        has nothing to do with an output or the output part of an I/O pin.

   >>>  No.  The intent was NOT to spec an absolute delay thru
        the buffer, but the *change* in delay due to differing overdrive
        and input waveform slope conditions.  As I detail below, the
        intent is that by detailing the change in propagation delay 
        thru the receiver for various controlled conditions, a simulation
        vendor can construct a model that predicts the receiver's behavior
        for any arbitrary waveform.

        You are correct that the delay columns in the second example are
        missing the "nS" suffix.  This will be fixed.

     >>> As I pointed out above, the intent is to show the change in
         propagation delay, and a negative change is perfectly OK.  
         Now, you do raise a good issue about 'base delay'.  I do not know
         if base delay is an important variable in constructing a 
         behavioral receiver model, of if different simulators will come
         up with different models because they assumed different base
         delays.  I do assume base delay can be approximated by looking 
         at the setup time specification for a particular pin.  I hesitate,
         however, to have IBIS spec a 'base delay' -- at least not without
         a lot of simulator vendor input.

   >>>  I'm not sure I understand your comment.  The Start_point and 
        End_point parameters are not replacements for Vinh or Vinl.
        Start_point and End_point are in no way "specifications" of 
        switching threshold.  They (and Slope) simply describe a waveform
        applied to a receiver.  Again, the idea is that with the right set of 
        ideal waveforms, a simulator can construct a behavioral model
        of a receiver. 

   I hope these responses help clarify the intent of the BIRD

---

From: Lynne Green <[email-masked]>
Date: Sun, 15 Aug 1999 14:59:00 -0700 (PDT)

A NEGATIVE delay is possible for ANY logic circuit. Example: a simple inverter,
with its threshold at any level except exactly Vcc/2.  Apply a slow ramp, and
measure the 50% to 50% delay.  It will be negative for either the rising or
falling edge (depending on whether the threshold was under/over Vcc/2).  
This happens because logic gates switch when they reach a voltage threshold
determined by transistor sizing.

While I would not expect a negative delay for most I/O, it is certainly not
forbidden at light loading.  And a negative increment in delay is almost certain
at light loading, as pointed out by others.

Lynne Green
HyperLynx

>          a lot of simulator vendor input.

----------------------------------
E-Mail: Lynne Green <[email-masked]>
Date: 15-Aug-99
Time: 14:46:38

This message was sent by XFMail
----------------------------------

---

From: "D. C. Sessions" <[email-masked]>
Date: Mon, 16 Aug 1999 09:39:32 -0700

Please note that I've trimmed the distribution to the standards list.
Presumably there is a difference between the standards list and the
users list, and this falls across that line.

> at light loading, as pointed out by others.

Welcome to the debate.

The question is: do you or any of the the other algorithm troglodytes
have comments on the feasibility of implementing input delay models
based on the table scheme we presented?

We really care -- honestly.

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

---

From: Kellee Crisafulli <[email-masked]>
Date: Mon, 16 Aug 1999 10:04:03 -0700

Hi DC, 

>based on the table scheme we presented?

Wasn't this a startrek episode?
As I recall the algorithm troglodytes ended up destroying their evil
masters (that sat around all day thinking up difficult to impliment IC
concepts)
and then the troglodytes ended up taking over control of their planet.
The background was that the poor algorithm troglodytes were being
mentally effected by working in software mines all day and they had to
breathe in toxic algorithms all day but they eventually liberated
themselves with the help of Kirk by switching to C++ and putting
everything in nice containers.

Monday grins and giggles...
Kellee

---

From: "D. C. Sessions" <[email-masked]>
Date: Mon, 16 Aug 1999 10:30:23 -0700

> everything in nice containers.

Did they look like penguins or was that just a dream brought on
by DAC and Cajun food?

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

---

From: "Matthew Flora" <[email-masked]>
Date: Wed, 18 Aug 1999 13:42:59 -0700

All,

> based on the table scheme we presented?

Well, I am concerned that about the use of the new INF reserved word in the

> | Note the use of the reserved word INF.

Often, interpolation/extrapolation is used when trying to look up values in
tables.  When INF appears in the table, doesn't it present a discontinuity in
the data?  One of the examples given showed a delay delta of 7.0ns at 1.53V
and INF at 1.51V.  What would the delta delay be at 1.52V?  Where is the elbow
in the curve?  Is this simply a case of the table not having enough data
points?

Regards,
Matthew Flora
IBIS Open Forum Postmaster
(425) 869-2320 PH
(425) 881-1008 FAX
[email-masked]
HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA

---

From: "D. C. Sessions" <[email-masked]>
Date: Wed, 18 Aug 1999 14:50:22 -0700

> Well, I am concerned that about the use of the new INF reserved word in the

Can't be helped.  If the rcvr trips at 1.218 volts rising and your wave only
goes to 1.193 volts the receiver never trips -- which is a pretty good
approximation to "inifinite."  OTOH you can't just ignore that point because
under some other condition it WILL trip.

> in the curve?  Is this simply a case of the table not having enough data

I don't see how you could use the data from the tables directly, thus
interpolation is irrelevant.

The problem that we're up against is that unlike the output path, with a
small number of variables (rise, fall) leading to a large number of
outputs (V/T or I/V points), there are an infinite number of possible
input stimuli leading to a small number of output results (timing
changes.)  Thus the usual IBIS enumeration/extrapolation methods won't
work.

Then again, you can't use V/T curves and I/V curves by brute force either.

So what we're anticipating -- and what we need a sanity check on -- is that
you'll come up with some sort of abstract timing model similar to the
noninteger polynomial I presented in San Diego, and then use the tabulated
data to correlate in the parameters.  Actual rundata would be evaluated
against your abstract model (double integral or whatever.)  As a model check
we're intending to add a "golden waveform" construct as well so that a
complex waveform can be checked agains the tool's internal model to see if
it gets something like the right result.

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

---

From: Stephen Peters <[email-masked]>
Date: Wed, 18 Aug 1999 15:31:19 -0700

> Well, I am concerned that about the use of the new INF reserved word in the

  <snip>

> in the curve?  Is this simply a case of the table not having enough data

  The simple answer is yes -- the intent of the example was to show syntax
rather than real data.  A realistic example would have many more point around
the input threshold point of the buffer.  However, it seems to me that the
use of the INF value cannot be avoided completely.  Does this mean a 
behavioral receiver model based on table lookup becomes impractical, or does
it just mean that the modeler (data supplier) needs to be *really* careful
about the points picked?

   Regards,
   Stephen Peters
   Intel Corp.

---

From: "Matthew Flora" <[email-masked]>
Date: Thu, 19 Aug 1999 11:46:49 -0700

D. C.,

> interpolation is irrelevant.

I thought we are supposed to use the delay deltas in the table to adjust the
receiver's propagation delay.  So using the example above (from the text of
the BIRD), if the rising edge at the buffer's input rises to a final voltage
of 1.55v, then Tco must be adjusted by 2.0ns.  Correct?

However, if the rising edge at the buffer's input rises to a final voltage
of 1.54v, then Tco must be adjusted by a value interpolated between 7.0ns at
1.53v and 2.0ns at 1.55v.  Correct?

Great.  Now suppose the rising edge at the buffer's input rises to a final
voltage of 1.52v.  Will the output switch?  If so, what adjustment must be
made to Tco?

I believe the BIRD needs to spell this out.

Cheers,
Matthew Flora

---

From: "D. C. Sessions" <[email-masked]>
Date: Thu, 19 Aug 1999 12:19:55 -0700

> of 1.55v, then Tco must be adjusted by 2.0ns.  Correct?

Yup, although it could be Tsu as readily.

> 1.53v and 2.0ns at 1.55v.  Correct?

One would expect so.  Then again, in The Real World (tm) input waveforms
are most unlikely indeed to slew neatly to 1.54 volts and then come to a
screeching halt at exactly that point, so the question is somewhat academic.
It is more appropriate to say that a simulator should respond to that
highly-unlikely stimulus with a value between 2000ps and 7000ps.

Given the same IBIS models with identical VT and IV tables, the same PWB
database, etc. users get different answers from Hyperlynx' simulators,
Interconnectix' simulators, Quad's simulators, Veribest's simulators, and
so forth.  That charming fact allows you as programmers to have fun on the
job, your employers as vendors to differentiate their products and us as
an industry to evolve our tools by selecting superior algorithms.

Similarly, you can all come up with different interpolators.  Please do.
May the best algorithm win.

> I believe the BIRD needs to spell this out.

On the contrary, doing so would cast the answer into stone when there's no
particular reason to suspect that it's even remotely right, much less optimal.
Just as IBIS doesn't specify an algorithm for interpolating output impedance
during transitions, it shouldn't specify an algorithm for predicting input
delays.

IBIS provides measurement points.  YOU provide algorithms.
C'mon, Matt!  You don't want us to hog all the fun now, do you?

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

---

From: "Matthew Flora" <[email-masked]>
Date: Thu, 19 Aug 1999 16:36:27 -0700

D. C.,

> C'mon, Matt!  You don't want us to hog all the fun now, do you?

You have hit upon my point.  Any data not explicitly supplied in the table
must be guessed at/approximated by whatever tools are processing the table.
Therefore, I suggest that we include language under the [Receiver Delay]
keyword that strongly recommends to the model creator that they include in
their tables the last "End_point voltage" which is sufficient to cause the
buffer to switch states and the first "End_point voltage" which is
insufficient to cause a state change, with the understanding that the effects
of any "End_point voltages" that fall in between the two are implementation
dependent.

In other words, indicate what would be considered a good [Receiver Delay]
table (one with plenty of data points around the "interesting areas") and
alert the model creator to behavior that is entirely dependant upon a tool.
Informed model creators create better models.

Cheers,
Matthew Flora