Subject: Re: [IBIS] BIRD 75 comments
From: Ross, Bob (bob_ross@mentorg.com)
Date: Wed Aug 28 2002 - 19:42:51 PDT
Arpad and All:
Thank you for your comments. Several others have expressed some
additional points privately, and I expect more discussion at
the next IBIS meeting.
Your main concerns are discussed here:
A. Move [External Model] from within [Model] to the same level as [Model]:
People have expressed preferences for each approach. From a syntactical
point of view, I believe either approach will work. Chris Reid stated
that one of reason for positioning [External Model] within [Model] is
to support compatibility with IBIS where sufficient, but allow additional
electrical processing capability with other languages (SPICE, -AMS) if
needed. Extended model behaviour formatted within the existing
[Model] is a constraint and "forces" the descriptions to fit within much
of the existing IBIS conventions. I view this as an advantage because
it leverages off of existing EDA tool methodology and notation.
Chris mentioned that [External Circuit] could be set up for general
structures outside of the IBIS model constraints. This is the way
to deal with new features and approaches. However, the user (or EDA
tool vendor support group) will need to configure the model to each
EDA tool.
I did mention documentation concerns. This may not be the biggest issue.
I initially imagined that BIRD75 would then expand to nearly all of
Version 4.0 with all instances and references to "model" or [Model] or
other variants reviewed and changed (only were appropriate) to "model and/or
external model" - a large, probably mistake-laden, and unreadable document
The existing BIRD75 does list some exceptions, but the alternative approach
might be to document [External Model] separately with general pointers and
note the exceptions. Both approaches intend to capure the new information
in one area.
You and others have mentioned a few specific points. New parameters are
always an issue - such as "vcross' for differential receivers. This
will be an issue for both approaches because we still have to interface
the new parameters to a selection of EDA tools. The extended language
capability does allow for the work-around of writing code to process
the parameter directly and reporting back the result in an existing
parameter. For example, any new threshold definition or interactive
combination can be coded up and transformed back into the existing
thresholds defined by IBIS (eguivalent to D_receive) - essentially
into '0', '1' and 'X' by any of the languages.
You also discovered a problem with [Ramp] being required for I/O and
Output buffers. I missed that. Lynne Green favored keeping the [Ramo]
or general speed information. My inclination is to add the rule that
[Ramp] is not required when [External Model] is used.
I am not sure there exists an overwhelming technical reason that
requires [External Model] to be positioned at one level versus another.
But I am open to exploring all of the concerns.
2. Parameterization
BIRD75 states that parameterization can be handled with the specified
language. My feeling is that BIRD75 does not prevent finding a
general parameterization mechanism within IBIS. However, I think this
can be investigated separately and a solution proposed in another BIRD.
3. Changing "port" to "terminal"
One of the biggest problems of BIRD75 was coming up with terminology and
also fitting it in with some physical-based IBIS terminology (pin, die)
and some electrical terminology (node). Some terms were interoduced
such as die nodels and internal nodes. The "port" notation was added
for module descriptions that might be conceptually positioned within a die.
The "port" usage, consistent with VHDL-AMS and Verilog-AMS, provides the
communication path from one module to another. Each named port corresponds
to an input or output connection point. This could differ from electrical
"n-port" parameter electrical concepts.
Various languages provide types of ports. For example, VHDL-AMS has
quantity ports, terminal ports and signal ports.
I would prefer not to make arbitrary changes without expert guidance.
I believe "port" is technically correct, and "terminal" may collide with
one convention.
4. Still a misunderstanding on the [Series Current] and [Series MOSFET]
comment.
I will have to work with you on this directly on this.
Bob Ross
Mentor Graphics
"Muranyi, Arpad" wrote:
>
> Bob,
>
> This is a public reply so (hopefully) others can also join the
> discussion.
>
> Thanks for all the editorial fixes, clarifications. There are a
> few technical items left which I would like to argue.
>
> The biggest one is regarding whether the [External Model] keyword
> should be inside or outside the old [Model] keyword. You call
> this debate "practical" vs. "purity". You raised basically two
> reasons to keep it inside. One is that taking it out would require
> a bigger editorial effort to make all the necessary changes even
> in the old sections of the spec. I agree that this would be a
> big job, but I feel that it would be well worth it. (This is the
> "practical" part).
>
> The problem I see with keeping it inside is that by doing that
> we introduce a bunch of rules which do not necessarily make
> engineering sense. (This would be the "purity" part). A newbe
> model maker would be utterly confused about why certain things
> have to be in certain ways, and we would have to end up teaching
> more history than technical content in our IBIS classes. That
> is a very "practical" problem in my mind. We need to be user
> friendly with our syntax, otherwise we will get more low quality
> models. It is hard enough to characterize the behavior of the
> buffers as it is, there is no need to make it harder with extra
> historical baggage. There are other problems with this approach
> also.
>
> The old [Model] keyword requires a few subparameters or keywords.
> Such is the C_comp, but you did not mention in BIRD 75.3 that
> [Ramp] is also required. What do we do with these? Put "NA" in
> them and still use them just because the spec requires them, or
> establish new rules that they are not required if the [External
> Model] keyword exist? In the latter case we would introduce a
> bunch of conditionals which is also "impractical" in my opinion.
>
> Secondly, we have a few inconsistencies already because we didn't
> think ahead in time that some parameters (such as Vinh, Vinl) will
> need typ min max values. To solve these we invented the [Model
> Spec] keyword, but this keyword may not have everything we may
> need in the future. I am already starting to hear from design
> engineers that for differential receivers we will need more than
> just Vdiff (Vcross seems to be a new candidate) to do it right.
> These subparameters are still fixed, they are not arbitrarily
> extendable.
>
> The idea of having an [External Model] keyword outside the old [Model]
> keyword could fix all of our historical shortcomings from the past.
> Yes, there may be some overlap between the old parameters and the
> new parameters, but that should not cause any conflicts, because I
> can't imagine anyone using both [External Model] and [Model] for the
> same pin (or buffer).
>
> This leads me into the next subject which is related to parameterization.
> Since we do not know what holds the future, we will never know ahead
> of time what kind of (sub)parameters a model may need. (One good example
> is the evolution of the [Model Spec] keyword). As I mentioned above,
> this keyword may need further extensions maybe very soon. Doing this
> through the BIRD process will take too long for every change. Just like
> we wanted to get away from rigidity regarding the buffer model
> characteristics, I think we should also make these parameters flexible
> and extendable. Doing this would also allow arbitrary parameterization
> with [External Model]s. What I have in mind is a specification for an
> interface between the tool and the IBIS file, rather than fixed parameters
> (such as Vinh and Vinl) which we have today. The interface would allow
> the model maker to define a parameter and provide data for it. The
> tool would then use the definition and set up its actions based on that
> using the data from the IBIS file. This would be similar to the way
> custom measurements work in some of the already existing tools. Now
> don't ask me for details on this, because this is a new idea to myself,
> and I am not a tools programmer either. But this idea would keep the
> specification flexible and useful for a longer period of time.
>
> This is a smaller thing, but I would consider changing the word "port"
> to "terminal". Especially because the way you define and use it. I
> think many people would have a different idea about what a port really
> means, and this usage may disturb them. To it seems that a terminal
> could be a single node without any confusion, but ports always assume
> two nodes whether one is an ideal ground node or not. Does anyone out
> there know what the proper definition and usage of "terminal" and "port"
> are?
>
> Regarding my comments on [Series Current] and [Series MOSFET] (#19),
> I think you misunderstood it. My point is that in the BIRD you didn't
> list them as keywords which need the [Series Pin Mapping] keyword under
> the interaction limits. I just mentioned that they should also be
> listed there (if I understand it correctly).
>
> That's it for now.
>
> Thanks,
>
> Arpad
-----
Previous messages in thread chopped here.
-----------------------------------------------------------------
|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
This archive was generated by hypermail 2b28 : Wed Aug 28 2002 - 19:57:33 PDT