Subject: RE: [IBIS] IBIS SUmmit minutes 6/13/02
From: Peters, Stephen (stephen.peters@intel.com)
Date: Fri Jun 21 2002 - 08:39:33 PDT
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
This archive was generated by hypermail 2b28 : Fri Jun 21 2002 - 08:48:48 PDT