Subject: BIRD58 discussion

From: "Muranyi, Arpad" <[email-masked]>
Date: Tue, 30 Mar 1999 17:08:45 -0800

To all involved in this conversation,

This is in response to the comments posted in connection with BIRD58
by Steve, Matt (Hyperlinx) Mike (Cadence) and Greg (IBM).  Hopefully
BIRD58.1 will follow shortly.

I am not going to address some of the simpler issues which deal with
spelling and simple English clarity.  I will come up with something
for those in the next revision of the BIRD.

Also, I don't understand Matt's question, quote:

"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?"

so I am not going to address it now.  Matt, could you please explain
to me what you meant?

Problem #1 (these are my numbers now)
==========

The major issue seems to revolve around where things go between the
top level and the scheduled models.  The following section quoted from
the spec (unchanged in BIRD58) makes a clear statement that the only
things that are used from the scheduled models are the pd and pu I-V
curves (not including the clamp I-V curves) and the V-t curves along
with the Ramp information.  According to the last sentence, it is not
illegal to define the specification information, clamp I-V curves and
C-comp in the scheduled model(s).  However, to me this says that if
they are there, they should be ignored, because this information is
"provided" by the [Model] keyword (meaning the top-level model).

|   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.

I hate to say this, but according to this, if we want to allow the
scheduled models to carry "usable" information other than the pd, pu
I-V curves, V-t curves and Ramp information is a spec change.

Of course it is a different question what the tools actually do with
the data that is not supposed to be there.  If they use it, they
actually violate the spec, in my opinion.  On the other hand, Greg has
a good point about the user of the model getting confused and possibly
expecting different results not knowing what is used or not.  But why
should we allow redundant data if it is not supposed to be used 
(according to the paragraph above)?  This relates to some other issues
to which I will return below.

Problem #2
==========

Matt brought up that the above section does not include the voltage
range, and reference voltages, and asks where those should be placed.
In my opinion they are all mentioned in the above section if we look
at the meaning of the words "specification information" carefully.
This is arguable, but to me the comma after the word "information" is
an indication for a list, which means that the words "specification
information" do not refer to the following items in the sentence ([GND
Clamp] and [POWER Clamp], and C_comp), but to all other IBIS parameters
and subparameters not listed here.  According to this argument
everything goes, including voltage range, reference voltages, Vinh,
Vinl, Vref, Cref, etc.  And using the previous argument, these should 
all be in the top-level model, or else they must be ignored.

And please don't call me a lawyer, some times we just have to look at 
the words the way they are written :-)

On the other hand, if the comma in the above sentence was intended to
mean "i.e.", the previous argument is invalid, and the remaining
keywords should all be listed in this section one by one with
appropriate explanations on where they should be placed.

Problem #3
==========

Matt raised the following question:

"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?"

The answer is in the spec/BIRD58:

| 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.
|

Problem #4
==========

Steve asked the following question:  "Do models that are turned on in 
one transition carry over, still turned on, into the opposite 
transition?" with examples to illustrate the issue.  I discussed this 
with Bob at length and I concluded the following.

I feel that the meaning of the delay parameters may not be clear to
most readers (which included myself).

Think of an open sink buffer for the next four points.  This buffer
has a pulldown driver only, which is basically a GTL type buffer. 
Let's assume that the model uses the [Driver Schedule] keyword.  The
meaning of the delay parameters then is as follows:

a)  Fall_on_dly => is the amount of time that elapses from the internal
simulator pulse initiating a FALLING edge and the actual t=0 time of
the V-t curve that turns ON the I-V curve of the pulldown device.  
This is the normal way to turn on a driving device.

b)  Fall_off_dly => is the amount of time that elapses from the internal
simulator pulse initiating a FALLING edge and the actual t=0 time of
the V-t curve that turns OFF the I-V curve of the pulldown device.  
This can turn off a driving device before the next edge occurs.

c)  Rise_on_dly => is the amount of time that elapses from the internal
simulator pulse initiating a RISING edge and the actual t=0 time of
the V-t curve that turns OFF the I-V curve of the pulldown device.  
This turns the driving device off on the subsequent edge, and is 
the normal way of turning it off.

d)  Rise_off_dly => is the amount of time that elapses from the internal
simulator pulse initiating a RISING edge and the actual t=0 time of
the V-t curve that turns ON the I-V curve of the pulldown device.  In 
my opinion this case is purely theoretical and impractical.

