[IBIS] Comments on BIRD94 - Clarification on [Diff Pin] Parameters

Aprad:

BIRD94 deals with a number of issues, but I have expressed
concerns on the impact and perhaps intended or unintended
concequences of the proposed resolutions. I expect that each
of the several changes needs to be considered carefully.

As a formal comment, I am adding below our Future committee
e-mail correspondence introducing several concerns.

Bob

--------------------------
Arpad:

We can get into details later. The [External Model]
differential capability is more restricted because it
supports four new Model_type arguments (I/O_diff, Input_diff,
etc.) True differential capability is available only through
[External Model] since the the A_signal_pos and A_signal_neg
interfaces have to exist in one model. So the [Diff Pin]
setup has to apply to both sides of the same model.

Psuedo Differential setups are based on two occurances
of A_signal and [Diff Pin] mappings - the same as standard
IBIS.

Requiring the same Model_type makes sense in most cases,
I still want to proceed carefully here to be sure there is
not a case where you might want a different Model_type for
unsymetrical or symetrical operation. I am thinking of some
hypothetical situations, but may stumble upon a practical
application.

Bob

Muranyi, Arpad wrote:

> Bob,
>
> Thank you for your response. I would like to single out only one
> question right now.
>
> I agree with you that it may be technically better to require only
> that the model types are matched. In fact that is how I first
> started to write the BIRD. However, I changed it, because when I
> got to the [Model Selector], I realized that this would be a parser
> nightmare. And since the *-AMS extensions can provide good models
> for the cases you mentioned (and I had in mind), I thought this would
> still be reasonable compromise.
>
> Do you see a good way to handle the parsing and error checking if we
> only required the model types to be identical?
>
> By the way, this is what the [External Model] says currently:
>
> | The [Diff Pin] keyword is still required within the same
> | [Component] definition when [External Model] describes a true
> | differential buffer. The models referenced by each pin listed
> | under [Diff Pin] MUST be the same.
>
> which I assume refers to the [Model] names, not the model types.
>
> We can continue the discussion on the rest another time...
>
> Arpad
> ==================================================================
>
> -----Original Message-----
>
> Hi Arpad:
>
> First, nice job in capturing some issues and proposing some
> changes.
>
> Also, Michael raised separately on possible weaknesses
> in the existing and Version 4.1 regarding testing model_type
> mismatches - with or wirhout [Model Selector]. In fact,
> our testing is weak in this area. While related to this
> proposal, what we do with parser advances is a separate
> discussion.
>
> This proposal will need a technical review of each change.
> I am concerned about unintended consequences of some
> changes.
>
> Main items:
>
> Default threshold vdiff 200 mV and ambiguous language - agree
>
> [Model Selector] additions - agree - adding new features
> is an exponentional back fill problem in the Specification.
> [Diff Pin] came first.
>
> Same [Model]s, or [Model Selector]s - concerned about the
> constraint. Sometimes different models with only a Polarity
> difference are used so that differential each pin operation
> can be displayed simultaneously more easily in some tools.
> Also, unsymetrical buffers
> should be supported (e.g., CAM bus standard for automobile
> wiring, possibly as a phasing trick for using two models with
> different [Driver Schedule]s in them in non-symetrical
> current-mode differential operation pre-emphasis.
>
> Different Model_types - Bad, not expected, but concerned about
> how to limit. There might be real differential, unsymetrical
> combinations using Open_source on one buffer and Open_sink for
> the other buffer. But I agree that some combinatons are
> meaningless. (Input on one side, Output on the other.) So
> its a decision on how far to spec. - (BIG table of combinations
> or a general statement, or ignore and assume useful models will
> be correct). Other than testing, how bad is this mismatch issue?
>
> NA for Input or I/O assignament defaulting to "0" - concerned
> because it is specified as "0" and some model makers
> unfortunately use this. I would just let that stand or
> just add a suggestion that numerical values be used.
>
> I started to comment in more detail below, but the main
> points got lost.
>
> So I think we can either issue the BIRD for discussion
> in the Forum and Futures group or hold off and do the same
> before issuing it.
>
> Bob

--------------------------

-- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
503-750-6481                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@teraspeed.com
-----------------------------------------------------------------
|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