Minutes from the 21 July ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 21 July 2020
Members (asterisk for those attending):
Achronix Semiconductor Hansel Dsilva
ANSYS: * Curtis Clark
Wei-hsing Huang
Cadence Design Systems: * Ambrish Varma
Ken Willis
* Jared James
Google: * Zhiping Yang
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
* Ming Yan
Todd Bermensolo
Stephen Slater
Rui Yang
Marvell Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
Mike LaBonte
Teraspeed Labs: * Bob Ross
Zuken USA: * Lance Wang
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Randy to create a BIRD draft for the Component_Name and Signal_Name Reserved
Parameters proposal.
- Done.
- Zhiping to email links to past Summit presentations and info about his
upcoming EMC SI+PI conference presentation to ATM.
- In progress, mail will be sent shortly after this meeting.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the July 14
meeting. Randy moved to approve the minutes. Lance seconded the motion.
There were no objections.
-------------
New Discussion:
Component_Name and Signal_Name Reserved Parameters BIRD draft:
Randy shared the new BIRD draft and noted that it was largely the same as the
previous week's proposal, but it was in official BIRD draft form. It introduces
two new AMI Reserved parameters, Component_Name and Signal_Name, that are Format
String and Type In.
In the Definition of the Issue: section, Randy describes the possibility of the
executable model maintaining a list or look-up table based on the Component
name and signal_name from the IBIS file. The combination of the two could form
a unique identifier for a particular Tx or Rx on the die, and the executable
model could use the look-up table to store buffer-specific characteristics, such
as DQ to DQS delay. This would allow one executable model to fully model
multiple buffers. The EDA tool would pass the Component name and signal_name
information in via the new parameters.
Randy noted that he added a new sentence in the Usage Rules: sections explaining
that a tool should pass in "NA" if the simulation setup is such that the tool
doesn't know the Component name or signal name. He had also added examples
using Value and Default. Randy said he and Curtis had discussed the issue,
and he asked for thoughts on the "default" value in the file. Curtis said he
had proposed to Randy that we might consider putting a meaningful default value
in the .ami file (in the Value or Default). This might give older tools that
don't recognize the parameter a better chance of passing in a reasonable value.
Perhaps we simply put "NA" in the Value in the .ami file, in addition to the
statement that the tool should pass in "NA" if it doesn't know the values of
the Component name or signal_name.
Bob objected to the use of "NA", and said it is expressly illegal for a
[Component] to be named "NA". Radek said that made "NA" a good choice for use
with the Component_Name parameter. Arpad noted that "NA" is a valid name for
a signal_name, and he suggested the tool should instead pass in an empty
string ("") if it doesn't know the Component_Name or Signal_Name. Randy
made the change from "NA" to "".
Arpad said he didn't like the example with a Default value of "Memory_x8", as
he didn't think it was good to have a meaningful value in the .ami file. The
group decided the entire Default example was redundant, since Value and Default
are essentially interchangeable in this case. Randy removed it.
Randy asked if it was necessary to mention that these new parameters would be
passed in to AMI_Resolve as well as AMI_Init. Radek suggested the text should
continue to include AMI_Resolve, as the values of these two new parameters
might affect AMI_Resolve's decisions about other Dep parameters. Randy left
the mention of AMI_Resolve intact.
Ambrish and Arpad asked if we should state that the model should act as if it
had recieved the value ("") if the EDA tool doesn't pass in these parameters at
all. Randy said that we don't explicitly state what the model should do if EDA
tools choose to ignore other parameters. Radek and Curtis noted that the
specification explicitly states that the EDA tools should pass in the values of
each and every In and InOut parameter. In 10.3.6, page 222:
The EDA tool shall pass a string to the executable model through the
AMI_parameters_in argument. This string shall contain all of the
leaf-formatted Usage In and Usage InOut AMI parameters if there are any
defined in the .ami file.
So, even if in practice some parameters might not be sent in certain situations
(e.g., older tools that don't recognize a new parameter), we don't want to
codify that in the specification.
Randy said he would send out a modified draft. Arpad said he would keep it on
the agenda for the next meeting.
Supporting PI modeling/simulation in IBIS:
Zhiping said he had nothing new to present, and he encouraged any questions or
feedback related to his ideas about adding PI modeling information to IBIS.
Zhiping asked if there were any policies or requirements related to inviting
other PI people to the ATM meetings. Arpad said the discussions are free and
open to anyone, they just wouldn't be able to vote if they weren't IBIS
members.
Topic bin list:
Randy noted the longstanding topic "Fix all the referencing problems in the
current specification (after Randy's C_comp proposal and BIRD189 are done)".
Randy asked if anyone was interested in tackling the topic. Arpad asked if
BIRD181.1 is still the place to tackle the referencing issues. Bob said that
it is, and that it addresses references, terminals, the meaning of various
voltage ranges, etc., and introduces a SPICE like syntax for indicating the
potential difference between two nodes.
Arpad noted that it had been a recent topic on the SIlist, and he had seen
package models formulated with only a 2 port S-parameter, i.e., two terminals
for the VCC path and no separate path for VSS, instead of the 4-port
partial loop models we specify in IBIS. Bob said in practice we can define
what we want, but it may be a subset of what the industry at large tries to
do.
Bob noted that certain assumptions, including ideal ground, were built in to
early work in Chapter 9, Data Derivation. However, if we understand the
original intent of the data derivation, we can explicitly generalize the
assumptions for modern application scenarios. It's just that it will be a long
arduous process to get agreement on the generalizations and make the editorial
changes.
Randy said the answer to his original question boils down to: Do we finally want
to deal with BIRD181? Randy suggested that we could leave it alone for now
unless someone wants to lead the effort. We have plenty of other things to work
on.
- Ambrish: Motion to adjourn.
- Bob: Second.
- Arpad: Thank you all for joining.
AR: Randy to send out a modified version of the Component_Name and Signal_Name
BIRD draft.
-------------
Next meeting: 28 July 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