The point I am trying to make here is that the pulldown can be turned
on/off by either one of the two internal pulses, and this is defined
through the particular delay variable used.  An equivalent truth table
can be made for a pullup device.  For a complementary driver (which is
a combination of both pullup and pulldown devices) the truth
table for these parameters is as follows:

a)  Fall_on_dly => is the amount of time that elapses from the internal
simulator pulse initiating a FALLING edge and the actual t=0 time of
the V-t curve that turns ON the I-V curve of the pulldown device and
turns OFF the I-V curve of the pullup device if it was not turned off
by the Rise_off_dly parameter yet.  This is the normal way of doing a
high to low transition.

b)  Fall_off_dly => is the amount of time that elapses from the internal
simulator pulse initiating a FALLING edge and the actual t=0 time of
the V-t curve that turns OFF the I-V curve of the pulldown device.
Theoretically, this parameter could also be used to turn on the pullup 
device from the falling internal pulse, but it is highly unlikely that 
it would be done in practice.

c)  Rise_on_dly => is the amount of time that elapses from the internal
simulator pulse initiating a RISING edge and the actual t=0 time of
the V-t curve that turns ON the I-V curve of the pullup device and
turns OFF the I-V curve of the pulldown device if it was not turned off
by the Fall_off_dly parameter yet.  This is the normal way of doing a
low to high transition.

d)  Rise_off_dly => is the amount of time that elapses from the
internal simulator pulse initiating a RISING edge and the actual t=0
time of the V-t curve that turns OFF the I-V curve of the pullup
device.  Theoretically, this parameter could also be used to turn on
the pulldown device from the rising internal pulse, but it is highly
unlikely that it would be done in practice.

(I hope I got it right...)  Note that even though these parameters use
the words "on" and "off", they don't always refer to the devices being
turned on and/or off.  This may partially be the reason for much of
the confusion.

So given all this, if we are modeling a complementary buffer, which
has only on-delays (rise_on_dly and Fall_on_dly) specified in its
model, the previous state must be extended to the time when the new
transition begins.  This may result in a situation in which a buffer
with more than one stages will have crowbar currents between one or
more of its delayed and/or non delayed stages.

Notice that there is one special case that seems impossible with the
above tables.  Here is a falling edge example to illustrate that:  The
pullup of a complementary buffer is turned off by the falling edge
without delay but the pulldown is turned on with a delay by the same
edge.  This combination can still be modeled by separating the pullup
and pulldown halves of the buffer into two open_??? models.

Problem #5
==========

Quote from Matt:

"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."

Keeping in mind the reasoning from the previous point, this is not a 
contradiction.  Note that the examples mentioned in this quote use 
two "ON" delays.  However, note that one of the "ON" delay actually
turns the device off.  So these examples correctly show that the 
scheduled device started and ended in the same state (OFF).

Problem #6
==========

Quote from Matt:  "Must at least one of the delay times be specified
or can all four be NA?"

Given the example in the previous problem and the requirement that the
model starts and finished in the same state, one may quickly realize
that only five combination of the delay parameters are valid.  One of 
the invalid combinations is the four NAs.

Problem #7
==========

I would like to revisit the issue of C_comp.  First of all, my 
statement in the last teleconference was not entirely correct, which 
will become apparent from the following thoughts.

In the meeting I suggested that having one C_comp in the top-level 
model may cause less accurate simulation results, because the 
simulator has to compensate for the effects of C_comp in the V-t 
curves.  My reason was that the independent V-t curves in the models
of the separate stages requires that we know what C_comp is for each 
of those stages, and a combined value in the top-level model is not 
sufficient.  Mike basically seconded this idea in his EMAIL response.

After thinking about this some more I realized that this is only true 
if the models of each stage were generated independently, that is 
completely separated from each other in the netlist.  However, one can 
also make a model for each stage by just disabling the stages that are 
not needed for the model of the particular stage being modeled.  If 
models are generated with this method, the capacitance of the disabled 
stages will still load the V-t curve of the one stage that is being 
modeled, therefore a combined C_comp is what should be used in the 
simulators for compensating the V-t curves.  This would suggest that 
the proper place for C_comp is in the top level model.

So this really boils down to what technique is used during the 
generation of the V-t curve data.

