Subject: BIRD 58

From: "Muranyi, Arpad" <[email-masked]>
Date: Tue, 2 Mar 1999 13:26:00 -0800

****************************************************************************
**
****************************************************************************
**

BIRD ID#:        58
ISSUE TITLE:     Driver Schedule keyword clarification
REQUESTER:       Arpad Muranyi, Intel Corporation
DATE SUBMITTED:  3/2/99
DATE ACCEPTED BY IBIS OPEN FORUM:  pending

****************************************************************************
**
****************************************************************************
**

STATEMENT OF THE ISSUE:

The [Driver Schedule] section of the latest IBIS specification (v3.2) does
not provide enough information to the model maker and EDA tool vendor on
essential details of this keyword.  The spec. can be interpreted in several
different ways which can lead to serious discrepancies and consequences.

****************************************************************************
**

STATEMENT OF THE RESOLVED SPECIFICATIONS:

One paragraph from BIRD35.3 is included in the [Driver Schedule] usage rules
section of the specification.  This portion seems to have been
inadvertently left out from the spec. and explains the gray areas.

The additional words do not change the original intent behind this keyword. 
It is only added to spell out how the keyword must be used so that the model
maker and EDA tool vendor could be in agreement on how the model works.

The new section is marked with a "*" character at the beginning of each
line.

|===========================================================================
==
|     Keyword:  [Driver Schedule]
|    Required:  No
| Description:  Describes the relative model switching sequence for
referenced
|               models to produce a multi-staged driver.
| Usage Rules:  The [Driver schedule] keyword establishes a hierarchical
order
|               between models and should be placed under the [Model] which 
|               acts as the top-level model.  The scheduled models are then 
|               referenced from the top-level [Model] by the [Driver
Schedule]
|               keyword.
|
|*              The [Driver Schedule] keyword overrides any existing
[Pullup],
|*              [Pulldown] and [Ramp] or [Rising Waveform] and [Falling
|*              Waveform] data for that model.  However, the required tables
|*              for [Model] are still required for backwards compatibility
|*              reasons for simulators which do not support multi-staged
|*              switching.  This information can be used as a composite
model
|*              cross-check, although the resulting model may not perform in
|*              the same manner as the multi-stage model.
|
|               The [Driver Schedule] table consists of five columns.  The 
|               first column contains the model names of other models that
|               exists in the .ibs file.  The remaining four columns
describe
|               delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and
|               Falling_off_dly.  All values are referenced to 0 seconds for
|               the start of the rising transition and 0 seconds for the
start
|               of the falling transition.  All delays must be equal to or
|               greater than 0.
|
|               The Rise_on_dly entry gives the beginning of the low-to-high

|               transition.  The Rise_off_dly entry may be given to end the 
|               low-to-high transition and initiate a high-to-low transition

|               during the rising cycle.  Similarly, the Fall_on_dly gives
|               the beginning of the high-to-low transition.  The
Fall_off_dly
|               may be given to end the high-to-low transition and initiate
a
|               low-to-high transition.
|
|               Use 'NA' when no transition is applicable.  For each model,
|               the transition sequence must be complete, i.e., it must
start
|               and end at the same state.  
|
|               Only the [Pulldown] and [Pullup] tables and transition data
|               [Ramp] or [Rising Waveform] and [Falling Waveform] data are
|               used from each model that is referenced.  The [Model]
keyword
|               provides the specification information, [GND Clamp] and
[POWER
|               Clamp], and C_comp, regardless of information contained in
|               the referenced models.
|
|               It is recommended that a "golden waveform" for the device 
|               consisting of a [Rising Waveform] table and a [Falling
|               Waveform] table be supplied under the [Model] keyword to 
|               serve as a reference for validation.
|
|               No [Driver Schedule] may reference a model which itself has
|               within it a [Driver Schedule] table keyword.
|
| Other Notes:  The added models typically consist of Open_sink (Open_drain)

|               or Open_source models to provide sequentially increased
drive
|               strengths.  The added drive may be removed within the same
|               transition for a momentary boost or during the opposite 
|               transition.
|
|               The syntax also allows for reducing the drive strength. 
|
|               Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly,
|               Fall_off_dly parameters are single value parameters, so 
|               typical, minimum and maximum conditions cannot be described
|               with them directly.  In order to account for those effects,
|               one can refer to the fastest waveform table with the delay
|               number and then insert an appropriate amount of horizontal
|               lead in section in those waveforms which need more delay.
|
|               Note: In a future release, the [Driver Schedule] keyword may
|               be replaced by a newer method of specification that is 
|               consistent with some other planned extensions.  However, the
|               [Driver Schedule] syntax will continue to be supported.
|---------------------------------------------------------------------------
--
[Driver Schedule]
| Model_name     Rise_on_dly  Rise_off_dly  Fall_on_dly  Fall_off_dly
  MODEL_OUT      0.0ns        NA            0.0ns        NA
