Subject: RE: [IBIS] IBIS SUmmit minutes 6/13/02
From: Hassan Ali (Hassan.Ali@fidus.ca)
Date: Fri Jun 21 2002 - 07:23:45 PDT
>>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
This archive was generated by hypermail 2b28 : Fri Jun 21 2002 - 07:35:12 PDT