Minutes from the 08 September 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 15 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 said he wanted to discuss an editorial issue he found in the IBIS 6.1
spec. (see below in New Discussions)
- Walter said that now that 6.1 was approved, we ought to start discussing the
rewrite of the discussions of "ground" in the spec.
- Arpad took Walter's suggestion as a motion to untable item #9.
- Radek seconded the motion, and none were opposed.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad to draft a new version of the Info, Out, InOut BIRD and send it out.
- Done.
- Mike Labonte to finalize and post Todd's minutes from September 1st.
- Done.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections for the minutes from
September first? [none]
- Arpad: Motion to approve the minutes.
- Curtis: Second.
- Arpad: Anyone opposed? [none]
- Arpad: Does anyone have any comments or corrections for the minutes from
September eighth? [none]
- Mike L: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Editorial Issue with IBIS 6.1 spec.
- Discussion: Arpad had noticed that the 6.1 spec had a section 10.3 "AMI
Parameter Definition File Structure" and then 10.4 "Reserved Parameters For
Data Management". However, the "General Reserved Parameters" section (heading
at the bottom of page 202) was not included in the table of contents and did
not have its own section number (presumably, it should be 10.4 and subsequent
sections' numbers incremented). Everyone agreed that Arpad had found a
legitimate issue. Since it had existed prior to 6.1, everyone agreed that it
was okay to simply fix the issue in the next revision of the spec. Mike L.
agreed to be the gatekeeper of the "ver6_1_known_issues.txt" file and to add
this issue to it.
Item #6: Info, Out, InOut BIRD draft.
- Arpad: [sharing his new BIRD draft on the screen]
- I have significantly rewritten the Statement of Issue and Analysis Path
sections based on our recent discussions and changes in the spec itself
over the past few years [this BIRD had been dormant for a while].
- New Reserved parameter VendorSpecificParams [name change - see below]
- Not required.
- Illegal in version 6.1 or before.
- Direction: Rx, Tx.
- Format: Value, List [changed to Table - see below]
- Discussion: Parameter name.
- Walter said that he preferred a different name for the parameter. Arpad
said that he wanted the name to clearly relay the message that some of these
parameters may not be handled by all tools. Some liked the suggestion of
"pre-standard," but others thought it too presumptive. Ultimately the
group settled on "non-standard".
- Discussion: Parameter Format.
- Bob R. had stated that he preferred a simple Boolean parameter. Walter had
agreed that it would be sufficient. Others preferred a Table listing all of
the non-standard parameters. Todd said that reducing it to a Boolean could
cause the model user to panic, but not tell them what the issues were.
Radek and John preferred the parseable list of names provided by the Table,
as opposed to free form text in a description field. Ultimately, Bob R.
said he was okay with the Table parameter concept.
- Arpad: Based on these discussions, I think my BIRD draft is close.
- Ambrish: Can we say "[non-standard parameters] must be listed" when we have no
way to enforce it via the parser?
- Is there precedent for any other spec providing a way to undermine itself?
- Todd: I understand your point, but I think we're acknowledging the speed of
of the industry not undermining the spec.
- Ambrish: If someone unfamiliar with these discussions opens the spec, they see
a description that opens the door to legitimizing these non-standard
parameters.
- Todd: The goal is to shine a spotlight on such parameters for the user.
- If something's not portable tell me what it is, what it does, and what is
the workaround.
- Arpad: We could take an enforceable heavy-handed approach that would only
allow parameters that are standardized and portable.
- But then we'd be saying that to do anything new you have to take it outside
of IBIS altogether.
- That might have the opposite effect of what we want. It might encourage
people to go further outside the spec and not ever come back.
- Ambrish: What is the incentive for the model maker to draw this to a close?
- What is the incentive to get the new parameters accepted into the standard?
- Is there a strong incentive?
- Arpad: The incentive for the model maker is provided by their customer base.
- If their customers want to use all different types of tools, then that
provides the incentive.
- Bob R: One concern is it's stated in the spec but not enforceable which
parameters must be listed. Should all In/Out params be listed?
- Bob M: The issue is any non-standard tool-model interactions.
- Radek: Correct, this parameter is used if such behavior exists.
- We already have noted in the spec that InOut or Out parameters in the Model
Specific section are only to be passed to the user. Other tool usages of
Info, In, Out, InOut should be required to be listed in this new parameter
table.
- Bob R: I'm not sure there's any way to check if something should have been
included in the list and isn't.
- Bob M: I don't think you can parse a model and figure out if a tool is
interacting in a non-standard way.
- What about the possibility that an EDA tool and a model might interact in a
way that doesn't involve a parameter?
- I think we want to make every such interaction tied to a parameter, even if
it's a dummy parameter, so that it can be listed in the table.
- We should have a parameter associated with every silent handshake agreement.
- Walter: We have that issue now with redriver flow.
- The current spec has a well-known error in the redriver flow description.
- Unfortunately, the ATM has been unable to agree on the wording of a revised
flow to fix the issue.
- So we [SiSoft] have a private agreement with certain model makers that we
are going to do the redriver flow the right way. If other tools use the
spec flow they will get different answers.
- Arpad: In that situation I'd think we should have a dummy Info parameter.
- Todd: An Info parameter that says what type of processing you expect.
- Radek/Walter: Agreed.
- Discussion: Listing all non-standard parameters.
- Bob M. suggested that to avoid clutter we might only list one non-standard
parameter associated with each feature. For example, for PAM4 there were
multiple non-standard parameters developed and only one might need to be
added to this list. Bob R. and John said that not listing all of them would
cause more confusion. Radek agreed and said clutter was not a problem.
Language corrections related to "ground" [untabled earlier, see above]:
- Walter: [sharing his document from a June ATM meeting presentation]
- I think we unanimously agreed that 6.2 should say that C_comp is connected
to the buffer local ground.
- I think someplace in IBIS we need a statement that says any reference to
ground connections in an I/O buffer is really a connection to the
pd_ref or gc_ref terminal for that buffer.
- Radek: I think of it the other way around. I think we should describe how
the pd_ref or gc_ref is connected to the ground.
- Walter: I would like Radek to work on the wording of this statement.
- I think if we can agree on this wording then 99% of the job is done.
- Arpad: Thank you all for joining.
AR: 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).
AR: Radek to propose ground connection language.
-------------
Next meeting: 22 September 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
