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 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