Minutes from the 26 March ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 26 March 2019
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC: David Banas
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Ming Yan
Stephen Slater
Maziar Farahmand
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
* Mike LaBonte
SPISim: * Wei-hsing Huang
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Arpad to submit Rx_Receiver_Sensitivity BIRD draft_4 to the Open Forum.
- Done (BIRD199).
- Walter and Mike L. to draft an email response to the BIRD198 submitters.
- Done (to be reviewed in this meeting).
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the March 12
meeting. Walter moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
Draft response to the authors of BIRD198:
Walter reviewed the draft he and Mike L. prepared. He first reviewed three
statements intended to describe our understanding of the intent of the BIRD.
Statement 1:
* The [PDN Model Mapping] defines a model between two pin names in the [Pin]
section, but we believe the intent is to define a model connected between the
power/ground rail signal networks associated with those pins.
Arpad and Radek agreed this was their general interpretation of the intent. Bob
noted that BIRD198 specifies connections between [Pin]s, but [Pin Mapping] can
extend that to on-die bus label and signal names. Walter asked if we thought
that was their intent. Bob noted that in examples the authors had included bus
labels. Arpad noted that this BIRD could be analogous to the series model
specified between pins with [Series Pin Mapping]. As he had noted in the
previous meeting, pin names were used because that's all IBIS had at the time,
but the implicit connection is actually on the pad side. He said this would
apply to BIRD198 as well. If the pads implicitly referenced in BIRD198 were
connected to anything else via bus labels, they would all be considered shorted
together. Given this interpretation, Walter concluded the first statement of
intent was incorrect, and he changed it to:
* The [PDN Model Mapping] defines a model between two pin names in the [Pin]
section, but we believe the intent is to define a model connected between the
power/ground rail signal networks (signal_name or bus_label) associated with
those pins.
Statement 2:
* We believe this model would be limited to on-die decoupling capacitance
connected between rail signal names. Any decoupling capacitance between rail
signals on the package (for example, package decoupling capacitors) would not
be included in this model. That capacitance would have to be included in a
package model.
Walter said the intent of the statement is to ensure that this model is confined
to on-die only effects. Any package effects must be in the package model.
Based on the previous comments with regard to bus labels, this second statement
was changed to (note the addition of "or rail bus_labels"):
* We believe this model would be limited to on-die decoupling capacitance
connected between rail signal names or rail bus_labels. Any decoupling
capacitance between rail signals on the package (for example, package
decoupling capacitors) would not be included in this model. That capacitance
would have to be included in a package model.
Statement 3:
* We also believe that BIRD 198 implies that all of the on-die pads and on-die
buffer connections to each rail supply voltage (signal name) are short-
circuited, so that there is a direct connection, and no rail interconnect
circuit elements, between the supply rail die pads and the buffer supply rails.
This statement was intended to note that there is no on-die power distribution
other than the decoupling caps defined in this BIRD's model. Arpad agreed. He
noted that this proposal was written without consideration of the new BIRD189,
and it likely is based on the legacy IBIS constructs in which buffer and die-pad
locations are considered to be the same.
Based on the previous bus label discussion, this statement was also amended
to include bus_labels.
Mike L. noted that we needed to be careful to refer to "rails" and say that they
are identified bus labels. Walter agreed wordsmithing could be undertaken, and
noted that he had used signal names and forgotten this would apply to bus labels
too.
Walter noted that he had some thoughts on a proposal for streamlining the syntax
of the proposed BIRD, particularly for the parser. But after a brief discussion
he and the group decided that we should not pursue that at all at this time.
The primary goal for now is to investigate whether BIRD189 can provide an
acceptable and more general solution to the problem addressed by BIRD198. We
can worry about any possible refinements to BIRD198 later, if necessary.
The email provided an example of a BIRD198 model implemented using BIRD189. It
also provided several suggestions for addressing the shortcomings of BIRD189
in this scenario (corners, need for an additional file for the ISS model, etc.).
Arpad suggested we keep it simple at this point, and not get involved in
discussions about how we might address any issues BIRD189 has right now.
We simply note the issue with respect to corners, and state that we could work
on improving that support later, for example. Mike L. agreed. Bob noted that
he didn't understand why one suggestion was for a hard coded "reserved" file
name for this type of model. Walter noted that he was attempting to address the
authors' concerns about additional complexity and needing to add extra files.
If we had a reserved file with a given structure (their model), the parameters
would simply be provided in the IBIS file, not an additional file. Radek noted
that this was a valid point, if we are encouraging the authors to consider
BIRD189 instead of their proposal, we should to have a way to define their model
structure without the additional complications of an extra file. Bob noted that
this would be falling back to the authors' proposal in the sense that you'd have
a fixed simple topology.
Bob noted that [Series Pin Mapping] and series models already provide a superset
of this BIRD198 proposal. Everything in BIRD198 could be done with [Series Pin
Mapping]. Mike L. noted that the authors wanted PDN_ in the name to make it
clear that a PDN was involved. He noted that he and Walter had used PDN_
in all their BIRD189 example names for this reason.
Randy noted that it might be hard for the parser to figure out if BIRD198
parameters collide with a BIRD189 model. Arpad noted that BIRD189 could define
a package model, and then BIRD198 might be connecting pads, so this interaction
could be tricky. Arpad proposed that we add an additional question to the
email, what is the authors' intent for the interaction of this proposal with
BIRD189? Walter added:
* Was your intent for this proposed syntax to be used along with BIRD189 models
or exclude using these models with BIRD189 models?
Bob noted that we might want to reference slide 7 from Murata-san's DesignCon
presentation. It states that another method for supporting die-caps using IBIS
7.0 will be investigated. We can state that we are attempting to help with the
investigation. There are many advantages to BIRD189.
Walter took the AR to send out the modified draft response to those in
attendance, field any requested changes, and serve as master editor.
- Michael M.: Motion to adjourn.
- Mike L.: Second.
- Arpad: Thank you all for joining.
AR: Walter to send out the modified draft response for further review by those
in attendance.
-------------
Next meeting: 02 April 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
