BIRD58 discussion

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
====================================================================
Received on Tue Mar 30 17:14:14 1999