Minutes from the 08 September 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 08 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:
- Todd had taken the minutes the previous week (09/01/2015). Todd had sent the
minutes to Arpad for review, but the final version had not been completed and
posted. Mike L. took the AR to complete the minutes and post them.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad to email the Editorial Committee with the ATM group's suggested
rewording of the [C Comp Corner] sentences.
- Done. [Arpad reviewed the final status in the New Discussion: section below]
-------------------------
Review of Meeting Minutes:
- Minutes for 01 September had not yet been posted.
-------------
New Discussion:
[C Comp Corner] update:
- Arpad: We discussed the ATM group's recommendation in last Friday's Editorial
meeting.
- We came up with a sentence that was mailed to the IBIS reflector so that
everyone would be informed prior to this Friday's Open Forum meeting.
- The final proposed language is: [from Michael Mirmak's email]
"If [C Comp Corner] is present, its subparameters take precedence over any
and all C_comp, C_comp_* subparameters of [Model]."
- The vote to approve IBIS 6.1 will be a conditional vote that includes making
this change.
- Hopefully everyone is okay with this language, since it came from the
Editorial review of what ATM had proposed.
- Any questions? [none]
Item #6: Info, Out, InOut BIRD draft.
- Arpad: In our last discussion of this topic two weeks ago, we seemed to agree:
- We would use the existing syntax.
- We would not introduce a new branch, parameter Type, etc.
- We would just be clearer in the spec that some information should be in the
model to let the user know if a non-standard parameter is used.
- We did have some discussion on introducing a new Reserved parameter.
- It could be called "proprietary" (values 0 or 1).
- It could be called "interoperability" and list supporting EDA vendors.
- Etc.
- Walter: I understand the concept [of the new Reserved parameter].
- I dislike the name "proprietary" as it implies that you're not documenting
what to do with the parameter.
- Arpad: Before we get into the specifics, do we want to decide if we want to
add a new Reserved parameter?
- Ambrish: I think adding a new keyword is not a good idea.
- Why add another layer of complexity if it's not enforceable?
- Bob: Introduction of a Model Specific parameter that is not universally
accepted or understood is still legal. It will still pass the parser.
- What is being proposed is a Reserved parameter indicating that this AMI file
includes parameters with special meanings or handling.
- That might be acceptable as a Reserved parameter just for information.
- Todd: Is the issue here that the model contains a parameter that affects
simulation results in a non-standard way?
- Bob: Yes.
- Arpad: [responding to Ambrish's question]
- I don't see any way to make this enforceable.
- Model Specific is already not enforceable.
- Can you see any way to make it enforceable?
- Ambrish: With sufficient pressure from the customer of your model, you could
resort to just removing the offending parameter and saying the model
no longer has the issue.
- The description in the model may have that information anyway, and that
should be enough for the user.
- John: Description strings are arbitrary and harder to parse.
- Ambrish: The info is mostly for the user to be aware, not the tool.
- Arpad: Last time we discussed a parameter that lists all the vendor specific
Model Specific parameters.
- Instead, we could add a new "vendor specific" leaf to all Model Specific
parameters (value 0 or 1).
- John: Either of those would make it easier for the tool to find that out.
- Ambrish: Do we see many models that will need this kind of thing or not?
- Are we adding this burden when most models won't need it?
- Todd: When we started this discussion a few weeks ago:
- I was tired of getting yelled at for putting new things in models.
- You were tired of getting customer complaints if your simulator didn't
support them.
- Now, we are deliberately offering to highlight such parameters for the user
to help us both out.
- Model maker would have to defend the reasons for putting the parameter
there.
- I thought you said this was a source of pain.
- Ambrish: Would this resolve it?
- Walter: I would dismiss the suggestion for a new leaf for every Model Specific
parameter.
- The new parameter with a list of the special parameters is better.
- Model maker should then be obligated to give an explanation for the
parameters listed in this new Reserved parameter.
- That would not affect any existing flows.
- Arpad: [responding to Ambrish's frequency of occurrence question]
- These types of models appear whenever there's a new feature appearing that
the spec doesn't cover.
- For example, if someone came up with a PAM9 and the spec only covers PAM4,
then they would have to add Model Specific parameters for PAM9.
- Suddenly, all these new PAM9 models would be proprietary.
- Walter: I think your premise is wrong.
- If there were a PAM9, the Model Maker would not just invent new parameters.
- They would talk to their EDA vendor(s). [the folks on this committee]
- Then we'd all agree on the needed parameters and converge on a PAM9 BIRD.
- We'd agree, and as with PAM4 they would use the new Reserved parameters.
- Arpad: Yes, but what happens while all that is shaking out?
- While the BIRD is being discussed, those models are proprietary solutions.
- Ambrish: Ideally that would not take place, and those proprietary models
would not slip out to customers.
- Todd: That's not realistic. They don't "slip out".
- They are shipped intentionally in order to get a job done.
- Ambrish: Is this a problem that could be fixed?
- I don't think it could.
- Walter: As a practical matter I think there are two things appearing in models
that are not compliant with the standard.
- 1. tstone files
- 2. dependency tables.
- Tstone files can already be addressed in 6.0 by using External Models if
the model maker and EDA vendor want to support it.
- Dependency tables will be addressed in 6.1. Once 6.1 is released, model
makers should be adding an AMI_Resolve() function to their .dlls.
- Radek: That's a suggested way of handling those particular upgrades.
- What about the models that have been used in the past?
- A user may not be up to date on the latest standard. They just get an old
AMI model and try to use it.
- It is really fair to inform the user if special parameters are used.
- Those old models are not going to disappear. We have no control over that.
- It is fair to put that information in for the user, whether it's 5, 10 or
30 percent of models that might be affected.
- Walter: I agree.
- Suppose in 6.2 we add Reserved parameter XYZ that lists all of the special
parameters. Someone can then take a 5.1 file, convert it to 6.2, add the
new XYZ that lists the parameters, and this issue is solved.
- Todd: Do we have a problem worth solving?
- Arpad: I think we do.
- Todd: I now hear Ambrish saying we don't?
- John: Walter went to a slightly different example, taking an older model and
updating the version and adding the new keyword.
- That's an area that is a big problem.
- A lot of older models have not been updated to the latest AMI version.
- A bit earlier we were talking about the interval of time between a new
prototype being released to users and the actual parameters getting approved
and tools getting updated to use them.
- Ambrish: Don't you think model makers would just update their old models
according to Walter's example?
- They could just add the new keyword and not actually bring the model up to
the latest spec by doing it the new approved way.
- Todd: You're right.
- Some model makers will not invest the cost to go rewrite an ASCII dependency
table using AMI_Resolve().
- But at least it's out in the open and the user knows about it.
- Radek: And we don't have to have it enforceable.
- We care about the user so we want to put this information in the AMI file.
- What's to enforce?
- Arpad: If someone writes a model that is vendor specific today, and later on
the spec adds that capability, is there a way to make that model work
in all tools (interoperably) without changing anything since the new
spec supports the previously proprietary feature of the model?
- Assume for this discussion that the spec implements the feature exactly as
it was initially prototyped in the vendor specific model (same name, etc.).
- Ambrish: There are too many ifs.
- Walter: It's simple, take the Modulation parameter introduced for PAM4.
- It was Model Specific in 6.0.
- Anyone can take that AMI file, change it to 6.1, move that parameter into
Reserved and get rid of the XYZ parameter.
- Radek: Yes, then it's ready to go.
- But there's no way to even know if you could just map an old Model Specific
parameter to a new Reserved parameter. Only the model maker would know for
sure if the implementation were identical and the model didn't need to be
updated.
- So only the model maker would know if you could just update the AMI file.
- Ambrish: That's half the people. What about those who never get their changes
approved and in the spec?
- Walter: There are lessons to be learned when we look at BIRDs in the future.
- PAM4 BIRD - I think we did that extremely well. We iterated through the
process quickly. I think everyone involved will find it easy to upgrade to
IBIS 6.1.
- Tstone file and Ext Model - I think we did okay. At least we gave a path
for vendors to migrate to Ext Model.
- I think we did the wrong thing with Dependency Tables. Instead of making
incremental changes, this group made the decision that they weren't flexible
enough. We chose a path that it was clear would make it very difficult
for people to upgrade [to AMI_Resolve()]. The problem was that we didn't
come up with that decision in a timely fashion. It's now coming in 6.1,
but it has been 4 or 5 years since dependency tables were introduced.
- The lesson is that we should make it easy to upgrade the model to the
approved way, or at least introduce the new method more quickly.
- Todd: There's one other hypothesis.
- One of the value statements for going to binary dependency tables
[i.e. AMI_Resolve()] was that people would want to hide the dependency
mechanism and not have it documented in plain text.
- That was a justification given, and it's legitimate.
- However, maybe it's not true in practice. Maybe people don't care about
that enough to want to go implement AMI_Resolve().
- Right now we see there's not enough demand in the market to drive people
to write and adopt models with Dependency Tables. Maybe that's because
tools don't support them, and the vendors aren't complaining enough, or
maybe it's just a non-problem and no one cares about them.
- Arpad: It sounds like we are leaning toward a Reserved parameter that has
Format Table and lists the vendor specific parameters.
- Should I start drafting a BIRD along those lines?
- Bob: I would like more discussion.
- I favor a simple Boolean parameter that says whether it's interoperable.
- The description parameter can then be used to list the details: what
parameters, how to use them, what tools support, etc. (assuming the
Boolean is false - i.e. not interoperable).
- Walter: I totally support Bob's suggestion.
- John: Use of the table would be to tell the EDA tool which of the Model
Specific parameters are not interoperable.
- The tools probably already can display description strings so it may
be a wash.
- Marginal gains and marginal extra work by adding a table.
- Todd: I think we've agreed that we have a problem we need to solve.
- Arpad: I will start drafting a BIRD.
- Thank you all for joining.
AR: Mike L. to finalize and post Todd's minutes from last week.
AR: Arpad to begin drafting a new BIRD for item #6.
-------------
Next meeting: 15 September 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
