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 1993Received on Fri Dec 31 12:15:15 2004
This archive was generated by hypermail 2.1.8 : Fri Dec 31 2004 - 12:16:27 PST