Subject: Re: [IBIS] BIRD 75 comments
From: Ross, Bob (bob_ross@mentorg.com)
Date: Fri Aug 09 2002 - 15:45:40 PDT
Arpad:
Thank you and for your comments and thoughtful review. Thank
you and others for your comments before, during and after the
meeting. This is very helpful to clean up and clarify the
details and to raise a few issues. Several points revealed
editorial mistakes or misunderstandings that I missed.
I will need to do some investigation on some points and respond
next week. Below are brief responses to some of the easy
issues or mistakes.
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.
>
> [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.
>
> 3) Regarding the typ., min., max corners, Lynne asked for capability
> of having more than just three.
>
> 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.
>
> 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.****
>
> 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.
>
> 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).
>
> 8) Also, I believe that you mistakenly used A_receive twice in this
> section instead of D_receive.
My mistake, will be fixed.
>
> 9) In the "true differential" buffers section you also say "two
> differential ports", which is really ONE differential port.
>
> 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.
>
> 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.
>
> 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.
Probably will add detail to a drawing to make this clearer.
>
> 15) There are a couple of "}" in this section.
Will be 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.
Will be fixed.
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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 : Fri Aug 09 2002 - 16:02:14 PDT