|
|                                  Examples of added multi-staged
transitions
  M_O_SOURCE1     0.5ns        NA            0.5ns        NA
|              low (high-Z) to high        high to low (high-Z)
  M_O_SOURCE2    0.5n         1.5n          NA           NA
|               low to high to low           low (high-Z)
  M_O_DRAIN1     1.0n         NA            1.5n         NA
|              low to high (high-Z)        high (high-Z) to low
  M_O_DRAIN2     NA           NA            1.5n         2.0n
|                  high (high-Z)           high to low to high 
|
|===========================================================================
==

****************************************************************************
**

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

An attempt to build an IBIS 3.2 buffer model for a three-stage buffer using
the [Driver Schedule] keyword failed.  The initial testing of this model
with the tools of two EDA vendors showed only two of the three stages
working.  This happened because the first stage of the buffer was placed
into the "main" [Model] section of the IBIS model due to a personal
interpretation of the IBIS 3.2 spec.  After consulting with several people,
it became apparent that the specification does not mention some of the key
information that is necessary to build a correct IBIS model for this kind of
a buffer.

The following paragraph in BIRD35.3 contains the missing information which
is necessary for making correct IBIS models using the [Driver Schedule]
keyword.  This section seems to have been accidentally left out from the
specification, and should be pasted into the appropriate location as shown
above.  (Note that the first and second sentences are deleted because they
do not provide new information in the context above).

"The new keyword [Driver Schedule] provides a syntax for sequencing other
models.  This is given as a keyword under the [Model] keyword.  It overrides
any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and 
[Falling Waveform] data for that model.  However, the required tables for
[Model] are still required for backwards compatibility reasons for
simulators
which do not support multi-staged switching.  This information can be used
as a composite model cross-check, although the resulting model may not
perform in the same manner as the multi-stage model."

****************************************************************************
**

ANY OTHER BACKGROUND INFORMATION:

Telephone conversation with Bob Ross on 2-26-99 confirmed that the IBIS
specification is missing the description of some of the usage rules which
were documented in BIRD35.3 and was implemented accordingly in ICX.

****************************************************************************
**

---

From: Matthew Flora <[email-masked]>
Date: Wed, 24 Mar 1999 11:29:11 -0100

Arpad,

Since you are submitting BIRD 58 as a clarification to the [Driver Schedule]
keyword, I was wondering if you could add to the BIRD.

From the spec/BIRD:
     "Only the [Pulldown] and [Pullup] tables and transition data 
      [Ramp] or [Rising Waveform] and [Falling Waveform] data are
      used from each model that is referenced.  The [Model] keyword 
      provides the specification information, [GND Clamp] and [POWER 
      Clamp], and C_comp, regardless of information contained in
      the referenced models."

1) In the above excerpt, it says "The [Model] keyword provides the
   specification information, ...".  Should that instead say "The top-level
   model provides the specification information, ..."?

2) The excerpt above does not explicitly say which [Voltage Range] and/or
   [Pullup Reference], [Pulldown Reference] is to be used.  My interpretation
   is that the referenced models use the voltage range/references from the
   top-level model.  Perhaps someone else would interpret it differently.  I'd
   like the spec to explicitly say which voltage range/references are to be
   used with the [Pulldown] and [Pullup] tables taken from the referenced
   models.

From the spec/BIRD:
     "It is recommended that a "golden waveform" for the device 
      consisting of a [Rising Waveform] table and a [Falling
      Waveform] table be supplied under the [Model] keyword to 
      serve as a reference for validation."

3) In the above excerpt, it says "... table be supplied under the [Model]
   keyword to  serve as a reference for validation.".  Should that instead say
   "... table be supplied within the top-level model to serve as a reference
   for validation."?

