Minutes from the 25 August 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 25 August 2015
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Avago (LSI) Xingdong Dai
* Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC * David Banas
Marc Kowalski
Ericsson: Anders Ekholm
IBM Steve Parker
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Nicholas Tzou
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: * John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp. James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys Rita Horner
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
(Note: Agilent has changed to Keysight)
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- Walter relayed a decision being worked on by the Interconnect group.
- BIRDs had been proposed for allowing an IBIS file to indicate that it
did not contain a description of a complete component, call it "pre-layout".
- The Interconnect group had come to the decision that you could have such
a pre-layout description, but there would be no special syntax for it.
- The IBIS file would still have to contain what looked like a normal
[Component] definition ([Pins], etc.) syntactically. In the [Notes], the
model maker could indicate, "This is not a shippable product, it is an
IBIS container for the following purpose..."
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- None
-------------------------
Review of Meeting Minutes:
- Note: Minutes for August 18th were taken by Randy in Curtis' absence.
- Arpad: Does anyone have any comments or corrections? [none]
- Arpad: Anyone opposed to approving the minutes? [none]
-------------
New Discussion:
Item #6: Info, Out, InOut BIRD draft.
- Arpad: In recent meetings we've decided this is a notification issue.
- We need to make model makers and users aware of portability issues.
- Should we introduce a new branch or make use of existing syntax?
- If we make use of the existing syntax, how should we refine the rules
and describe them?
- Bob R: I favor using the existing branch.
- We can't dictate that the existing branch not be used for new features.
- Arpad: You're afraid people might still use the old method anyway, and we
can't enforce use of a new branch?
- Bob R: Yes.
- Ambrish: I agree with Bob.
- Nothing in the spec can force anyone to change their behavior.
- Even if we say you shouldn't, there's nothing to stop anyone.
- If you forbid Model Specific Info parameters, people could just use In for
the same purpose.
- The spec should add a line that says it should not be done, and the user
and model maker should not expect the EDA tool to read a Model Specific Info
parameter, but if it is done then we can't guarantee portability.
- Walter: I agree with you and Bob, except for your last statement.
- I don't mind if we have a statement that says using a Model Specific Info
parameter should not be expected to yield the same behavior on all tools.
But I object to saying, "it should not be done."
- Arpad: It sounds like we've decided to stick with the existing syntax.
- We just need to add something to the spec to point out that certain
situations could present an issue.
- Radek: There is one simple possibility for notification.
- The model maker could put a proper description in the descriptions string.
- It's easy to relay that information to the user, and the user will know that
the parameter may be tool specific.
- This is exactly what we want to tell the user.
- Ambrish: You're saying add something to the spec that tells the model maker to
put something in the description string?
- Radek: Yes, we may suggest that.
- Arpad: That's not enforceable by the parser.
- Radek: It's a good place to put the information anyway.
- Arpad: That is one good idea. What should the verbiage be for this?
- I would like more.
- Ambrish: In the section defining "Model Specific" parameters we could add, "if
these parameters are used for any other purpose that may change the behavior
of the model and affect the results, then..."
- John: Usage says whether the user provides the info to the .dll, or the .dll
gives it back, or it's for the tool/user (Info).
- If a model maker intends to eventually make a parameter Reserved, and the
aim is to inform the tool of something, then its usage is Info.
- The parser or tool could catch Model Specific Info parameters and note that
they might not be portable.
- But another option would be an Out parameter that is intended to be Reserved
eventually. If we have an Out in a Model Specific branch then that does not
indicate anything special to the parser.
- So is parser flagging on Usage alone adequate?
- Arpad: If we explain in the spec that Model Specific parameters are intended
to be used by the model, why would we have Info?
- Info is typically for the tool? So should we prohibit them?
- John: We are contemplating notification, not prohibition.
- Walter: When we created this it was explicitly stated that the intent of Model
Specific Info parameters was to let people develop advanced
capabilities and advance the standard in a way that the parser would
not fail.
- So we can't now say that it's not going to be allowed.
- Arpad: I understand, but if that is the purpose of this then we should not
explain in the spec that Model Specific parameters are for the models.
- They are also intended for the tools (Info).
- Walter: No, it is intended for the user (Info).
- If it's something the EDA tool can use, okay, but I think it's for the user
and the user controls the tool.
- Bob M: If there's a pressing need for EDA platforms that might not be in the
know then what we want might be some set of Model Specific data types,
for example InfoInOut, that informs any other EDA platform that this
parameter might have proprietary uses elsewhere.
- To require some explanation in a description field that isn't going to be
parsed anyway seems to be above and beyond.
- What we need is a warning about a model that appears to have secret
handshakes with certain tools.
- I think we've said there's no reason to have a Model Specific Info parameter
other than a secret handshake.
- John: Model Specific In parameter is okay.
- Model Specific Info parameter is guaranteed to be a secret handshake.
- Model Specific InOut or Out is indeterminate.
- Ambrish: That's not really true.
- Nothing is guaranteed with Model Specific parameters.
- Even if you ban Info, nothing prevents a model maker from doing it with In.
- So it doesn't preclude anything, even if we add a bunch of new types.
- Bob M: But if a model maker wants to play nicely with the standard, if he has
a secret handshake with a tool they could use InfoInOut.
- It's to my advantage as a model maker to be able to tell the user if a model
only works on a subset of tools.
- John: If we have a way to parse and identify those parameters that might be
proprietary then we get what we want.
- Bob M: I ask that we please keep it simple so it doesn't become burdensome
going from proprietary to approved Reserved parameter.
- Ambrish: That doesn't help, you still have old models out there after the spec
is updated, or the parameter is rejected.
- Bob M: The model is still out there, but the tool can tell the user.
- The tool could also update its warnings over time.
- Arpad: What if we have verbiage to state that under the Model Specific section
model makers could develop parameters that are specific to certain
tools, and that they my then not be able to expect portability?
- Then you don't have to define specifics?
- John: That stops short of giving the tool a way to parse, find, and notify the
user about such parameters.
- Arpad: Then we could add another section, "It is strongly encouraged that
model makers work with the spec to eventually make such parameters
Reserved so that portability can be achieved."
- Bob M: Instead of new types, what if we added another Model Specific Info
parameter that calls out the use of proprietary Info.
- John: You mean a Model Specific Info parameter that lists the proprietary
parameters?
- Bob M: Or just a single value 0 or 1.
- Arpad: This "proprietary" parameter would be Reserve parameter though, right?
- Bob M: It could be.
- John: You could require secret params to be put in the Reserved parameters.
- Then the parser can flag any whose name it doesn't know.
- Ambrish: You could still just do it with a comment. It's still voluntary.
- Arpad: I see the benefit of putting unrecognizable stuff in Reserved.
- But then the user might have to edit the file to get rid of it?
- If you take the "comment it out" approach, then what is the point of Model
Specific?
- John: The Model Specific branch does not generally have secret stuff.
- Ambrish: Model Specific is for the model, period.
- Arpad: You say that, but Walter says it's for innovation purposes.
- Ambrish: Walter says that it is for the model, but for innovation purposes we
don't preclude it being used by the tool.
- Walter: If you eliminate Info it doesn't solve anything. You could just make
them In.
- It's the model maker's responsibility to make sure they don't have super
secret handshake parameters.
- Model makers don't do that, they usually document the issue.
- Arpad: It's not a question of whether it's secret.
- It's whether it's described by the spec or not.
- Walter: We've been doing this for 10 years and haven't run into this problem
of EDA tool specific parameters being released without notification.
- Radek: We always come back to this topic of how to lead and how to change.
- We have already agreed the issue is just notification.
- "Proprietary" Reserved parameter, or info in the description, the focus
should just be on the best way to do it.
- The best way is to say, the standard describes the syntax, if the syntax is
okay it's compatible. If there's any way of handling Model Specific
parameters that will influence the simulation then it should be made clear
to the user.
- John: You're saying we should be in agreement to have a parseable means of
notifying the user?
- Bob M: I think we're in agreement on that.
- The EDA tool should be able to make the user aware that there may be
something in the model that it might not understand.
- John: As opposed to just asking for descriptive text from the model maker?
- Radek: Usually the descriptive string is quite visible in the file or GUI.
- It should be sufficient, but it's not enforceable.
- John: Nothing is enforceable, but do we want parseable notification or
description?
- Radek: Description would still be good even with a parseable warning.
- John: Perhaps we want a "note" or "caution", not a warning.
- Here's notification that we might not support this parameter right now.
- Bob M: What if we had a Reserved parameter called "Interoperability" of type
List. It could default to "all" or the value could be set to "limited"
if necessary (not calling out particular tools).
- David: What if you list the advanced features your model supports (not list
specific tools)?
- To Walter's point, history suggests these are announced well in advance.
- Bob R: There's no requirement to make people do that.
- It's noble that some do give advance warning.
- Bob M: I could support a Reserved parameter "Interoperability" that was a list
of all Model Specific parameters that are special.
- Mike L: One Reserved parameter for the whole model, or a Model Specific leaf?
- Bob M: Both have been proposed.
- Mike L: Based on the name of the parameter, tools will know if they know what
to do with it or not.
- Arpad: What if the new parameter were "Proprietary", and the value is the name
of the parameter.
- Then, if it gets added as a Reserved parameter later, the tool would know if
it already knows how to use it.
- Bob M: Then it would need to be a List.
- Walter: We could have a true/false "Interoperability" parameter.
- If it's false then it means that it has some parameters that are not
supported in the standard but the model maker expects the tool to do
something based on the value of the parameters.
- It would not have to list the parameters.
- Arpad: But if the spec later implements the features, how would we know this
flag is valid or not?
- Walter: It's still valid if the params are in Model Specific and not Reserved.
- Arpad: People often don't update their old models.
- So that old model would stay the same way.
- Based on your earlier comments about ease of promoting parameters to
Reserved,
we could establish a rule that if you find a Model Specific parameter with a
Reserved name then the tool can use it.
- Walter: That won't work because the parameter names often change multiple
times during development.
- Bob M: Once the new spec is in place, I want to update my model to reflect the
new standard.
- Arpad: Not everyone does that.
- Just this week I got a newly updated model that still used IBIS 5.0.
- Walter: You can't legislate quality.
- Arpad: Have we managed to find something reasonable to everyone?
- Should we continue this next week?
- Ambrish: Even with everything we've talked about today, if there's a model
that goes to a customer today nothing bounds things to help the user
or tool know if there's anything special about the model.
- Mike L: We need another meeting.
- Arpad: Now is a good stopping point.
- Thank you all for joining.
-------------
Next meeting: 01 September 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
