Subject: Re: [IBIS] BIRD 75 comments
From: Abdulrahman Rafiq (arafiq@cisco.com)
Date: Tue Aug 27 2002 - 15:48:39 PDT
Arpad,
If you want my opinion, though I am not an expert at ibis I have been using
ibis models, verifiying and validating them. I think the [external model]
keyword should be outside the [model] keyword.
This I gather from your explaination/opinion below and past knowledge of how
ibis works.
Regards,
Abdulrahman Rafiq
Cisco Systemsts
arafiqsi@yahoo.com
"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
> ========================================================================
>
> -----Original Message-----
> From: Ross, Bob [mailto:bob_ross@mentorg.com]
> Sent: Wednesday, August 14, 2002 4:50 PM
> To: Muranyi, Arpad; ibis@eda.org
> Subject: Re: [IBIS] BIRD 75 comments
>
> 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
--
---------------------------------------------------------------------------
| | Abdulrahman A. Rafiq
:|: :|: Hardware Engineer
:|||: :|||: HSS Engineering Services, (ISBU)
.:|||||||:...:|||||||:. Direct: (408) 527-5540
C i s c o S y s t e m s Fax : (408) 526-6603
www.cisco.com email : arafiq@cisco.com
800-250-4800 epage : arafiq@epage.cisco.com
URL1 : http://wwwin-sipd.cisco.com
URL2 : http://wwwin-people.cisco.com/~arafiq
-----------------------------------------------------------------------------
-----------------------------------------------------------------
|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 : Tue Aug 27 2002 - 16:10:17 PDT