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

From: [email-masked] (Dileep Divekar)
Date: Tue, 5 Nov 1996 11:16:06 +0800

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 - [email-masked]
------------------------------------------------------------

---

From: [email-masked] ( Bob Ross)
Date: Wed, 6 Nov 96 14:09 PST

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: [email-masked] (Dileep Divekar)
> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table
> Cc: [email-masked]
> X-Sun-Charset: US-ASCII
> Status: RO

---

From: [email-masked] (Dileep Divekar)
Date: Wed, 6 Nov 1996 16:17:36 +0800

Hi Bob,
Thanks for filling us in on the background.

>better control the individual shapes.

My understanding was that the multi-stage switching specification
was an ALTERNATE and may be a more detailed way of specifying the
waveforms. Your statement seems to imply that the multi-stage
specification is in ADDITION to the waveform specification.
If that is the case, I do not see how one can utilize both
pieces of information and reconstruct a waveform in the simulator
and also I do not see how one can develop a model to isolate
these two effects.

Dileep Divekar

---

From: Arpad Muranyi <[email-masked]>
Date: Thu, 07 Nov 96 08:27:00 PST

Text item: 

Dileep and Bob,

I believe the main reason this BIRD was written was because Jon Powell showed us
a few cases for which the V-t curves are NOT adequate.  I am only including 
short excerpts from his description here.  (I am shure he would be willing to 
send the full document to anyone interested).

1)  Decreased drive capability.  In this example the driver has two output 
stages.  The first stage is High Current Low Voltage (100 mA at 3 V), the second
stage is lower driver to 5 V.

2)  TTL-CMOS staged output.  In this example the driver has two staged outputs, 
the first is a standard TTL and the secone is standard 5 V CMOS.

Arpad
================================================================================

Hi Bob,

Dileep Divekar

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Cc: [email-masked]
Subject: Re:  BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table
To: [email-masked]
From: [email-masked] (Dileep Divekar)
Date: Wed, 6 Nov 1996 16:17:36 +0800
dl.org (8.7.3/8.7.3) with SMTP id RAA01013 for <[email-masked]>; Wed, 6 Nov 1996
17:37:49 -0800 (PST)
Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c
om (8.8.2/8.7.3) with ESMTP id RAA27301; Wed, 6 Nov 1996 17:49:19 -0800 (PST)
Received: from mailbag.jf.intel.com ([email-masked] [134.134.248.4])
by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id RAA10791; Wed, 6 Nov 1996 17:4
6:46 -0800 (PST)
Return-Path: [email-masked]

---

From: [email-masked] ( Bob Ross)
Date: Thu, 7 Nov 96 10:58 PST

To All:

Thanks Arpad for your comment.  I had actually replied to Dileep's
question below but forgot to copy to the reflector or to myself.  So
I am reconstructing a similar response.

Multi-staged switching [Driver Schedule] keyword schedules other [Models]. 
These scheduled [Models] have all the properties needed to function
independently including their own V/T tables.  In fact, that would 
probably be the recommended for models that are scheduled to provide
more predictable results for different simulators.  So in this sense,
the [Driver Schedule] is in addition to the [Rising Waveform] and
[Falling Waveform] tables because it calls [Model]s which contain
these tables, and the composite response is the summation of the
individual staged responses of each [Model].

For downward compatibiltiy and consistency, the [Model] under which
[Driver Schedule] is positioned needs to still be a functioning
model with overall I/V tables and [Ramp] and possible V/T characteristics.
In this sense the [Driver Schedule] is an alterative to the V/T
tables and V/I tables contained under this [Model] keyword
because these tables are not used.  So there is no conflicting
information.  However, simulators which do not support [Driver Schedule]
or need it for a particular application could still use the [Model] if the
[Driver Schedule] keyword and table are removed or ignored.

Bob Ross
Interconnectix

> Date: Thu, 07 Nov 96 08:27:00 PST
> From: Arpad Muranyi <[email-masked]>
> Message-ID: <Thu, 07 Nov 96 08:31:38 [email-masked]>
> To: [email-masked]
> cc: [email-masked]
> Subject: Re[2]: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table
> Status: R