Subject: [IBIS-Users] Driver Schedule keyword ambiguities
From: Muranyi, Arpad (arpad.muranyi@intel.com)
Date: Tue Sep 16 2003 - 12:54:48 PDT
All,
As I promised in the last IBIS Open Forum Teleconference, I am
posting a message about the issues that were discovered with the
[Driver Schedule] keyword recently.
1) Under the Usage Rules, the end of the 3rd paragraph says the
following in the current specification:
| ... Also, all other keywords not shown
| in the above list will be ignored in the scheduled model(s).
The question becomes, what about the subparameters? Are they
also supposed to be ignored in the scheduled models?
For reference, I looked up the subparameters of the [Model]
keyword:
| Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp,
| C_comp_pullup, C_comp_pulldown, C_comp_power_clamp,
| C_comp_gnd_clamp, Vmeas, Cref, Rref, Vref
Interestingly, the "Other Notes" of the [Driver Schedule] keyword
says that:
| Notice that the C_comp parameter of a multi-stage buffer is
| defined in the top-level model. ...
(As a comment on style I have to mention that the word "Notice"
is improper here, because this is the first time C_comp is mentioned
in the entire [Driver Schedule] description, so there was actually
nothing to notice about C_comp before the reader got this far...).
Regarding the main subject of this writing, however, notice :-) that
C_comp is a subparameter. We agreed verbally in the last
teleconference that we should just make the text in the first quote
include all keywords and subparameters. So the suggested text would
read something like:
| ... Also, all other keywords not shown in the above list and all
| subparameters will be ignored in the scheduled model(s).
This is hopefully an easy change (clarification) in the specification.
2) There is another problem with the wording of the [Driver Schedule]
keyword. This is related to our four 7-line long famous one-sentence
paragraphs describing the meaning of the on/off delay parameters. The
issue is that the word "event" (towards the end) is not defined.
Because of that, some ambiguities may arise when two of the parameters
are NA so that the given numbers are both in the ON or OFF delay
positions. The ambiguity will happen when the two numbers are not
equal and the stimulus is shorter than the delay. For example, the
following example is well defined, there are no problems with it:
| Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly
MODEL_OUT 0.0ns NA 0.0ns NA
However, the next example has a problem:
| Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly
MODEL_OUT 20.0ns NA 0.0ns NA
Imagine a test case, in which the stimulus begins at 0 V, and has a
periodic short pulse with a pulse width of 5 ns. The pulses repeat
every 50 ns. At time zero, the output will be 0 V, since the stimulus
is also 0 V. Given the above delay values, the first rising edge
of the stimulus would initiate a delay for the output to go high
20 ns later. However, the question is, what should the falling
edge do which comes 5 ns after this delay got initialized and before
the output could switch due to the delay? Should it cancel the
unexpired delay, or should it let it run its course?
In the first case, the output would remain at 0 V forever, because
the falling edge stimulus will always cancel the unexpired rising
edge delay. On the other hand, if the delay is allowed to run its
course, we would see a rising edge on the output 20 ns after the
rising edge stimulus, even though there was a falling edge stimulus
that should have generated a falling edge on the output (which we
didn't see, because the output was at 0 V during this time). The
output would actually go low at the next time the stimulus goes low,
because at that time the output will be in the high state already.
Here is an ASCII attempt to illustrate this:
Stimulus:
__ __ __
___| |________________| |________________| |____________...
Output:
____________ ___________ ____...
_____________| |_______| |_______|
Note that this problem only occurs if the pulse width is smaller
than the delay, in other words, the buffer is over clocked. Trying
to get a physical meaning to these delays I can imagine a design
that, being over clocked, will not switch at all, but I could also
imagine a design that is kind of pipe lined and would generate the
above waveforms. To me it seems that both interpretations can be
correct.
The question in terms of how the spec is written is whether the
"event" refers to the edge of the stimulus which starts the delays,
or whether the "event" occurs when the timer expires and sets the
time to t=0 for the Vt curve to generate the output transition.
We would either have to limit ourselves to just one of these
possible cases in the IBIS spec with a clarification to this
keyword, or if both results are desired, we need to add another
parameter that allows a selection mechanism. Even though
technically perhaps more appealing, this option seems to be
less favorable, since there is a note already at the end
of this keyword that says:
| 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.
Which basically says that this keyword was just an interim solution
until we have something better. Because of that I would not favor
making improvements to [Driver Schedule], only clarifications.
With BIRD 75 we can achieve any kind of a buffer behavior now,
so we would not be stranded.
Having said that, which solution should we pick? The one that
produces a flat line on the output, or the one that still produces
a waveform? To be consistent with the way Vt curves are handled,
it seems that the "flat line solution" may be what we need here.
This is because due to current algorithms, a regular buffer having
long Vt curves will also respond with a flat line on the output
when stimulated faster than the Vt curves allow.
Note that this situation would also arise with other combinations
of delay numbers when they are in the On-On or Off-Off places, have
different values, and the stimulus is shorter than the delay values.
The above is just one example to illustrate the issue.
I would like to combine these two problems in the same clarification
BIRD to the [Driver Schedule] keyword. Please send me your comments
and suggestions so I could write a useful BIRD.
Thanks,
Arpad
====================================================================
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Tue Sep 16 2003 - 14:12:39 PDT