Minutes from the 27 March ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 27 March 2018
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
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
SiSoft: * Walter Katz
Todd Westerhoff
* 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 prepare a second draft of the new BIRD to supersede BIRD158.7.
- Done. (A draft2 was prepared in time for the previous week's meeting but
was not yet discussed).
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Discussion: Radek noted that his comments at the previous meeting had been
captured correctly, but he subsequently realized that the Ext_Gnd_Ref in
Randy's model was in fact internal to the subcircuit and not exposed as an
external node for the overall model. Therefore, this node had no special
significance.
- Arpad: Does anyone have any comments or corrections? [none]
- Radek: Motion to approve the minutes.
- Mike L.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD189 and BIRD158 related issues:
- Arpad: Michael Mirmak had asked the question, "What happens to BIRD189 if we
ignore BIRD158 for the time being?"
- My answer is that BIRD189 has no dependence on BIRD158, but there may be a
dependence in the other direction.
- We may just need to tailor BIRD158 to BIRD189.
- Radek: We have an unfinished discussion of A_gnd.
- We need a clear understanding of any BIRD189 interconnect and how it should
be handled in AMI simulations, not just BIRD158 simulations.
- Discussion: Walter asked the rhetorical question, "Right now, does BIRD189
work with [External Model]?" Walter then noted that BIRD158 is simply a
shortcut approach to an [External Model]. Bob and Radek noted that BIRD158
was confined to AMI applications. Walter noted that BIRD158 provides Info
type parameters so the tool can configure the analog model for the step
response calculation. It does not depend on .dlls, equalization, etc., or
any AMI specific concepts. Arpad and Bob noted that [External Model] may use
the seven defined terminals analogous to all the implicit [Model] terminals.
BIRD158, on the other hand, provides no way to get power and ground rails to
the buffer model and assumes ideal rails.
Walter noted that one could take a BIRD158 Ts4file model and create an exact
equivalent of it by using [External Model] to wrap a subcircuit containing the
S-parameter data. [External Model], as a replacement for [Model], only
goes as far as the buffer pads. It can work with BIRD189, and therefore there
is no issue with BIRD158 with respect to BIRD189.
Arpad noted that until we have final agreement on BIRD189 there is nothing
to do on BIRD158. Walter noted that BIRD158 does not contain "A_gnd". Arpad
agreed, but noted that it does contain the triangle reference symbols, and the
text vaguely explains them as "typically ... the global ground". Walter noted
the he thought we needed to decide whether A_gnd is a local reference or the
equivalent of node 0. Walter said he would make a motion at some point to
define it as node 0.
Bob noted that the latest (draft2) version of Arpad's proposed update to
BIRD158 had changed the language to include "A_gnd". Arpad shared his draft2
email and reviewed it. He noted that "typically be the global ground" was
vague, and he had changed the text to define the triangle symbols as "local
reference node, A_gnd of the IBIS [Model]" instead. Walter noted that every
other place in the IBIS spec that provided figures of this type was referring
to a device under test, i.e., the device being "measured" to create the
IBIS model. In that case the triangle reference symbol would be the test
fixture ground, which would be node 0 if you were "measuring" with simulation.
Walter noted that IBIS describes how the model is made, not how it should be
used. Bob agreed with this statement with respect to the S-parameter data.
However, he noted that a BIRD158 model is a simulation model because it
defines Vp and Vn (Tx_V) that should be used at simulation time. So, it's a
model made for use in AMI simulation. Radek agreed that we have to make it
clear how to use the model. Arpad said that to avoid a debate over whether
the figure is a measurement figure or a simulation time figure we should add
some explanatory text. Radek noted that we should add the word "model" at
the end of the Figure title ("Transmitter Analog Circuit" becomes "Transmitter
Analog Circuit Model"). Arpad suggested we table the measurement/simulation
discussion so he could think about what language we might add.
Ambrish noted that he thought we had also agreed to add language stating that
if you're using BIRD158, then you should not expect your simulation to be
power aware. Radek noted this was true of any AMI simulation. Arpad noted
that adding such language might be problematic if some vendors were to claim
they can make use of power aware models in AMI simulations. Walter provided
one example of a method for incorporating some power aware effects into a
BIRD158 simulation. He said one might fold time varying rail information into
a BIRD158 simulation by modulating the values of Vp and Vn. Arpad noted that
he didn't think we should add any text discussing "power aware". He noted
that it is understood that an AMI model is an LTI model.
Questions from the Quality group regarding parser decisions (BIRD158):
- Arpad: The Quality group asked a question about Rx_R.
- Text says if Rx_R is not present, it should default to open.
- However, it doesn't restrict the range of allowable values if it is present.
- Quality group is asking if it should be >=0 or >0.
- Bob: We (Quality) propose that we add to Arpad's new BIRD158 replacement BIRD.
- "... value of Rx_R in Ohms (greater than 0)."
- Discussion: Arpad modified his draft2 to add the "(greater than 0)" text to
the Rx_R and Tx_V sections. Radek noted that it could be done in a better way
grammatically. Walter noted that in other places, Rref_rising for example,
the spec does not explicitly state that it has to be a positive number. He
asked why we would start now. Radek agreed that it was obvious. Walter said
that adding new text was unnecessary, and the parser could simply adopt the
check for > 0. Radek noted that the topic had been discussed at the last IBIS
Open Forum meeting, and the parser could issue an error or a warning, either
was fine. He noted that no model maker will intentionally use unreasonable
values. Bob noted that it was true that we hadn't done it before, but that
these questions had come up while attempting to craft a parser development
contract. He noted that if we can't define it in the spec then we can't put
it in the parser contract.
Questions from the Quality group regarding parser decisions (BIRD179):
- Discussion: Mike L. noted that the example for Special_Param_Names contained
a single-column Table with one parameter name per row. He asked if ibischk
should require the names to be in a single column. He noted that
Supporting_Files explicitly specifies a single column of one or more rows.
Bob suggested an editorial change to copy the text from Supporting_Files
into BIRD179. Walter agreed. Arpad agreed that a single column was his
intent. Arpad moved to copy the text from Supporting_Files into BIRD179 as
part of the editorial process. Bob seconded. No one was opposed.
Bob noted that we may want to capture these editorial changes in a document
for the Editorial task group. Mike L. noted that we have a document
tracking reported editorial issues with previous versions of the spec, but we
have no document tracking editorial issues with approved BIRDs. Bob noted
that we might want to create such a document and add the BIRD158 and BIRD179
changes to it.
Mike L. noted that the Quality group's second question about BIRD179 was about
the parameter names themselves. Were they intended to be top level parameters
only, or should they be searched for at any level? Arpad said his intention
was that they be searched for at every level. Bob agreed, and noted that a
parameter name need only be declared in Special_Param_Names once, regardless
of where and how many times it was used.
- Curtis: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 03 April 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
