Re: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table

Dileep, Kumar, Chris, Arpad and IBIS Committee:

I have reviewed the recent comments concerning BIRD35.2. You
are all perceptive and correct in noting that BIRD35.2
is a departure from the existing external-based-measurement
IBIS paradigm. You are correct in questioning the need
when IBIS already supports Waveform-based models matching.
Also you are correct in noting that there might be some
simulator algorithm dependency on how the model might be
processed by different vendors. All of these items need
to be weighed with respect to the benefit and intent of
providing this capability.

I can give some historical perspective and also illustrate
where such a capablility is (in my opinion) technically
needed.

At an IBIS face-to-face Summit Meeting in 1993, Jon Powell
introduced the notion of multi-staged switching as part
of the discussion on how to deal with V/T characteristics.
One or two other approaches were also presented. Over time
the committee opted to implement the [Rising Waveform]
and [Falling Waveform] approach. It provided the broadest
coverage and had other advantages. It is currently being
used as a reliable way to add model detail. A number of
people also felt that [Rising Waveform] and [Falling
Waveform] capability might adequately cover the multi-
staged driver situations to a sufficient level of
modeling accuracy.

The multi-staged switching physical architecture has been
implemented by a number of silicon vendors. There still
exist details in the implementations that make the case
for including a simulation capability. In the January 1996
IBIS face-to-face Summit Meeting, we put this capability
on the list as one of the priority needs for IBIS Version
3.0. It was not defined then. However, through a number
of proposals evolving into the current BIRD35.2, there is
now is a [Driver Schedule] proposal.

Vendor algorithms to process waveforms are generally good
and reliable, in my opinion. However, there are details
which are different and which hit a the core or why this
added functionality might be required. One nature of
multi-staged switching is that there might be a kicker
pulse during any of the transitions. This implies a
dynamic switching in and out of one or more stages. The
overall transition can be non-monotonic. The more
important aspect is that within some of the silicon
architectures, there is a switched in and out impedance
change during the transition as a result of switching
in and out of, say, an Open_drain stage. From a modeling
perspective, an I/V table gets switched in and out.

While V/T tables can give a good model of such a transition
provided there are no relections back to the driver during
the transition, even this model might not produce the best
results if reflections occur at the driver during the
transitions while the source impedance has changed.

In my opinion, the decomposition of a total circuit is a
not a clean process unless there is really some very
isolated behavior. Whether you can get overall better
results remains to be proven.

My position is that there is need for at least the hooks
so vendors can put in the extra work (and perhaps iterative)
construction to produce an overall better approximation
of actual behavior through a driver scheduling method.
I would expect this method to be used with models that
have [Rising Waveform] and [Falling Waveform] tables to
better control the individual shapes. This would not
be a requirement, but a practical way of implementing
the scheduling so that the results are more predictable
between vendors.

I look forward to more discussion on BIRD35.2 this Friday.

Bob Ross
Interconnectix

> Date: Tue, 5 Nov 1996 11:16:06 +0800
> From: dileep@contec.Apsimtech.COM (Dileep Divekar)
> Message-Id: <9611051916.AA24859@contec13.contec.COM>
> To: ibis@vhdl.org
> Subject: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table
> Cc: dileep@contec.Apsimtech.COM
> X-Sun-Charset: US-ASCII
> Status: RO

> I missed the earlier discussion on BIRD 35.2 before it got hatched.
> Could some one please post the discussion on why the waveform table
> was considered inadequate? Thanks for the help.
> Dileep
> ------------------------------------------------------------
> Dileep Divekar
> Applied Simulation Technology, Inc.
> 2188 Bering Drive
> San Jose, CA 95131

> Phone - (408)-434-0967 x 100
> Fax - (408)-434-1003
> Email - dileep@apsimtech.com
> ------------------------------------------------------------
Received on Wed Nov 6 14:18:08 1996