Subject: Re: [IBIS-Users] Sticky problem in [Driver Schedule]
From: Bob Ross (bob@teraspeed.com)
Date: Fri Apr 18 2003 - 19:23:22 PDT
Michael:
[Driver Schedule] was added to IBIS so that IBIS could handle some common
buffer extensions (pre-emphasis (including P-channel kicker) and some
scheduled driver topologies). The implementation addressed these practical
concerns by adding scheduled FIRST-ORDER adjustments. However,
the architecture is technically flawed and inconsistent with the
rest of IBIS, when pushed to limit. So, I do not think it is worth
investing too much time to fix [Driver Schedule].
Here are some background thoughts:
- The specification and information content (Model_Type,
clamps, C_comp, Polarity, etc) was moved to the top level
model so that it was available in a known, convenient location,
especially for Input and High-Z operation. (Otherwise, it
would have been distributed in all scheduled models.)
- We did not add scheduling controls from a separate clock
or input control pins because of the single-pin I/O architecture
structure of an IBIS [Model].
- The intent of the scheduled models was to provide a behavioral
approximation to the model the first order effect. The scheduled
models are assumed to be totally independent of each other. In
real parts, I would expect some interaction.
- For simplicity, scheduled models were put in the existing [Model]
keyword to avoid introducing many new keywords and subparameters.
- However, all driver operation is handled only by the scheduled
models. For simplicity, the Top level model still contained
unscheduled set of I-V and [Ramp] or V-T characteristic for the
buffer for two reasons: (1) It was contained in the [Model] keyword,
and such information was already "required", (2) such
information provided a default approximation for tools that did
not have the [Driver Schedule] keyword implements - this was
probably a mistake, but consistent with the migration of IBIS
philosophy at that time. (We did not follow the master/slave
architecture where the master information also is used in
the driver simulation, and the slave models provide adjustments.)
- Clamps in scheduled models created separate issues. Do clamps
get switched in and out, or do they always remain active? This
was the reason for moving the total clamp information to the
top level where clamps are always active. The scheduled models
could have different Model_types, than the top level model, so
this was not helpful. (Since some of the capacitance is
introduced in clamps, the same questions would apply for
C_comp - below.)
- The biggest problem is C_comp. If it is truely distributed
within the scheduled models, does this capacitance also get
switched in and out? Or does it remain forever as a "load"
on other buffers. How do you really find out of how C_comp
is partitioned? The safest recommendation is to revert
to a behavioral philosophy and simply set C_comp = 0 in any
scheduled model. In that way, the top level C_comp is just
a passive load. This works in a consistent manner among tools
that handled C_comp differently, but this is still an area of
ambiguity.
All of these and perhaps other issues have created interpretation
issues, and probably inconsistent implementions. [Driver
Schedule] is useful as a practical first order adjustment.
However, its structure is flawed and not worth the effort
of trying to fix or improve it.
Bob Ross
(P.S., I cannot help noting that BIRD58.3 from your company
provide "improved" editorial revisions including some long
sentences.)
Mirmak, Michael wrote:
> 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.
-- Bob Ross Teraspeed Consulting Group LLC Teraspeed Consulting Group LLC 2926 SE Yamhill St. Device Modeling Division Portland, OR 97214 13610 SW Harness Lane 503-239-5536 Beaverton, OR 97008 http://www.teraspeed.com 503-430-1065 bob@teraspeed.com 503-246-8048 Direct|------------------------------------------------------------------ |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 - 19:34:01 PDT