Re: BIRD #61 -- Characterization of Receivers

From: Matthew Flora <mbflora@hyperlynx.com>
Date: Thu Aug 19 1999 - 16:36:27 PDT

D. C.,

> > | 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
>
> > 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.
>
> 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?

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
IBIS Open Forum Postmaster
(425) 869-2320 PH
(425) 881-1008 FAX
mbflora@hyperlynx.com
HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA
Received on Thu Aug 19 16:37:47 1999

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT