I am not sure whether I follow the details of this discussion, but I wouldn't implement variations of the IV/Vt checking routine based on the model type. I would just simply check for the existence of IV tables against the model type, and issue warnings or error messages based on that. And by existence I mean I would also check whether the table is all zero or not... Arpad =================================================== -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Bob Ross Sent: Friday, October 28, 2005 5:13 PM To: Angulo, John Cc: ibis; ibis-users Subject: [IBIS-Users] Re: [IBIS] Inappropriate I-V tables in open_drain/source model types John: The dual mode V-T waveform checking option is unnecessary. I now favor elevating the inconsistency to Error, but not change the existing V-T mismatch checking. The fact that the V-T checking is not consistent with a Model_type assumption does force the issue. (If the V-T checking was consistent with Model_type and the non-zero [Pullup] or [Pulldown] table was NOT included, then I would consider keeping this as a Warning.) The Error message forces the modeler or the user to address the problem. Then the checking will already be correctly in place when the Model_type inconsistency is addressed. Bob Angulo, John wrote: > At today's IBIS teleconference, I raised the issue of whether a bug > report should be logged against ibischk for its treatment of I-V tables > inappropriate to the model type. Specifically, there should be no > [Pullup] table, or at least no non-zero currents for the [Pullup] table > in a model using open drain/sink topology, and there should be no > non-zero [Pulldown] table in a model using open source topology. > > If an inappropriate I-V table is present (with non-zero currents), > ibischk issues a warning message. However, it goes on to check I-V/V-t > endpoint agreement using all the model's I-V tables. > > Should ibischk instead ignore the I-V table incompatible with the > model_type? A motivation for doing this is that sometimes model makers > mistakenly put internal bias characteristics for open_* parts into the > [Pullup] and [Pulldown] tables. Ignoring inappropriate I-V tables > during I-V/V-t checking would expose this by causing I-V/V-t mismatches. > > > However, if using the inappropriate I-V table causes an I-V/V-t > mismatch, the current parser behavior exposes the problem. > > So it may be valuable to report both when ignoring the table causes a > problem and when using the table causes a problem. I can report that at > least one popular SI tool does not ignore the inappropriate table. The > existing parser behavior has in fact encouraged this policy. It is not > safe for the SI tool to ignore one of the I-V tables the parser depended > on to "bless" the model, unless it does the alternative endpoint > checking itself. > > Would it be worth adding a separate I-V/V-t endpoint check under the > assumption of open_* topology to highlight models that depend on > significant currents in the inappropriate table? Would it equivalently > be worth elevating the inappropriate-table warning to an error? It > seems unsafe to drop the existing I-V/V-t test policy for open_* models. > > John Angulo > Software Development Engineer > Hyperlynx Products > Mentor Graphics Corp. > > ----------------------------------------------------------------- > |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 > -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC |------------------------------------------------------------------ |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 1993Received on Mon Oct 31 08:39:04 2005
This archive was generated by hypermail 2.1.8 : Mon Oct 31 2005 - 08:44:01 PST