Subject: AW: [IBIS] IBIS SUmmit minutes 6/13/02
From: Lenski Eckhard (Eckhard.Lenski@icn.siemens.de)
Date: Thu Jun 20 2002 - 23:10:09 PDT
please find my answers below
regards
Eckhard Lenski
Siemens AG
ICN WN OP TDC TC3
81359 München
Tel: 0049 89 722 27776
Fax: 0049 89 722 44692
Email: eckhard.lenski@icn.siemens.de
-----Ursprüngliche Nachricht-----
Von: Hassan Ali [mailto:Hassan.Ali@fidus.ca]
Gesendet: Donnerstag, 20. Juni 2002 22:27
An: ibis@eda.org
Betreff: RE: [IBIS] IBIS SUmmit minutes 6/13/02
I have a few questions relating to Eckhard's observations quoted below:
1. When models have "unreasonable" lead-in time on V-T curves I guess
the solution is to uniformly (i.e. for all the corners) trim the V-T
data so as to only remain with the rise or fall data that sufficiently
captures the rise/fall time. If by doing that, however, the time range
of the resultant V-T curves [i.e. for rise: time(Vhigh_max -
time(Vlow_min) ]is greater than the bit-width, what would be the best
way to correct the model?
>>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.
>>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 )
>>and for your last question: I see the only way to go back with this question to the vendor that he will do new
>>simulations for you.
>>so lead-in-time might also be one more point for ibis-quality-check-list
2. If for a given SPICE model, the output slew-rate of the buffer is
dependent on the slew-rate of the input stimulus, what would be the best
way to create useful V-T curves? Is their a rule-of-thumb for the
suitable slew-rate of the input stimulus?
>>We discussed that on thursday, and one solution is to make different simulations with different stimuli-slew-rates
>>and to see, when there is no more change in the output rising/falling behavior.
>>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.
3. Could anyone explain using a simple (driver->transmission line->load)
example how different simulators use V-I and V-T curves of an IBIS model
to compute voltages/currents on circuit nodes?
>>I hope that you will got some answers directly from the tool-vendors, because I only could tell you my
>>understanding how it might works.
Thanks.
Hassan.
-----Original Message-----
From: Guy deBurgh [mailto:gdeburgh@innoveda.com]
Sent: Tuesday, June 18, 2002 5:30 PM
To: ibis@eda.org
Subject: [IBIS] IBIS SUmmit minutes 6/13/02
...
On the subject of model creation, Eckhard noted that when creating IBIS
models from encrypted HSPICE models, model vendor must include enough
pre-driver stages so that the risetime of the input stimulus does not
effect the risetime of the final output stage. Five pre-driver stages
seems to be adequate. Eckhard also mentioned cases where models have
unreasonable lead-in time on V-T tables. The quality group should
address
these issue in their checklist.
-----------------------------------------------------------------
|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 : Thu Jun 20 2002 - 23:30:21 PDT