From the spec/BIRD:
     "The [Driver Schedule] table consists of five columns.  The 
      first column contains the model names of other models that
      exists in the .ibs file.  The remaining four columns describe
      delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and
      Falling_off_dly.  All values are referenced to 0 seconds for
      the start of the rising transition and 0 seconds for the start
      of the falling transition.  All delays must be equal to or
      greater than 0.

      The Rise_on_dly entry gives the beginning of the low-to-high 
      transition.  The Rise_off_dly entry may be given to end the 
      low-to-high transition and initiate a high-to-low transition 
      during the rising cycle.  Similarly, the Fall_on_dly gives
      the beginning of the high-to-low transition.  The Fall_off_dly
      may be given to end the high-to-low transition and initiate a
      low-to-high transition.

      Use 'NA' when no transition is applicable.  For each model,
      the transition sequence must be complete, i.e., it must start
      and end at the same state."

I'm sorry, but I find this whole section confusing.

4) It appears that the intent of the keyword is to allow the drive strength of
   an output buffer to be increased or decreased by adding in (and/or taking
   out) various tables from other models at strategic times during the
   transitioning of the buffer's output.  Is this intent stated in the spec?

5) The above excerpt refers to transitions and a rising cycle.  When is the
   text referring to the transition (cycle) of the output of the buffer as a
   whole versus the transition (cycle) of the added "boost" model?

6) If the Rise_on_dly and Rise_off_dly specify the start of the added "boost"
   model's rising edge and falling edge, respectively, then the example shows
   "boost" models (MODEL_OUT, M_O_SOURCE1) which turn on, but not off during
   the rising transition of the output buffer.  Yet the excerpt above says
   "For each model,  the transition sequence must be complete, i.e., it must
   start and end at the same state."  This strikes me as a contradiction.

7) Must at least one of the delay times be specified or can all four be NA?

I also noticed some typos in the spec/BIRD:

1) In one place the spec refers to "Falling_off_dly" instead of
   "Fall_off_dly".

2) "... other models that exists in the .ibs file."  The "exists" should be
   "exist".

Now I realize that I may have a misunderstanding of the intent and/or the
workings of the [Driver Schedule] keyword.  If I do, then I would suggest that
the definition of the keyword is not clear enough.

Regards,
Matthew Flora
IBIS Open Forum Secretary
(425) 869-2320 PH
(425) 881-1008 FAX
[email-masked]
HyperLynx, 17641 NE 67th Court, Redmond, WA 98052 USA

---

From: Bob Ross <[email-masked]>
Date: Mon, 29 Mar 1999 18:05:08 -0800

Mike:

Thank you for your input.  You have some valid points regarding
allowing C_comp to be distributed.  This will work for creating
driver models as the summation of individual drivers.  The 
problem is that if the top-level model is an I/O model, we
would normally not put in a C_comp value = 0.  Then in the
Input mode, we would have to add up all of the C_comps in 
the lower level models to come up with the effective C_comp.

This is a possible workable solution that does not require
any Specification syntax change - just a few more words of
interpretation.  It would also support moving all of the
C_comp to the top-level for another method of building a
behavioral buffer by construction.

We will have to consider this.

Bob Ross
Mentor Graphics

Subject: Re: BIRD 58
Date: Fri, 26 Mar 1999 14:10:46 -0500
From: Mike LaBonte <[email-masked]>
To: [email-masked]

Regarding the c_comp issue discussed in the Mar 26 IBIS meeting,
related to BIRD 58, I would like to register my opinion in favor
of allowing for the use of separate c_comp values attributed to
each Driver Schedule stage.

Although c_comp may be named as such because of the original
intention that it encapsulate an overall component level capacitance,
the practical matter is that Driver Schedule stages are most
likely to correspond to actual transistors in an IO section. Each
transistor does have it's own effective die capacitance. The
designer of the stage buffers may (should) have validated their
behavior individually, with c_comp intact. To then use them in a
scenario where the c_comp values are not used may not make sense.
(insert discussion of the aggregate capacitance for a cluster of
transistors vs. sum of individually calculated capacitances here).

Furthermore, IBIS could gain maximum flexibility by stating that
the c_comp values of individual stages are used in addition to
the c_comp that might be specified for the top-level model. In
this way, model designers can specify c_comp=0 for any portion
that is not to be used. This part of the proposal is debatable in
my own mind, simply because I have some difficulty producing an
elegant explanation of what the top-level capacitance represents,
when the`"transistor" capacitance is already accounted for. But it
offers flexibility. And it eliminates the requirement that simulators
ignore c_comp data present in the Model, which users may not be aware
of.

Mike LaBonte