Subject: BIRD61 - Input Model

From: Bob Ross <[email-masked]>
Date: Tue, 14 Sep 1999 17:26:45 -0700

To IBIS Committee:

I have been following the BIRD61 discussions.  At this time, we are
still looking for a solution to simulate delay variations as a function
of actual input waveforms Vin(t).

The reference model that captures delay variations is the Spice model
itself.  However, for business reasons (versus technical reasons), this
model may not be available.

BIRD61 attempts to work around this limitation by providing delay
data (that may be derived from Spice Model simulation).  The simulator
then is supposed to use this data to derive an equivalent model of
delay changes that can be applied for an arbitary Vin(t).

BIRD61 proposes to tabulate delays as a function of IDEAL input ramp
parameters: Start_point, End_point, and Slope.

Two general approaches can be taken to apply this data:

(1)  Develop a method to characterize an arbitrary Vin(t) into table
parameters and use the delay tables directly.

(2)  Use the table data to develop model of the input from which Vin(t)
can be transformed (through simulation or tranformation) and the resulting
delay can be derived.  The authors intended that this approach be taken.

Approach (1) is attractive.  It is possible to provide a table as a
function of all three parameters that captures the changes over the
ranges of interest.  The table ranges of interest would need to include
the min and max values of all of the parameters.  Other intermediate
values might be needed.  However. the amount of data would depend upon
how accurate the delays are when such data is extracted using interpolated
values of Start_point, End_point, and Slope.

The problem is to characterize an "arbitrary" input into the "effective"
Start_point, End_point, and Slope.  While there is no perfect process,
some defendable approximation approach might stated such as:

  Start_point = Min point,
  End_point = Max point, 
  Slope = Slope from Min to Max, but derated by some known manner.

The problem is to find a good derating method.  Some approaches might be to
assume a fixed factor, use the (set of) test waveforms to derive a factor,
or use some mathematically derived effective slope.

The recommended derating method should be one that we agree upon.  The
model provider then has enough information to populate the table based
on ideal ramp inputs (that do not need derating) and also to test the
accuracy of applying the derating method on real waveforms.

Approach (2) is attractive for its simplicity.  However, in order for
Approach (2) to be practical, we really do need use the same input model
because:

  Simulators need to produce consistent results.

  Model providers need to know how the data is used in order to produce
    a sufficient amount of tabular data and to also check the validity
    of the calculated delay adjustment against the reference model delay
    simulation.

So far, the proposers of BIRD61 have investigated, without success, some
equation based input models.

These models could be of the following forms:

  (a)  Vin(t) transforms into a delta delay value directly,

  (b)  Vin(t) transforms into a Vout(t) from which the delta delay value is
       calculated.

While I can speculate on a number of approaches, I really do not know
where to begin.  Approach (a) may be to capture as part of the equation the
delay as a function of voltage (under and overdrive effects extracted from
the real Vin(t)) and also adjustments as a function of slope (derived in
some manner from Vin(t)).

Approach (b) is the mathematical equivalent of the complete Spice model
itself (or a simplification).  In the extreme case, a (large) set of
mathematical non-linear equations could be provided that are the Spice
equations with the given process parameters.  These equations would
relate Vin(t) and Iin(t) of the input node to Vout(t) and Iout(t) of the
output node.  No table data is needed.  The given equations are applied
directly through Spice simulation.

If a simplified set of equations are presumed, table data is needed to
fit the coefficients or parameters.  However, for consistency, we all
need to use the same set of equations.

Also, the question arises whether a generic Spice input structure might
be presumed (implying only one set of equations).  One problem may be
that the format of the set of equations will vary with different input
structures.

I think we should continue to pursue Approach (2) and may actually discover
a solution.  However, we need some break-through information such as a good
starting point for an equation structure or a good input model (e.g., 
operational amplifier with feedback) to investigate this further.

In the mean time, I think Approach (1) is more promising.

Bob Ross
Mentor Graphics

---

From: Bob Ross <[email-masked]>
Date: Thu, 16 Sep 1999 10:44:18 -0700

Fred:

You raise some good points and have offered an alternative.

Working directly with tables is the only approach I know so far.
As you indicate, table lookup method has its potential problems
for arbitrary inputs.

While different input modeling approaches might be implemented
(and defended) by different vendors, we are seeking at least
one approach that is defendable.  Without knowing any approach,
we do not know what minimum set of data is necessary.

You indicate that simulation model can be developed that would
respond to arbitrary inputs.  The set of data for this is the
set of Vout(t) tables for a range of Input ramps with different
slopes.  Can you indicate the minimal set of data needed to
implement this approach?

  How many Vout(t) tables do you need?  Will minimum and maximum
  slope tables be sufficient?

  Do you need a range of Vout(t) tables with different Start_point and
  End_point values to capture overdrive/underdrive effects?
  What is this set?

Also I have some general question on Input models:

  Do we need Vout(t) to be extracted under defined load conditions?

  Does a Vmeas need to be specified as the point at which the delay
    is measured?  If Vmeas is internal, does it need to be given?

  Since the Input model transfer may be impacted by overdrive/underdrive 
    conditions, does the input timing reference point for arbitrary
    input slopes or waveforms need to be specified as Vth defined 
    elsewhere?

Bob

Fred Balistreri wrote:
...
> 
> Bob what the current Bird does is give information of delay versus
> slope. However as you mentioned slope is a linear ramp. Left as it is
> a vendor would have to determine slope, presumably during simulation
> in order to choose the right delay. However as you know during SI
> simulation the slope is anything but linear. You therefore are opening
> a can of worms. No doubt each vendor's answer could be different since
> the algorithm to determine slope (what ever that means) could be
> different. Now for the killer. With non-linear slope you don't know who
> is right, and with the data given there is no way to determine it. I
> actually don't care that each vendor is different. Yeah after all that's
> how we distingish ourselves, right? I don't know about you but one way
> I win business is to prove my answer is better than yours. But this
> Bird does not give me enough information to make a better model or
> even a determination of.
> 
> I've said this before but I'll repeat it again. More information could
> be achieved by giving the devices voltage transfer curve(s). That's
> Vout as a function of Vin. This would be tables for rising and falling
> waveforms under different input slope test conditions. This type of
> information gives the vendor precise information (much like I/V curves)
> about the devices characteristics without revealing any structural
> or equations at all. Since Vil, Vih are known the delay numbers can
> be easily derived from simulation. Not only that the model can be made
> more dynamic and would better measure delay as a function of non-linear
> slope. In this way it's straight forward. The vendor does not need to
> determine slope and no equations (guess work) is needed.
> 
> Anyway my two cents (what the hell yeah!) as Canadians say.
> 
> Best Regards,
> --
> Fred Balistreri
> [email-masked]
> 
> http://www.apsimtech.com