[ibis-macro] Minutes from the 21 June ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Thu, 23 Jun 2016 19:07:24 -0400

Minutes from the 21 June ibis-atm meeting are attached.

The following document, which was discussed during the meeting, was
previously posted to the work archive.

*DATE* AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html> TITLE
<http://ibis.org/macromodel_wip/archive-title.html> FORMATS
15-JUN-2016 Walter Katz SiSoft DUT_ref_term BIRD draft 2 (zip
IBIS Macromodel Task Group

Meeting date: 21 June 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
IBM                         * Luis Armenta
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
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
                            * Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

The meeting was led by Arpad Muranyi.


- Arpad asked if we should cancel the July 5th meeting because people might be
  away the week of the July 4th holiday.  Radek moved to cancel the July 5th
  meeting.  Walter seconded.  No one was opposed.  The July 5th meeting will
  not be held.
- As this was Kevin Li's first time joining the ATM meeting, Arpad asked him to
  briefly introduce himself.  Kevin said he works for Synopsys' SI PI group.  He
  works on generating IBIS and AMI models and is interested in the latest
  discussions on C_comp and Buffer model creation in general.

Review of ARs:

- Walter to update the DUT_ref_term BIRD draft to produce draft 2.
  - Done.  Draft 2 was emailed to the list and posted to the archives.

- Ambrish to check for a collaborator's feedback on his nearly ready new
  version of the Backchannel proposal.
  - In progress.

Call for patent disclosure:

- None.

Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]

New Discussion:

