Subject: RE: [IBIS-Users] Sticky problem in [Driver Schedule]
From: Beal, Weston (weston_beal@mentorg.com)
Date: Fri Apr 18 2003 - 17:12:04 PDT
Michael,
The IBIS specification used to say that the scheduled models must be of the same type as the master model. I think the intent was that they should all be outputs, but when some of this was clarified then that statement was clarified clear out of the spec. You dilemma shows the implied condition that the master and the scheduled models must be of some output type because all the timing relationships are based on the digital stimulus. Most people just don't push the spec THAT hard. :)
Regards,
Weston
-----Original Message-----
From: Mirmak, Michael [mailto:michael.mirmak@intel.com]
Sent: Friday, April 18, 2003 4:13 PM
To: ibis-users@server.eda.org
Subject: [IBIS-Users] Sticky problem in [Driver Schedule]
All,
We have just noted a strange issue when using the [Driver Schedule] keyword.
The specification clearly states that, for a "top-level" model under [Driver Schedule], keywords such as [Pulldown], [Rising Waveform], [Ramp], etc. are ignored. [Power Clamp] and [GND Clamp], however, are not (they would be ignored in the scheduled buffers).
In order to ensure a minimum of issues with tool interpretations of [Driver Schedule], I recently created a model which uses a top-level Model_type of "Input," while using scheduled models of "Open_source," "Open_sink," etc. An input-only top-level model is not explicitly prohibited by the specification, and, indeed, the parser flagged no errors or warnings with this construction.
Unfortunately, many tools, especially those for which users must explicitly create input stimulus nodes, will probably not be able to use this kind of construction successfully (where, for example, do you tie the input stimulus from the core on an input-only top-level buffer model?).
At this point, I can only conclude that a clarification BIRD should be written to add restrictions on the Model_type of [Driver Schedule] models. A parser bug would be inappropriate, since the parser is faithfully following the language of the specification.
Any thoughts?
- Michael Mirmak, Intel Corp.
|------------------------------------------------------------------
|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
|------------------------------------------------------------------
|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 : Fri Apr 18 2003 - 17:18:15 PDT