Minutes from the 22 September 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 22 September 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
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:
- None
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad to update the draft of the Info, Out, InOut BIRD.
- Done (revision #12 posted on the ATM website).
- Mike L. to add a ver6_1_known_issues.txt to the 6.1 spec folder and add the
issue Arpad discovered ("General Reserved Parameters" section number).
- Done.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L: Motion to approve the minutes.
- Todd: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Item #6: Info, Out, InOut BIRD draft.
- Arpad: [sharing and reviewing the newly posted revision #12]
- Name of the parameter changed to NonStandardParams.
- New "Other Notes" section.
- Other Notes: A non-standard Model_Specific parameter may require action
from the user or the EDA tool that is not described in the IBIS
specification.
- Bob R: Add the Info, Out, InOut to the Other Notes text to fully describe
what parameters' Usage(s) might be non-standard.
- Walter: Why doesn't it include Usage In?
- Arpad: In goes from the AMI file to the model.
- Walter: That's not necessarily true. It is also available for use by the
EDA tool.
- Todd: This is a voluntary declaration of something as non-standard.
- Therefore, we shouldn't assume the degree of non-standard-ness.
- Arpad: Okay, then this BIRD is open to all Usage(s).
- Bob R: I prefer NonSpecified to NonStandard. A parameter could comply with
the specification but expect the tool or user to modify the
parameter in a non-specified way.
- Radek: The issue is only whether any special action should be taken by the
tool based on the value of such a parameter.
- Bob R: This is a specification, it may become a standard but it's not a
standard yet.
- It's really a non-specified action we are talking about.
- Mike L: If we're making an important distinction, any one of our
specifications could become standards.
- Radek: The only things specified are Reserved Parameters.
- Anything in the Model Specific section is not specified by the
specification.
- So by this definition everything in Model Specific would be unspecified.
- I think NonStandard is closer to the meaning we want.
- Bob M: I think the crux of this issue is also with the Other Notes statement.
- I think it should not include the words "from the user".
- Model vendors may have plenty of parameters that require the user to set
them appropriately in order to get useful results from the model.
- The key is whether the EDA tool directly interacts with the parameter.
- For example, a "tuning mode" parameter that allows the user to select
the value does not require special handling.
- Discussion: What is NonStandard (or NonSpecified)?
Bob R.'s initial comments about nonstandard vs. nonspecific led to a
discussion that revealed a more fundamental difference of opinion on this
BIRD. Bob M.'s example (Model Specific "tuning" parameter of Usage In,
Format Table, Type String, from which the user would select a value) served
to highlight the difference. Bob M., Radek, John, Todd, and Curtis all
supported the interpretation that such a parameter would not need to be
listed in the new NonStandardParams. It was an acceptable use of a Model
Specific parameter and would classify as "normal processing." Since only
the user was making the selection, and the EDA too was not doing anything
with the parameter on its own, nothing was NonStandard. Any EDA tool should
be able to present the user with the list of choices. Bob R. contended that
such a parameter should be listed in the new NonStandardParams because its
behavior was not defined in the specification. Others (see Radek above)
felt that this interpretation would then apply to all Model Specific
parameters, rendering the new NonStandardParams meaningless. Throughout the
discussion Arpad tracked various proposed changes in the language of the BIRD
for use in a future revision.
- Discussion: Using Reserved Parameters.
Todd brought up a suggestion he had previously made. One might list the non-
standard params under Reserved Parameters (since they require some special
handling that needs to be defined eventually), but also list them under the
new NonStandardParams so that the parser would know not to issue errors when
it found Reserved Params it didn't recognize. This would let the user know
what params expected special handling from the EDA tool (those in Reserved),
but which ones weren't defined in the spec (NonStandadParams). Bob R. again
opposed this concept. Arpad pointed out that the current definition of
Reserved Parameters was that it included only things fully defined by the
spec.
- Discussion: Tstone models as an example.
The tstone models were brought up as an example of special handling. The
tstone parameter would need to be listed in the NonStandardParams. The
tstone models also contain documentation listing workarounds the user might
employ when using a tool that does not support the non-standard tstone (for
example, manually including the touchstone model directly in the circuit).
This was noted as a good thing to do in the case of non-standard parameters.
- Bob R: Anyone can use the name 'tstone.'
- Radek: That's a good example.
- You may have a tstone parameter that should be completely ignored by the
EDA tool. It may be used by the .dll to find the file and do something
with the data, for example.
- Therefore this NonStandardParams that lists those params that actually
require special handling by the EDA tool is useful in differentiating
between the two cases.
- Bob M: That's the first time I've heard a really good reason for having
a table of the non-standard parameters.
- A model may use the same name in Model Specific quite by accident, but if
it's present in the table the EDA tool knows something odd is going on
with it.
- Mike L: It's important to make sure that model makers will have a consistent
understanding of whether a parameter falls under this BIRD or not.
- Arpad: Thank you all for joining.
AR: Arpad to work on next revision based on language changes proposed during
the discussion.
-------------
Next meeting: 29 September 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
