Minutes from the 14 January ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 14 January 2020
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
Ken Willis
Kumar Keshavan
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
* Todd Bermensolo
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): Walter Katz
Mike LaBonte
SPISim: * Wei-hsing Huang
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that we will have a meeting on the 21st of January. The meeting
scheduled for the 28th is cancelled because of DesignCon.
- Michael raised a discussion item about how AMI String parameters are handled.
There were two questions. The first was related to if/how empty strings are
handled. The second was a follow-on from Ambrish about the handling of double
quotes.
-------------
Review of ARs:
- Walter to send the BCI for statistical proposal to Randy for submission to the
Open Forum as a BIRD.
- Done. BIRD201 was introduced at the last Open Forum meeting.
- Fangyi to send the modified version of BIRD197 to Randy for submission to the
Open Forum as BIRD197.7.
- Done. BIRD197.7 was introduced at the last Open Forum meeting.
- Walter and Randy to work on a new iteration of a proposal for BIRD198.
- Randy reported he had some updated feedback to discuss before sending to the
BIRD authors.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the January 07
meeting. Randy moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD198:
Randy reviewed the syntax change suggestions and feedback that Randy, Walter,
Arpad, Bob, and Mike L. had discussed. The feedback focused on the syntax
examples the BIRD198 authors had provided. Randy noted that the group was
fine with much of the proposal, but some proposed changes were:
- The definition of the PDN requires two terminals, and the group agreed the
terminals should be able to be defined by signal_name or bus_label. They
propose a syntax to accomplish this.
- The "_case" suffix isn't needed for the names of the C and R parameters.
- The original example used lower case g for gig, but it must be G.
- Suggesting the possibility of wrapping all the PDN domain sections inside
a PDN domain begin/end keyword pair. Since the sections are all scoped
under component, we either need a rule that they all have to be listed
sequentially, or just define the being/end pair to wrap them all.
- Suggesting that we leave it to the authors to explicitly define what the
allowed parameter values and combinations are.
- Suggest we allow NA to be used in min and max columns and specify that EDA
tools use the typ value in such cases.
- Suggest rules for allowable combinations of these values, e.g., is it
allowable to not specify an R_leak? Specify what default values the EDA
tools should use if a parameter is not defined.
- Suggest a rule for the default model an EDA tool should use. If there are
multiple PDN models under a PDN domain, the first one is the default.
Bob noted that a typ value is required if a parameter is used in the model. He
also noted that since these parameters could follow process-voltage-temperature
conditions, not numerical min <= typ <= max, the ibischk parser would not be
checking relative magnitudes of typ, min, max values.
Arpad asked if we would draft a new revision of this BIRD based on the feedback
or if that would be done by the original authors? Randy noted that he planned
to encourage the authors to create a new BIRD198.1 after reviewing our feedback.
Randy said that he would send out his proposed reply to the other members of the
small group for a final review prior to responding to the authors.
AMI String parameter questions:
Michael reviewed an email he had sent to ATM the day before the meeting. The
email quoted the definition of the AMI Type String. He provided an example with
a String parameter with Format List in which the values were:
... (Type String) (List "Good" "Bad" "Indifferent" "") ...
Michael noted that ibischk7.0.1 (as well as earlier versions) parsed this
successfully, but he said that the "" empty string did not appear to be
explicitly allowed by the specification. He noted that several Reserved
parameters, e.g., Supporting_Files, and Model_Specific branch names explicitly
prohibited empty strings as values.
Michael noted that the null character 0x00 was not explicitly listed by the
specification as one of the allowable ASCII characters, and he asked if it
should be. Arpad noted that the null character is the C-style string
termination character, but in the .ami file we have the parameter's value in
double quotes and the end of the string is clear. Radek said we should not add
any mention of the null character to the spec. He noted that the null character
is a programming-side issue. We could decide to state that an empty string is
allowed as a parameter value, but this has nothing to do with the null
character.
Michael said his primary concern was whether we should state that an empty
string value is permitted. Arpad suggested we might state that a zero length
string is allowed. Michael noted that we might need to say that it's allowed
"unless otherwise prohibited", since there are already parameters that
explicitly disallow empty string values. Bob noted that the "unless otherwise
prohibited" statement might need to be strengthened, since there were other
parameters, e.g., Repeater_Type, that had enumerated acceptable values, and the
empty string would not be acceptable. He said tightening up the language and
dealing with these cases could complicated any BIRD.
Ambrish discussed the question he had posed in a reply to Michael's original
email. Ambrish asked if the "" double quotes delimiting the String value in
the .ami file should be passed to the model by the EDA tool. For example,
should this:
(filename "abc.txt") <-- including the ""
or this:
(filename abc.txt) <-- not including the ""
be part of the ami_parameters_in string argument sent to the model?
Arpad said he thought the "" characters just define the endpoints of the string
value in the .ami file, and they should not be passed to the model. Ambrish
agreed. Radek and Curtis disagreed and said the "" characters should be in
the string passed to the model. Radek asked what happened if the filename in
this example included spaces? Ambrish agreed the tool would probably have to
pass the surrounding "" in that case. Curtis asked what would happen if the
string value contained '(' and or ')', and noted that at a minimum this would
make life more difficult for the model's parser if the surrounding "" weren't
passed. Radek said the model should definitely be able to deal with it if
the "" characters were passed to it. Ambrish said it was one thing for the
model to handle the "" characters, but was it valid for the model to require
that they be there? Radek said Michael's question about allowing empty strings
provided a good example. If you're going to allow empty strings, what would
you pass to the model in the empty string case if you don't pass the ""?
Arpad asked if we would need a BIRD for this and who would volunteer to write
it? Ambrish suggested discussion could continue via email.
- Curtis: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.
AR: Randy send the reply to the BIRD198 authors after final review by the small
working group.
-------------
Next meeting: 21 January 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
