Subject: Re: [IBIS] BIRD 75 comments
From: Ross, Bob (bob_ross@mentorg.com)
Date: Wed Aug 14 2002 - 16:49:47 PDT
Arpad:
Thank you again for your thoughtful comments.
I am adding to the responses I gave earlier in preparation
for issuing BIRD75.3.
Some of your points could lead to long discussions. I tried
to keep the responses here short and/or just acknowledge that
BIRD75.3 documented a choice among several possibilities.
Bob Ross
Mentor Graphics
"Muranyi, Arpad" wrote:
>
> All,
>
> This is a public posting of my message to Bob Ross from last night
> regarding BIRD 75. Based on some private discussions and the Open
> Forum meeting this morning, I added the last item (#20). Item #5
> was my misreading of the BIRD, and it was clarified to me by Bob,
> I just left it in there for completeness, and to see if anyone
> else has a problem understanding it.
>
> I would like to encourage everyone to comment and express their
> opinions so we could come up with a robust solution for our needs.
>
> Thanks,
>
> Arpad
> ===================================================================
>
> Bob,
>
> Here are my comments on BIRD 75.2.
>
> Some of the wording is still not entirely to my liking, but I can
> live with that, or we can do an editorial session once again on
> section 6b. I think this is important, because we have to make
> sure that the reader who has never hear of this can understand
> what is being said here.
>
> Technical issues:
>
> 1) The 3rd and 4th drawings do not label the core side of the nodes.
> I think they should also be labeled.
I left the third drawing as is for a context diagram, but added
the ports for the External Circuit diagram so that the [External
Circuit] example would be clearer.
>
> [External Model] section:
>
> 2) In general, I wonder whether this is the right way of doing it,
> I mean to have this inside the [Model] keyword. Our last discussion
> on true differential buffers and the associate rules bothers me a lot.
> So I wonder what is the reason to want to have this [External Mode]
> keyword inside the [Model] keyword. Is it for its subparameters
> (C_comp, Model_type, Vinh, Vinl, etc)? For one, only two of these
> are required, all the other ones are optional. Second, if we had
> the [External Model] as an alternate to the [Model] then the [External
> Model] keyword could have its own set of (duplicate) subparameters
> analogous to the [Model] keyword. I know this is kind of duplication
> but this way some of those ugly rules would go away, and the two
> model keywords would be independent. (Similar to the [Nodal Path
> Description] and the [Tree Path Description] keywords in the
> ICM spec. Doing it this way would also make me happier because
> we could perhaps combine the [External Circuit] and [External Model]
> keywords as I commented the first time. This would also make BIRD 77
> unnecessary, because those subparameters could be added for the
> [External Model] keyword. We could also combine everything that
> is under the [Model Spec] keyword and do it right for once all
> under the [External Model] keyword.
You may be right. However, the reason for the current approach is
for practical considerations rather than purity reasons. An
[External Model] keyword at the same level as [Model] would create
some documentation difficulties:
- Most, but not all locations of [Model] would have to be reviewed
and possibly changed to "[Model] and/or [External Model]" where needed.
Such an exercise is subject to mistakes.
- Several but not all of the keywords and subparameters under
[Model] would have to be repeated causing documentation change
tracking problems.
So I felt it was easier to contain [External Model] under [Model]. This
also makes the IBIS compatibility/migration path easier with existing
IBIS models.
>
> 3) Regarding the typ., min., max corners, Lynne asked for capability
> of having more than just three.
The proposal is limited to just the three corners. This will make
the EDA tool migration easier since other "corners are not defined.
However, the user work-around is to create a separate ibis file or
new model. In one model, the min might be
low voltage/ low temp/ slow process
The second model might have the min column as
low voltage/ high temp/ slow process
Other variations could be configured by separate models, but each
User would have to configure their EDA tool to handle the cases in
a vendor specific manner - since there are no standardized conventions.
Such handling could be done through interfaces or scripts.
So any specific or unusual configuration (such as strong PMOS, weak NMOS)
could be constructed, but the user would then have to know what the
contents are and direct the analysis through different files or
problem specific scripts.
>
> 4) It is still not clear to me how the .LIB statement would work with
> the subcircuit calls as you show it. Process files are usually
> separate from the netlist, and here we only have netlist references
> only.
We did not know at the meeting whether .LIB was part of Berkeley Version 3F5.
My understanding is that the .LIB statement provides a level of indirection
so that only specific files of interest are included.
The .LIB feature does appear in several SPICE implementations. A Specific
SPICE implementation might process it directly as one of the Corner
setups as long as the higher level entry is still through a .subckt name.
However, if the .LIB is itself the top level file, you might have to
bypass the .LIB and enter the filename and .subckt name directly in
the Corner lines.
>
> 5) Regarding Ports, it is not clear to me whether these include the
> internal nodes labeled (a) - (j) as well as the pad nodes which
> correspond to the inside of the package.
> *** This was my misunderstanding of the text, please ignore.****
(The Ports do not include nodes. The Ports are the [External Circuit]
or [External Model] terminal names.)
>
> 6) Regarding D_to_A and A_to_D it is not clear from this writing
> whether these are an "element" or parameters to an element.
> If they are elements, then I wonder whether they should be
> lifted out from being subparameters and make them keywords.
> If they are just parameters to an element that resides inside
> the [External Model] itself, then this needs to be explained more
> clearly.
The text defines D_to_A and A_to_D as subparameters of [External Model].
These "subparameters" have up to 7 entries. This was chosen as a more
compact way to enter in just one line the port and ramp informaton to
control SPICE circuits or to report logical state changes from
threshold values. The alternative could have been to spread this over
several lines. However, there would be more syntax checking rules
regarding possible omitted information.
>
> 7) In the port description under A_to_D and D_to_A you describe
> port1 and port2 as 1 referenced to 2. In that case isn't this
> just one port having a + and a - node (two terminals).
Each port name is meant to name a particular terminal. There might
be an implicit two terminal definition of port if a global reference
is implied for the reference terminal. With a common implied
global reference, the plus and minus terminals can be used is
if it were a two terminal definition of a single port. However,
in this document each "port" name corresponds to a single terminal.
>
> 8) Also, I believe that you mistakenly used A_receive twice in this
> section instead of D_receive.
My mistake, this will be fixed.
>
> 9) In the "true differential" buffers section you also say "two
> differential ports", which is really ONE differential port.
I am consistent with the definition of 7) that each port is the name
of one terminal. So differential buffers have two ports.
>
> 10) The last section before the examples talks about the regular
> keywords under [Model] being useful for things if this is still
> not supported, etc. It would be nice to spell out what is
> required and what is optional from the old stuff if this new
> stuff is there.
Good point. The Other Notes section is revised to give a
minimal content rule.
>
> 11) The paragraph before the [External Circuit] is misleading,
> because it makes me believe that the [External Model] keyword
> can be placed anywhere in the document as it is with the
> [External Circuit].
A badly written clause that cause the confusion will be removed.
>
> 12) Regarding corners typ., min., max, comment same as above,
> Lynne wants more then three.
My response is similar to 3) above. Three corners consistent with
existing IBIS are defined. The user can work in more conditions
with extra files.
>
> 13) [Node Declaration] keyword is required for internal nodes.
> What is an internal node? Are the die pads considered internal
> nodes, since they are not listed on the pin list?
An editorial mistake causing this misunderstanding will be fixed.
The [Node Declaration] keyword documents internal nodes only.
>
> 14) The third [Circuit Call] example with BUS_SPI is confusing
> because the port names are not identified on the 4th drawing
> up front. Without those showing on the drawing I have a hard time
> to identify the connection between the pin to circuit, and then
> circuit to internal node, and then internal node to buffer port
> name.
The drawing is revised per 1), and the example should now be clearer.
>
> 15) There are a couple of "}" in this section.
Fixed, thank you.
>
> 16) The last paragraph before the true differential example uses
> 200m for Vlow etc. It should be spelled 200mV. Otherwise it
> means meters.
Fixed by using 200 mV.
>
> 17) In the example(s) you mention C_comp. This raises the question:
> With external models is it still required to have C_comp under the
> [Model] keyword? This is not mentioned anywhere (at least I couldn't
> find it). This doesn't make sense, because the external
> model could probably do a much better job in describing C_comp.
> On the other hand, if yes, than we need to have at least a C_comp_diff
> that is a capacitance between the two signal pins... Not to speak
> about the new ideas Luca proposed. I just found it now at the
> interaction limits. I wonder if it should be mentioned earlier.
Per our discussion, some things need to be stated more clearly.
C_comp and/or C_comp_* per existing rules is now required whether
it is needed or overridden. This will make checking simpler.
>
> 18) It should be mentioned somewhere in the "Reference Voltages"
> section that the an external model using SPICE should not have
> any global nodes (most often Vdd and Vss) because that will short
> them together across all of them, and thereby making the external
> circuit useless. (Global scaling factors could also be mentioned
> for similar reasons).
A caution statement is added.
>
> 19) In the interaction limits you mention "series switch" models
> using the [External Circuit] needing the [Series Pin Mapping].
> I think this is also true for [Series Current] and [Series MOSFET]
> and I would mention them here too.
The statement is that BOTH Series and Series_switch models still need
the [Series Pin Mapping] keyword - if they are configured under the
[Model] keyword and/or use [External Model]. [Series Current] and
[Series MOSFET] keywords can be configured as Series models. So
I believe the specific keywords are already included - along with
[R Series], etc.
It is also possible to connect Series elements such as passive
components, diodes, etc. using [External Circuit] and the
native language elements. This is a way to bypass the [Model]
keyword and [Series Pin Mapping].
>
> 20) SPICE and AMS models can be parameterized very well. It would
> be a pity not utilizing this capability. However, I don't see any
> mention and provisions for bringing out the parameters from an
> [External Model] or [External Circuit] call to the user interface
> of the EDA tool. I think this could be done easily, we just need
> to define how.
This is an issue. While parameterizing model is useful, providing
a standard process may be difficult when supporting an number of
language variation. I choose to leave this as a function of the
specific external language.and have mentioned this under the
EXTERNAL LANGUAGES: heading.
>
> Arpad
> ===================================================================
-----------------------------------------------------------------
|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 14 2002 - 17:11:05 PDT