[ibis-macro] Minutes from the 09 February ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Thu, 11 Feb 2016 12:56:43 -0500

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.


- 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
  - 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
  - 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

Other related posts:

  • » [ibis-macro] Minutes from the 09 February ibis-atm meeting - Curtis Clark