Subject: RE: [IBIS] BIRD 75 comments
From: Muranyi, Arpad (arpad.muranyi@intel.com)
Date: Thu Aug 29 2002 - 10:28:38 PDT
Bob,
Thanks for your response and for educating me about the terminology
using the words port, terminal, etc. in a broader sense as the AMS
languages do it. In that perspective it makes a lot more sense now.
I was only concerned, because of some conversations I had with RF guys
(primarily ADS users) who use the word "port" with special and mysterious
emphasis. Port as opposed to probe, kind of like ... oh the port is
different, oh, you don't know what it is? It is not the same thing,
... it is something very special, it is a ***port***, its not just a
measuring point. But what is it, how are they different? Well, it is a
***port***, not a probe... Sorry for the sarcasm, RF guys, didn't mean
to hurt anyone.
I didn't want to fall into the mistake of using that word in a single
minded, special way where people can read a lot of different things into
it. The explanation you gave is good, perhaps a better definition upfront
(using the words from your message) may help to put the reader into the
correct mind frame.
In order to help the decision and not get rat holed into this discussion
about the location of the [External Model] keyword I would like to look at
it from a distance. In summary, the fancy specmanship parameters and
measurements I brought up can be done inside the model. So the model
will decide when it saw a good signal and then just signal it with a
purely digital output whether it was good or bad. From that point of
view we wouldn't need the extended capabilities I mentioned regarding
these parameters. This puts more burden on the model maker, but the
model itself could take care of it. I can live with that, this reduces
the dependency on the tool's measurement capabilities.
However, because this could eliminate the need for many of the subparameters
and keywords that the old [Model] keyword now uses I wonder, what other
reasons
do we have to want to nest the [External Model] under the old [Model]
keyword?
The only questionable keywords and parameters I can think of would be the
voltage
range and voltage reference keywords and the reference load definitions
(which
may also be debatable).
It is true that one could make a combo model that way, using the old style
IV and Vt curves in addition to the new [External Model] description.
However,
I don't think that this will happen too often, because this puts extra work
on the model maker, and the miscorrelation between the new and old
descriptions
may be so great that you may not want to have to deal with it. The
additional
complications regarding the added complexity of keyword usage rules,
especially
in connection with C_comp, [Ramp] and the differential models makes this
approach
very undesirable to me. The rules and interactions become too ugly in my
opinion,
just think about the [Driver Schedule] keyword, how ugly and problematic it
is
with C_comp, etc...
Frankly, I do not want to be bogged down by the old baggage by putting this
new
keyword inside it. That would force us to have to live with the old
mistakes and
shortcomings of the spec for the rest of its life. If the new keyword was
independent, the old stuff could eventually be put to sleep after a while.
(Even
though the tools would still need to support it, but model makers wouldn't
have
to use it).
I am also confused by your and Chris' allusions regarding the usage of the
[External Circuit] keyword. It sounds like as if you would be saying that I
could put a buffer model into it. That is not the way I read the BIRD. We
need to decide what the intention is and write the BIRD accordingly.
However,
if that was the case, I have to say it again, would prefer to not have two
different but very similar keywords do the same...
Thanks,
Arpad
============================================================================
======
-----Original Message-----
From: Ross, Bob [mailto:bob_ross@mentorg.com]
Sent: Wednesday, August 28, 2002 7:43 PM
To: Muranyi, Arpad
Cc: ibis@eda.org
Subject: Re: [IBIS] BIRD 75 comments
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 : Thu Aug 29 2002 - 10:49:13 PDT