Re: BIRD #61 -- Characterization of Receivers

Matthew Flora wrote:
>
> All,
>
> > 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?
>
> Well, I am concerned that about the use of the new INF reserved word in the
> receiver delay table:

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.

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

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
dc.sessions@vlsi.com