RE: BIRD #61

The goal is to model behavior. Are the tables sufficient for some limited
problem space?

Simply put: Can simulator vendors use this data to drive their algorithms?

It doesn't, a priori, require the simulator to use a particular method.
Regarding a "functional" implementation the question would be: "Can these
tables be used to load the function's algorithms?" Another simulator may
choose a more direct approach that detects slew rate. Each will have its
advantages which allows simulator vendors to differentiate on.

To rephrase the question: "Have we provided enough information for the
implementation of an acceptable variety of receiver modeling methodologies?"

Richard Mellitz
Intel
-----Original Message-----
From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
Sent: Tuesday, August 24, 1999 8:56 PM
To: 'ibis@eda.org'
Subject: RE: BIRD #61

Part of the issue here is a fundamental question, not so much whether
we had the smarts to come up with a function or not.

If we go with functions to characterize input behavior, the model maker
will have to generate the coefficients, or even the function itself. In
this case the simulator may turn into a dumb number cruncher. On the
other hand, if we go with tables (as currently proposed) the tool vendor
will have the burden of coming up with the smarts to find the proper
algorithm for the behavior of the input. This allows room for product
differentiation, but may result in a situation where the data provided
in the tables does not define all possible solutions (as someone commented
on this before).

This is the reason we decided to put the proposal (BIRDs) out and solicit
feedback ESPECIALLY from the tool vendors. We want to find out from them
whether they can work with something like this, or not. If the answer is
NO, we will have to revisit the problem and try coming up with a proposal
using functions. If the answer is something like: This will work but,
this and that should be changed (data format, amount of data, etc..) then
we will tweak this proposal until (most of) the tool gurus like it.

So keep on commenting...

And thanks for the comments so far.

Arpad Muranyi
Intel Corporation
========================================================================

I think that this actually addresses the subject of BIRD #61 instead,
so I've changed the 'Subject:' to match. #62 just attempts to capture
in IBIS the same specification semantics that already exist in standards
such as SSTL and HSTL so that there is common ground between the SI tools
and device timing specs.

WRT using vout <= f( vin ) semantic, the problem is that this is not
a static function. The whole point is that it's time-sensitive in
some pretty nonlinear ways. We had a go at characterizing input
delays using algebraicly and weren't happy with the results, so we
fell back on the IBIS tabular strategy.

That doesn't mean that there isn't some clever way to do it more
concisely; it just means that the BIRD's authors weren't smart
enough to find it. Maybe one of the other listmembers will fare
better.

-- 
D. C. Sessions
dc.sessions@vlsi.com