Minutes from the 09 February ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 09 February 2016
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
* Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: 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
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------
Review of ARs:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Bob M.: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Fixing [Pin Mapping]:
- Walter: I think this can be removed from the agenda.
- We are handling it in the interconnect task group meetings.
- Arpad: I am okay with that.
- Does anyone have any comments on removing this from the agenda? [none]
- I will remove it.
New Redriver Flow BIRD:
- Arpad/Walter: Not worth discussing today without Fangyi here.
Discussion of language corrections regarding "ground":
- Discussion: Walter said he thought we had generally agreed in last week's
meeting that the IBIS spec's use of ground was largely okay with respect to a
device under test (DUT) and measurement of data (test bench or simulation).
He said that we needed to fine tune wording and clarify the context of some of
the sections, but that this could be dealt with in an editorial task group.
He noted that Radek had expressed a desire to go further and clarify certain
concepts with respect to a device in action as opposed to just the DUT. He
said he had no objections to that, but didn't think it was necessary. Radek
agreed with Walter's suggestion, and confirmed that he would want to be a part
of the editorial task group. He suggested that task group could work on
clarifying the ground language to create IBIS 6.2, and also could produce
additional BIRDs for reference node clarifications, etc., as necessary.
Walter agreed that topics might come back to the ATM group if necessary. Bob
agreed with Walter's suggestion and confirmed his interest in working with
the editorial task group. Mike L. and Arpad raised some logistical questions,
and confirmed that Michael M. had served as chair and editor-in-chief for
previous editorial task group projects. Michael M. agreed to serve in both
roles again this time. The editorial task group typically meets on the
Fridays when there is no Open Forum meeting. Radek said he would be extremely
busy for the next two weeks and unable to start on this task. Arpad suggested
that the inaugural editorial task group meeting be scheduled for March 4th,
the Friday after the next Open Forum meeting. Everyone agreed with this, and
Michael Mirmak took the action item to send out a kickoff announcement email
to the IBIS lists.
How to handle missing min/max data?:
- Arpad: I have no updates on this topic and haven't had time to work on it.
- Walter had some new thoughts he wanted to share.
- Walter: After studying the ground language, my understanding of IBIS is that,
at least for legacy models, IBIS only talks about how to measure I/V,
and v(t) and Composite Currents (measure, again meaning test bench or
simulation).
- Everything is relative to a reference node and based on measurement.
- Therefore, all of the parameters are based on measurement.
- So when some parameter only has a typ value, does that mean they only
measured it under typ conditions, or they only have one value?
- You're normally measuring three devices, a typ, min, and max device.
- Implication is that threshold parameters, etc., are all derived from those
measurements.
- If you have Vinl, Vmeas, etc., and only have a typ value, what is it for?
- Is it the same value for the min, typ, and max DUT?
- Or, is it only for the typ DUT.
- My interpretation is the typ value is also for the min and max DUT.
- If you have a min value for a parameter, did it come from measuring the
min device or the max device?
- IBIS has to tell you how to measure things, so I think we have to go ahead
for each parameter and say what it means to only have a typ value, because
it's a measurement specification not a usage specification.
- I think Arpad wrote up this topic as "How do you use something?"
- I don't think IBIS should tell you how to use data, it should tell you how
they were measured.
- Arpad: When I started thinking about this issue, it was raised by the question
of how the simulators would use the data.
- But it was also triggered by some statements in the spec that say you
should use the typ value for min and/or max if those columns contain NA.
- At that point we had never had any discussion regarding normative vs.
informative, so I thought the spec was actually giving instructions on how
to use the data or what to do if min and max data were missing. I thought
those were normative instructions.
- Now Walter is indicating that since IBIS is a measurement spec and really
shouldn't be mentioning how things are used, any of mention of how to use
things is informative not normative.
- Bob: We already have voltage sensitive specifications.
- In [Model Spec], where we have typ, min, max, there are parameters that
allow for the explicit declaration of specification thresholds as they
vary with the voltages.
- Discussion: Walter agreed with Bob's point regarding [Model Spec]. However,
they had different opinions on how data for the subparameters might be
obtained. Walter described some measurement scenarios to determine the
relationships between the parameters (e.g., a threshold varying with rail
voltage), but Bob said they were created with the expectation of holding
ranges from data sheet values. Walter said both were valid interpretations,
and that since typ, min, max would mean different things depending on the
interpretation even this suggested the IBIS spec had to more carefully define
the way each IBIS parameter was measured. He said that the question of
missing min max data was secondary to the question of exactly how to handle
min max data if you did have it. Arpad raised the point of this new
suggestion that IBIS was only a measurement spec and asked if we were really
moving forward with this approach. Radek again pushed back on the idea, and
again suggested that IBIS both defined the measurements and defined things
that were necessary for unambiguously creating a useful behavioral model.
Arpad then said that we needed to resolve this larger question in order to
tackle this specific topic of missing min max data. He said there were some
inconsistencies in the spec currently, as it said to use the typ value for
missing min max data in some places but not others. He also pointed out
that using typ raised many additional questions, as you might run into
trouble if you only had typ v(t) curves but had typ, min, and max I/V
tables, for example. All the combinations and possibilities were not
spelled out, and the statements about using typ might be incorrect or
misleading. The question of ranges was discussed, with Arpad wondering if
ranges implied specification limits (absolute bounds on behavior) or
statistical chip behaviors (e.g., 3 sigma bounds). Radek pointed out that
he thought the spec said only the typ, min or max values are to be used
and not values in between them. Arpad did not think the spec prohibited this.
K(t) tables were also discussed, as an example of something most simulators
do without explicitly being told to by the IBIS spec. After these discussions
of various concepts that might be vaguely specified and require clarification,
and whether the spec should ever tell the EDA tool what to do with data, Arpad
took the AR to go through the spec and find all instances where typ was
stated as serving as the default for missing min and max data.
Note: Radek had to leave the call at this point.
Buffer Impedance / C_comp improvements:
- Walter moved to untable the topic.
- Randy seconded. No one was opposed.
- Walter: In private discussion with Randy and Michael M., we've discussed the
idea of adding the IBIS b-element (HSPICE b-element) to IBIS ISS.
- Understanding that ISS currently stands for interconnect SPICE subcircuits,
set that aside for now.
- If we take the b-element and use External Model to add whatever one wanted
as a C_comp compensation as IBIS ISS elements, it might be an alternative
to adding a SPICE subcircuit for C_comp in our legacy IBIS models.
- Arpad: I think I would be in favor of that.
- Would we have to ask Synopsys for permission to do so?
- Walter: I would ask them. I don't think it will be a problem.
- Their b-element is quite complicated.
- All we need is a basic subset of it (file, model, ports).
- There is one issue with handling the effects of the C_comp circuit.
- We know how hard it can be to generate the K(t) function, even with a
regular C_comp, because the v(t) data might not be well measured.
- One idea Randy and I came up with is to have the model maker give a C_comp
effective that the tool uses to generate its K(t) curves, then the tool
can apply those K(t) curves using the more complicated actual C_comp
compensation circuit.
- I wanted to introduce those concepts. I could put together more thoughts on
this for next week.
- Arpad: Thank you all for joining.
AR: Michael M. to send out a kickoff email for editorial task group meetings
starting on March 4th.
AR: Arpad to review the spec and find all instances of language stating that the
typ value should serve as the default for missing min max values.
-------------
Next meeting: 16 February 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
