Minutes from the 11 August 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 11 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:
- Curtis stated that he would not be able to attend the following meeting.
Arpad said he would therefore be asking for a volunteer to take minutes.
Randy said that he thought he would be available to take the minutes.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- None
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Curtis: I received no feedback via email for last week's minutes.
- Mike L.: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
- Arpad: We had an email last week regarding the Backchannel issue.
- Walter: I sent a private email to Ambrish, Radek and Arpad.
- I stated that I do not want to continue working on perfecting a Backchannel
BIRD.
- We don't see sufficient interest from IC vendors and customers.
- I've done significant work on this.
- I think my proposal is a good approach.
- I'm going to step back and let Ambrish and others come up with a new BIRD
that meets the fundamental requirements in a way they feel comfortable with.
- Ambrish: [summarizing discussions with Walter, et al.]
- Simplify BIRD 147 to remove any complications with the stimulus of the
back channel interface file. Generally what Walter's proposal did.
- Also propose a simple Tx BCI file that will cover most current transmitters.
- Analogous to Walter's second "pigeon" proposal.
- Will also allow for any future BCI file that someone may want to propose.
- Maintaining the position that the EDA tool will not have any involvement
with the message other than passing it back and forth.
- With these changes we will then reintroduce BIRD 147 to the ATM.
- Arpad: Based on this discussion I will remove item #11 (SiSoft co-optimization
proposal) from our tabled topics list.
- Walter: Yes.
- Arpad: Item #12, BIRD 147 will be untabled when Ambrish is ready to update us.
Item #7: Info, Out, InOut BIRD draft.
- Arpad: We had a good discussion last week.
- We ended with the suggestion that people come up with ideas on how the goals
of this proposal should be implemented in the spec.
- Walter: What are the goals? What is the intent?
- Arpad: I made a statement that the goal was to prevent the specification from
undermining itself by allowing undocumented non-portable features.
- Ambrish: The main goal is to somehow prevent a Model Specific parameter from
influencing what the EDA tool does.
- There is a lack of knowledge about what the tool would need to do.
- Walter: So, "A model maker should not expect the EDA tool to do anything
differently based upon the value of any Model Specific parameter."
- Ambrish: Yes.
- Walter: That's a fair statement. That's a simple statement.
- I'm comfortable with that.
- Radek: I believe the discussion went a bit further.
- We generally agreed that some experimentation being done with Model Specific
parameters is okay.
- But, it's important that the user is aware that some EDA tools may be doing
something specific.
- Ambrish: You could make another section or branch for EDA specific parameters.
- Once you put a Model Specific parameter in the model, then users expect all
tools to read it and handle it the same way. That causes problems.
- Walter: "The user shall not expect that the EDA tool will do anything
differently based on the value of a Model Specific parameter."
- But the user can still direct the EDA tool use a certain Model Specific
parameter's value in a certain way. That's not a problem.
- Discussion: Walter, Todd, John, Arpad and Ambrish all showed interest in the
proposal for a separate top level branch for experimental, non-portable
parameters. Fangyi and Bob did not support the idea. They felt that nothing
was to be gained by the added complication. Both felt the existing Model
Specific concept could be used for experimental parameters. Fangyi felt the
committee was trying to place certain restrictions on the experimental phase.
John replied that the top level branch would really only serve to document
the experimental nature of the parameters to the EDA tool. Supporters felt
the top level branch provided the flexibility and the documentation. Arpad
and Ambrish suggested that using Model Specific parameters for experimental,
tool-specific features was overloading the Model Specific concept and causing
confusion for users. Mike L. pointed out that using normal Model Specific
parameters for experimental features could result in EDA tools reading them
and presenting them to users to make choices that might be unexpected.
A suggestion was made for locating EDA tool specific branches underneath the
Model Specific branch. Walter preferred the top level experimental branch
concept because it minimizes the changes necessary if a parameter is later
accepted as a Reserved parameter.
- Arpad: [responding to objections to the new branch proposal]
- We have come full circle now.
- If you're saying we don't need a new branch, that's fine.
- But now we need to go back and define explicit rules and regulations
spelling out what the expectations are.
- Todd: At the end of the day you have to do it one way or the other.
- How much is about expectation, and how much is about notification?
- John: If notification is the goal, that's hard to accomplish using Model
Specific.
- How do we achieve this goal?
- Arpad: Now is a good stopping point.
- Thank you all for joining.
-------------
Next meeting: 18 August 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
