Minutes from the 29 September 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 29 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:
- Arpad noted that he had removed two BIRDs from the "Pending BIRDs" list in the
ATM Agenda. BIRD 157, Parameterize [Driver Schedule], had been voted down in
the Open Forum meeting. BIRD 178, Specifying Buffer Directionality for AMI,
had been approved by the Open Forum and is now part of the released IBIS v6.1
specification.
- Arpad noted that we may need to cancel the ATM meeting the last week in
October because of people traveling for the IBIS Summit held at EPEPS. He
said this would be finalized during upcoming meetings.
- Ambrish mentioned that work commitments had kept him from making progress on
the Back-channel proposal (BIRD 147).
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad to work on the next revision of the Info, Out, InOut BIRD draft based on
the language changes proposed during last week's discussion.
- Done (see discussion below).
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Todd: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Item #6: Info, Out, InOut BIRD draft.
- Arpad: [sharing some new language proposals he had emailed to the reflector]
- Today I would like to answer the following question:
- What type of special parameters should be listed in this new Reserved
parameter? Should we list only those parameters without which the model
would be completely broken, not able to perform even the basic IBIS-AMI
functionalities, or should we also list those parameters that are needed
for "above and beyond" normal features?
- I believe Walter's preference was to list both types, even new features.
- John: Could we start with this proposed definition? [following]
- Any Model Specific parameter that requires the tool to do anything other
than just get the user's input (provide a value) or display it to the user
should be listed in this new keyword.
- Mike L: That sounds like it lines up fairly well with Walter's proposal.
- Radek: I think we've agreed to that several times.
- John's way of phrasing it is good.
- Arpad: I want to discuss the word "requires".
- John: Requires in order for the model to function as the model maker intended.
- Bob R: If the model maker wants the features used, the parameter(s) should
be listed.
- Walter: Requires is not a good word here.
- Any Model Specific parameter for which the model maker expects the EDA tool
to do something other than allow the user to select a value or display
the value should be listed.
- We've all said the same thing several ways.
- I think we are all in agreement.
- We don't need any requirements on what bad things will happen, etc.
- Arpad: Okay, this decision has been reached.
- Given this decision, the follow on question is:
- Would it be useful to have an indicator for each of the special parameters
to indicate whether it is part of a new feature or required to get proper
results out of standard simulation flows?
- It sounds like it might be useful to have a "severity" indicator.
- Walter: The information would be useful.
- It should be given to the user as the description field of the parameter.
- The model maker should describe what the parameters do.
- We should leave this to the model maker.
- Radek: I think the original agreement was not to complicate things with this
indicator parameter.
- However, now that the new Reserved parameter has Format Table, it would be
easy to add another column.
- It might be easy to add another bit of useful information.
- Arpad: I agree.
- A second column would be parseable, as opposed to description field text.
- The tool could then decide, when it doesnt recognize the name of a special
parameter, whether it can perform the basic AMI simulations or not based on
the severity indicator.
- Discussion: Do we need a severity indicator for non-standard parameters?
Participants understood the value of the information Arpad's proposal was
attempting to provide, but there was disagreement about whether the proposal
would work in practice. Bob R. agreed with Walter's position that it was an
unnecessary complication, and suggested that there would always be a grey area
between any two defined severity levels. Todd stated that he was worried that
we were already asking model makers to list their non-standard parameters, and
asking them to now flag them as the "critical" type might be a bridge too
far. Tstone models were again introduced as an example. Todd suggested that
tstone might not be flagged as critical, since the workaround was well
documented and easy. Radek countered that the workaround might not be trivial
depending on how the IBIS Model had been formulated. Bob M. noted that as a
model maker who had released tstone models he would list it as critical to
ensure the users were alerted. John, Bob M., and others noted that if we were
debating the way to characterize tstone models then it would be hard to expect
model makers to uniformly characterize their parameters. Arpad felt the issue
could be addressed by properly defining the criteria for the severity levels
in the spec. He also suggested we might use a term other than severity
if that sounded too harsh. Ambrish reiterated that this entire BIRD was all
voluntary on the model makers' part, and adding further indicator fields would
be an unnecessary complication.
Todd suggested that we have a vote to see where people stood on the topic.
Walter suggested that each person vote, as opposed to each company, since this
was a non-binding vote just to gauge the opinion of participants. Arpad and
Mike L. noted that the vote was not official, and Arpad phrased the vote,
"Should we add a severity parameter for the non-standard parameters?"
Results of Participant Vote:
Dan Dvorscak No
Curtis Clark No
Bob Miller No
Ambrish Varma No
David Banas No
Michael Mirmak Abstain
Radek Biernacki Abstain
John Angulo No
Arpad Muranyi Yes
Randy Wolff Abstain
Walter Katz No
Todd Westerhoff No
Mike LaBonte No
Bob Ross No
Totals:
No - 10
Yes - 1
Abstain - 3
- Arpad: The feelings of the group seem pretty clear.
- Arpad: I would now like to review the proposed language.
- Ambrish: Will this have an impact on the parser?
- Bob R: The parser will be cross referencing names from the new parameter to
make sure they exist in the Model Specific parameters.
- Discussion: Parser handling of the new parameter.
Ambrish and Arpad suggested that the parser should issue a warning
if the new parameter appeared at all, and an error if the new parameter
contained the name of a parameter that did not exist in the Model Specific
section. Bob R. suggested that the parser should issue a note and warning
respectively in those two cases. Bob R. asked that any parser handling
requirements be documented in the "Background information:" section of the
BIRD and not in the text of the actual BIRD (spec). Mike LaBonte agreed
with this, and suggested that these topics might be handled in the IBIS
Quality Group.
- Arpad: Thank you all for joining.
-------------
Next meeting: 6 October 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