Given the argument in the first point, it may make sense to keep 
C_comp in the top level only, and instruct the model maker that the V-t 
curves of the stages should always be generated by keeping the whole 
buffer in the netlist, only disabling the unwanted sections using 
the controls of their prediver circuit.

Another reason to keep all of the "remaining parameters" in the top
level model is that the staged models are really used only for
describing the driver, hence the name [Driver Schedule].  The
information that is used for receiver mode operation are supposedly all
in the top-level model (if we agree with what I wrote above).

Summary
=======

The situation is not as bad as I thought before.  With a few
clarifications and/or rewording I believe that the existing spec is
good and useful without any functional changes.  I am sorry that this
turned out this long, but this is a fairly complicated problem.

I am eager to hear your comments.  Sincerely,

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

---

From: Bob Ross <[email-masked]>
Date: Wed, 31 Mar 1999 17:18:59 -0800

Arpad:

You have made some very good observations.  I have a few comments in
your text in UPPERCASE.  My suggestion is to consider the points and
then draft a BIRD58.1 which will force some choices.  We then have
a reference for more discussion.

Bob Ross
Mentor Graphics

SOME CHOICES WERE MADE AT THE TIME OF ADOPTION BASED ON SOME EXISTING
PRACTICAL CONSIDERATIONS: 

(1) THE TOP LEVEL MODEL CONTAINED IN ONE LOCATION THE "INPUT" OR "HIGH-Z"
STATE INFORMATION FOR EASY REFERENCE.  (THUS C_COMP AND THE CLAMPS.)  THE
ASSUMPTION WAS THAT THESE WERE ALWAYS IN THE BUFFER REGARDLESS OF ANY
SCHEDULED TURN ON OR TURN OFF OF ANY BUFFER.  THIS MADE IT EASIER TO LOCATE
THESE PARAMETERS.  (I NOW WOULD RECONSIDER THIS.)

