Subject: RE: [IBIS] IBIS SUmmit minutes 6/13/02
From: Lynne Green (lgreen@cadence.com)
Date: Fri Jun 21 2002 - 12:22:51 PDT
Hello, Hassan,
Some additional thoughts:
1) The data slew rate should be roughly the same as what the buffer
will see from the chip core. This means the data driver should be
roughly 3-5 stages, with the transistors sized similarly to the chip
core transistors in the logic stage preceding the buffer. This can
be done with an inverter chain, or with the actual on-chip circuit
(which might include logic gates or a MUX, for example).
2) The model maker does not need to re-simulate to remove the
leading and trailing "flat" zones. Rather, they need to remove any
data that comes before the signal change into the buffer (such as the
inverter chain in #1). They also need to remove the "flat" zone after
the three V-t columns have stabilized. Only the model maker has
enough information about how the model was simulated to make these
changes safely.
3) The IBIS specification does not say anything about how to handle
"over-clocked" circuits, where the bit period is less than the length of
the V-t table. Each EDA vendor must decide how to handle this in
their tools. You can ask your vendor for a new model, with V-t tables
built at your fast clock rate.
4) Related to 31, if you run a simulation to determine C_comp, the
edge time (and waveform) should be similar to what a signal arriving
from elsewhere on the board (that is, from a driver) would look like.
This will typically be much slower than the edge rate of a signal
arriving from the core.
Best regards,
Lynne Green
Cadence Design Systems
-----Original Message-----
From: Peters, Stephen [mailto:stephen.peters@intel.com]
Sent: Friday, June 21, 2002 8:40 AM
To: 'Hassan Ali'; 'ibis@eda.org'
Subject: RE: [IBIS] IBIS SUmmit minutes 6/13/02
Hi Hassan:
On your question "Is there an explicit rule for what that [rise and fall
time] duration
should be?", a V-T table should include enough points to span the time it
takes the output to switch from one logic level to another. For example,
for a [Rising Waveform] table the first voltage point in the table should be
the quiescent output voltage at the low state, the last voltage point in the
table should be at the quiescent output voltage at a high state. Also, I
would expect the [Falling Waveform] table's first voltage point to be the
same as the last point in the corresponding [Rising Waveform] table (and
visa versa).
Regards,
Stephen Peters
Intel Corp.
-----Original Message-----
From: Hassan Ali [mailto:Hassan.Ali@fidus.ca]
Sent: Friday, June 21, 2002 7:24 AM
To: ibis@eda.org
Subject: RE: [IBIS] IBIS SUmmit minutes 6/13/02
>>I had in mind an example, where the risetime started at about 50ns and
the falltime started at about 100ns, so
>>even if you corrected the models by the same timevalue for rising and
falling, there still would be a lead-in-time
>>of about 50ns for the falltimes. And the model was supposed to work
with 100MHz.
Thanks, Eckhard for your response. I guess then, both two situations
should be covered in the ibis-quality-check-list. i.e. time duration of
all (min, typ, max) the V-T curves for rise and fall. But the check
won't be possible without specifying the maximum bit-rate that the model
is designed for. Or would that max. bit-rate info be extracted from the
V-T curves duration? Is there an explicit rule for what that duration
should be?
>>Your idea of trimming is not so easy, because what you usually got in
the models with rising-falling-waveforms is
>>the behavior of the break-before-make-scenario , or in other words,
you see the behavior of the outputstage, during
>>switch-off of the low-transistor and the switch-on of the
high-transistor ( and vice-versa ).
>>( usually there is a time-window during which both are conducting (
cross-bar-current), and these informations are
>>also needed for the simulation. So I
>>think trimming the lead-in-time is a dangerous thing to do ( without
knowing the outputstage-behavior )
I understand that, but I believe the pronounced lead-in time is a
function of initial conditions which may not exist during continuous
operation of the buffer. I had such a problem with a clock driver and I
successfully trimmed the V-T curves. The IBIS/SPICE simulation results
matched very well for all the corners.
Of course a clock driver is a special case with 0101010101... bit
sequence. A different bit sequence may break the model. And that
suggests that a full evaluation of an IBIS model should also include
testing with different bit-sequences and comparing the results with the
SPICE output.
>>That's why I tried to make this rule of thumb of using at least 5
stages and an stimulus of 1ps, because these 5
>>stages should be enough, to get an realistic stimulus of the last
stage.
>>But I think this will also be a point we have to discuss in the
ibis-quality-group as well.
I think it's dangerous to fix a number for the stimulus rise time and
number of output stages. 1ps risetime/at-least-5-stages may be good
enough now but may not suite future technologies. I think it should be
sufficient to put a guideline that one should include sufficient number
of output stages to make the driver's output slew-rate independent of
the slew-rate of its stimulus. But there I have a question: are all
output buffers designed to give a fixed output slew-rate for all
stimulus slew-rates? Aren't there any output buffers designed to give
output slew-rates dependent on the stimulus slew-rate?
Thanks.
Hassan.
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with 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 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
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with 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 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
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with 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 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 : Fri Jun 21 2002 - 12:31:15 PDT