Subject: RE: [IBIS-Users] Sticky problem in [Driver Schedule]
From: Mirmak, Michael (michael.mirmak@intel.com)
Date: Fri Apr 18 2003 - 17:29:27 PDT
Weston,
Good points! This is an esoteric case, for many reasons, but I wasn't just being pedantic (at least, not here :) ). This is actually a lead-in to a larger issue.
My actual intent was to try and separate out the top-level effects from the scheduled effects to investigate the treatment of different delays, plus clamps and c_comp, by various simulation engines. In order to ensure I wasn't seeing the top-level effects "poison" the scheduling, I wanted to build the simplest top-level models possible -- a 0 mA clamp input model seemed the most simple way to start, even if it breaks the intent of the spec.
We have a suspicion here that the scheduling instructions in the spec are written in such a way as to be easily misinterpreted by users and tools (for example, each delay parameter is described using a single sentence seven lines long!). This case was just a crude illustration of some of the unintentional side-effects of the way the current text is put together.
We'll be preparing some test cases and perhaps even a presentation or paper on this issue in the near future. Stay tuned...
- Michael Mirmak, Intel Corp.
-----Original Message-----
From: Beal, Weston [mailto:weston_beal@mentorg.com]
Sent: Friday, April 18, 2003 5:12 PM
To: ibis-users@eda.org
Subject: RE: [IBIS-Users] Sticky problem in [Driver Schedule]
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
|------------------------------------------------------------------
|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:33:46 PDT