(2) THE "SPECIFICATION" PARAMETERS, "POLARITY" AND "MODEL TYPE" OF THE
TOP-LEVEL PROVIDED THE OVERALL DEFINITION.  (THUS, WE DID NOT HAVE TO
DEAL WITH ANY CONTRDICTORY INFORMATION IN THE SCHEDULED MODELS.

(3) THE SCHEDULED MODELS COULD FUNCTION AS COMPLETE, INDEPENDENT MODELS
(ONE APPLICATION WOULD BE TO MODEL DOUBLE-STRENGTH, PARALLELED BUFFERS
USING DRIVER SCHEDULE KEYWORD.)

(4) WE WANTED TO ADD DRIVER SCHEDULE WITH A MINIMUM OF NEW, SPECIAL SYNTAX
RULES WHICH WOULD HAVE COMPLICATED THE IBISCHK3 PARSER WITH A LOT OF NEW
SPECIAL CASES.  ALSO, THE MODEL DEVELOPER WOULD THEN HAVE DIFFERENT RULES
FOR DIFFERENT SITUATIONS.

(5) THE TOP-LEVEL MODEL PROVIDED A "STUB" MODEL OF LOWER ACCURACY AND
WITH A POSSIBLE "GOLDEN WAVEFORM"  THIS WAS LEFT OPEN.  AT THAT TIME,
SIMULATORS WERE JUST ADDING THE DRIVER SCHEDULE FEATURE, SO THIS 
PROVIDED A LOWER-LEVEL ALTERNATIVE (JUST LIKE USING RAMP IN PLACE
OF UNUSABLE OR BAD WAVEFORM DATA).

I WOULD PROBABLY MAKE A FEW DIFFERENT CHOICES TODAY.  HOWEVER, THIS
PROVIDES SOME OF THE OVERALL CONTEXT FOR WHICH THE DRIVER SCHEDULE
KEYWORD IS BASED.

Problem #2
==========

IN THIS CASE, I FAVOR USING THE GIVEN VOLTAGE RANGES AND REFERENCE
VOLTAGES THAT EXIST IN THE SCHEDULED MODEL.  THEY ARE REQUIRED AND
NEEDED IF THE SCHEDULED MODEL COULD EXIST AS A COMPLETE MODEL BY ITSELF.
THE VOLTAGE RANGE AND REFERENCES ARE REALLY RELATED TO THE PULLDOWN
AND PULLUP KEYWORDS AND RAMP AND WAVEFORM DEFINITIONS OF THE SCHEDULED
MODELS.  SO SCHEDULED MODEL VOLTAGES SHOULD OVERRIDE THE TOP LEVEL
VOLTAGES.  I WOULD FAVOR ADDING CLARIFICATION ON THIS.

THE TOP LEVEL VOLTAGES WOULD STILL BE USED FOR THE TOP-LEVEL MODEL
DATA.

Problem #3
==========

YOUR EXAMPLE IN PROBLEM #4 GIVES A CASE WHERE AN OUT OF PHASE PULLDOWN
(BASED ON THE RISE_ON_DLY AND RISE_OFF_DLY) PROVIDES AN PULLDOWN
CURRENT THAT REDUCES THE OVERALL DRIVE STRENGTH.  ALSO, IT IS THEORETICALLY
PERMITTED TO SCHEDULE A FALL_ON_DLY LATER THAN A FALL_OFF_DLY TO GET
AN OPPOSITE POLARITY EFFECT TO REDUCE THE STRENGTH.

THIS IS HOW WE COULD DEAL WITH DIFFERENT POLARITIES IN THE SCHEDULED
MODELS.  WE DID NOT USE THE SCHEDULED MODEL POLARITY INFORMATION, BUT
MADE EXPLICIT REFERENCE TO LOW-TO-HIGH OR HIGH-TO-LOW TRANSITION 
DEFINITIONS.

Problem #4
==========

USING "OPEN_* BUFFERS IS ACTUALLY THE PREFERRED APPLICATION.

HOWEVER, WITH TOTEM STRUCTURES AND WITH 2-RISING AND 2-FALLING WAVEFORMS,
YOU CAN ALSO GET THE INDIVIDUAL PULLDOWN AND PULLUP TURNON AND TURNOFF
CHARACTERISTICS OF THAT SCHEDULED MODEL (AND WHATEVER CROWBAR CURRENT
OR LACK OF CROWBAR CURRENT THAT MAY BE PRODUCED).

Problem #5
==========

Quote from Matt:

Problem #6
==========

I AGREE THAT 4 NAS IS NOT ONLY MEANLESS, BUT YOU DO NOT KNOW WHAT
STATE THE BUFFER IS IN (LOW OR HIGH FOR A TOTEM POLE OUTPUT) OR
(HIGH-Z OR ON FOR AN OPEN_* OUTPUT)

Problem #7
==========

ONE PRACTICAL METHOD IS TO SET C_COMP TO 0 IN ALL SCHEDULED MODELS
AND USE THE TOP-LEVEL C_COMP AS A LOAD.  THIS IS ALREADY COMPATIBLE
WITH SOME OTHER FORMATS AND SUPPORTS SEEING THE C_COMP IN THE HIGH-Z
OR INPUT MODE.

THE OTHER METHOD, AS YOU SUGGEST IS TO DISTRIBUTE THE C_COMP IN THE
INDIVIDUAL SCHEDULED STAGES AND PRODUCE THE CORRESPONDING WAVEFORMS
ASSUMING THOSE LOADS.  WE MAY PUT C_COMP = 0 IN THE TOP-LEVEL MODEL.
WE WOULD HAVE TO SPECIFY THAT IN THE INPUT OR HIGH-Z STATE, ALL OF
THE SCHEDULED DRIVER C_COMP VALUES WOULD BE ADDED.  I WOULD ALSO
SUPPORT ALLOWING THIS, BUT THIS WOULD CHANGE THE SPEC.  THE TOP-LEVEL
MODEL C_COMP VALUE, IF ANY WOULD STILL SERVE AS A LOAD TO THE SCHEDULED
MODELS.  ALSO, THE TOP-LEVEL C_COMP WOULD SERVE AS THE TOTAL C_COMP BOTH
FOR DRIVER AND INPUT OR HIGH-Z MODE IF IT WERE USED AS A STUB MODEL.  HOWEVER,
IT IS ALREADY KNOWN TO BE NOT AS ACCURATE AS THE FULL DRIVER SCHEDULE
MODEL.  THEREFORE THIS IS NOT A MAJOR PROBLEM.

Summary
=======

I AGREE, BUT WE HAVE SOME CHOICES TO MAKE.  WE CAN GIVE MORE DETAILS
AS AN EDITORIAL INTERPRETATION BASED ON WHAT PEOPLE WANT AND HAVE
ALREADY IMPLEMENTED

Arpad Muranyi
Intel Corporation