DUT_ref_term BIRD Draft 2:
- Walter: [sharing draft 2 of the BIRD]
  - Added Ext_ref as a possible selection for DUT_ref_term (as decided in last
    week's meeting).
  - Removed the superfluous initial phrase "If ... [* Reference] is not 0.0"
    from the first sentence of the "Other Notes:" section, as Bob had suggested.
- Walter: [reviewing his email to which draft 2 was attached]
    - Note that Ext_ref is not forbidden for drivers.  The IBIS spec only says:
        "Figure 16 - [External Reference] - (used only for non-driver modes)"
    - Nothing prevents Ext_ref from being used within a driver.  I'm not sure
      what the parser would do with it.
- Walter: [ reviewing Bob's spreadsheet (also attached to the email)]
  - I recommend using the same terminal names used by [Receiver Thresholds].
  - I'm going to propose that the Interconnect BIRD be changed to use them
    as well.
- Walter: We could use "Reference_terminal" instead of "DUT_ref_term" for the
          subparameter's name.
- Bob: I prefer a shorter name, though I understand the confusion because "term"
       could be short for termination.
- Arpad: I like "Reference_terminal" because it is clearer.
- Bob: I would go with "Ref_terminal," since its possible values are the *_ref
- Walter: Motion to change DUT_ref_term to Ref_terminal.
- Arpad: Second. [no one opposed, though Bob noted his preference for Ref_term]

- Discussion: Radek said he still disagreed with the paragraph in the BIRD that
  describes adding the value of the [* Reference] keyword to the voltages
  measured relative to the Ref_terminal.  He said if the keywords are the
  voltages relative to the reference terminal, then how could [* Reference] be
  non-zero for the terminal that served as the Ref_terminal?  Walter reviewed
  the IBIS spec's figure 16 [External Reference].  He said the [* Reference]
  keywords defined the voltage between the corresponding terminal and the test
  fixture ground (ground symbol in Figure 16) during the DUT measurement.  At
  simulation time, the difference between any local node and the Ref_terminal is
  computed and then the [* Reference] value is added in as the offset.  Arpad
  and Radek said the problem was that the v(t) tables in the IBIS file contained
  a voltage column that was relative to that test fixture ground (ground
  symbol).  Walter said that as soon as you compute the difference between the
  pad and the Ref_terminal at simulation time, you add in the [* Reference]
  offset and end up with a value you can use to go into the v(t) table (and
  other things like Vinl and Vinh thresholds, etc.)  Curtis said he thought of
  this step as converting the local relative measurements at simulation time
  (DIA) back to the "absolute" values that existed at DUT time because those are
  what are found in the IBIS file.  Walter agreed and said this was a nice way
  to describe it.  Walter also noted that the v(t) table itself is not really a
  problem at simulation time because it is only used to generated the K(t)
  scalers, and this is done with DUT conditions.  Radek said we had to be
  careful because things are simple with a basic C_comp, but once we have a more
  complicated block these assumptions could break down.  He said the fixed
  offset approach worked for the simple case, but he considered it to be
  compensating for the fact that the test_fixture/local ground terminal was
  "removed" from the model.  He said that in the most general case we really 
  to have that local ground terminal available to the model.  He said in the
  most general case you might have all 5 [* Reference] values non-zero.  In that
  case you would still need a separate terminal for the actual local ground.
- Discussion: Walter agreed with Radek's point about the most general case.  He 
  said that in our discussion on this topic we all agreed that at simulation
  time (device in action), you can't really measure the voltage between buffer
  terminals and some far away test fixture ground.  Yet, for DUT measurements
  we assume we can.  In practice this is because there really must be some other
  Pin on the component's package that can be used to connect to "ground."  It
  may not be one of the four rail terminals we've identified in the IBIS
  [Model], but we know there must be some ground pin local to the component for
  any of these measurements to make any sense.  For example, if you have PECL
  and the [Model] says the rail voltages ([* Reference]) are not zero, there
  must be some Pin which is ground and relative to which they are not zero.
  It's just not a pin that takes a part in the operation of the particular
  buffer.  Walter reiterated a suggestion that we ought to have a new additional
  terminal called a reference terminal (e.g. DUT_ref), just like we have 
  Pullup_ref, etc., added to the [Pin Mapping] section.  With that new column in
  [Pin Mapping] you could specify a Pin (bus label) which is in fact the local
  ground for the [Model].  Radek said this was what he has been advocating, too.
  Walter reviewed an alternate version of the BIRD he had been drafting, which
  contained a new model terminal DUT_ref that you can add to [Pin Mapping] and
  add to the list of terminals that can be assigned to the Ref_terminal, and its
  corresponding [* Reference] is by definition always 0.0V.  DUT_ref is used to
  identify the Pin in the system that is connected to the ground.  Radek again
  agreed and said that one could do it this way by extending [Pin Mapping], or
  could do it with the additional [Pin Reference] keyword Walter had described
  in the alternative Pin Reference BIRD.  He noted that one inconvenience of
  extending [Pin Mapping] was that the sixth column 'Ext_ref' was optional and
  maintaining backward compatibility by adding a seventh column 'Dut_ref' would
  put a more important column (7) after a less important column (6).  Bob asked
  why declare a DUT_ref if it's always known to be 0.0V?  Radek said he hadn't
  thought it through fully, but that in the most general case you might have
  a situation where the DUT_ref terminal's [* Reference] was non-zero and the
  other reference terminals were considered connected to it if they shared the
  same value in their [* Reference].  Bob said he considered DUT_ref's
  [* Reference] to be 0.0V fixed, and that all the other [* Reference] values
  were all relative to that 0.0.  Arpad asked if the existing reserved terminal
  name A_gnd might be used for this purpose instead of inventing a new terminal
  name.  Radek and Walter thought that this could be done.  Radek noted that we
  would need to extend A_gnd beyond the Multi-Lingual Model Extensions context.
- Discussion: Arpad asked what remained to do to complete discussions and move
  on to formalizing the BIRD draft.  Walter asked if we agreed that we would go
  with the DUT_ref that is always 0.0V?  If so, in a power aware simulation we
  need a way to specify what Pin or bus label serves as that reference.  In that
  case we need to add something to [Pin Mapping] to define it, or we could use
  the [Pin Reference] proposal for that association and make it optional and
  only used for cases in which none of the existing five [* Reference] values
  were 0.0.  Radek agreed.  Walter said he and Radek agreed, if any of the
  five existing [* Reference] values is 0.0, then the corresponding terminal
  can be the reference terminal for simulation.  If not, then the model maker
  needs a way to assign the Pin that will serve as the DUT_ref terminal.  Walter
  said he would write up these changes.  Bob said he saw no value in adding a
  specification of something that is always 0.0V.  He felt this was already
  implicit, and that the other [* Reference] values are by definition ideal
  fixed offsets from it, so any one of their corresponding terminals could
  be used as a reference.

- Arpad: Thank you all for joining.
Next meeting: 28 June 2016 12:00pm PT

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 21 June ibis-atm meeting - Curtis Clark