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

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Thu, 16 Jun 2016 13:41:16 -0400

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

The following document, which was discussed during the meeting, has been
posted to the work archive.  Draft 2 contains the changes agreed upon
during the meeting.

*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
14-JUN-2016 Walter Katz SiSoft DUT_ref_term BIRD draft 1 (zip
IBIS Macromodel Task Group

Meeting date: 14 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
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

The meeting was led by Arpad Muranyi.


- None.

Review of ARs:

- 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]
- Dan: Motion to approve the minutes.
- Mike L.: Second.
- Arpad: Anyone opposed? [none]

New Discussion:

New Redriver Flow BIRD:
- Discussion: Fangyi reported that discussions had settled on the approach for
  the new flow, and he is currently converting the proposal into a BIRD.

DUT_ref_term BIRD Draft:
- Walter: [sharing draft 1 of the BIRD]
  - The boiler-plate requirements sections of this BIRD are identical to those
    from the earlier [Pin Reference] BIRD.
  - This approach simply introduces a new [Model] subparameter: DUT_ref_term.
    - It is set to one of four values specifying which reference terminal
      serves as the overall reference terminal (Pulldown_ref, Gnd_clamp_ref,
      Pullup_ref, Power_clamp_ref).
    - It defines the terminal from which all terminal voltages are measured.
    - You make those relative measurements in the simulator.
    - The "Other notes:" section describes how you adjust for the offset if the
      [* Reference] keyword corresponding to the specified reference terminal
      has a non-zero value.
    - Note that Bob would prefer to remove the introductory phrase, "If the
      reference terminal's corresponding DUT test condition voltage
      [* Reference] is not 0.0," since one could just add the offset all the
      time even if it is 0.0.
- Discussion: Arpad noted that he would prefer to spell out "terminal" as
  opposed to "term" in the subparameter's name, because "term" could be an
  abbreviation of several different words.  Bob said that he preferred "term"
  for brevity, but understood Arpad's point about clarity.  Radek said he agreed
  with Arpad and added that he didn't like the "DUT" abbreviation in the
  subparameter's name either.
- Discussion: Arpad asked if Ext_ref and/or some additional reserved terminal
  names, such as A_gnd from [External Model] and [External Circuit], should
  also be included as options for DUT_ref_term.  Walter said only Ext_ref could
  be added easily, as it is defined in [Pin Mapping].  He noted that he liked
  the idea, but that Bob had asked him not to include Ext_ref as an option.
  Walter said he thought Ext_ref should be an option.  Referring back to the
  RS-232 example, he said you might have +14 and -14V power rails, and there
  is a 0.0V external reference that is provided by another Pin.  Ext_ref could
  be used to provide that 0V reference via [Pin Mapping].  Bob said he felt this
  would be a misapplication of the Ext_ref.  Arpad asked why, and said that
  historically Ext_ref had been added when differential receivers were being
  adopted with a common reference instead of individual references, i.e.,
  independent negative input pins for each receiver.  Arpad and Walter noted
  that, as currently defined, [External Reference] is explicitly defined as a
  reference for Input receiver measurements.  Bob said it was added because some
  buffers have a separate terminal for an external reference that may be created
  by a voltage divider or provided externally and is used as a reference for
  threshold measurements.  He said that was its only application, and that is
  why it's declared as a separate supply.  He said it was not intended for use
  with respect to I/V tables.  Walter stated that it would work perfectly fine
  for this purpose as well.  Walter said that an RS-232 would have +14 and
  -14 volt rails, and was also guaranteed to have some 0V terminal, which
  could be provided by Ext_ref.  Bob said that Ext_ref was already declared as
  a separate POWER or GND type model, and that it did not actually exist as
  part of the RS-232 Signaling [Model] itself.  He said it was used so the
  receiver had an alternative way of creating a reference that might be a
  different Pin from the power rail Pins used by the Model.  Walter said that he
  couldn't see any distinction between what Bob was stating and this proposed
  new use of Ext_ref.
- Discussion: Radek said he still didn't get the concept of what was proposed.
  He said that you define one of the 4 (or 5 if Ext_ref is added) choices as the
  reference terminal, and then say if the value of the [* Reference] is non-zero
  then you add that to the voltages measured relative to the reference terminal.
  He said it made no sense, for example, to say that you measured a potential
  difference of zero between two terminals and then added in some delta.
  Walter said that the offset methodology was designed to take into account the
  voltage value that was at the reference terminal at DUT time when the DUT
  threshold measurements were taken.  He said you can only measure the potential
  difference between buffer terminals, and then you use the offset to convert
  those differences to the absolute values recorded in the IBIS thresholds,
  etc., which are based on the DUT conditions.
- Discussion: Radek pointed out that Ext_ref is only defined for receivers, so
  relying on it would not solve the issue for drivers.  Walter agreed with this
  point and said Ext_ref might have to be extended.  Radek still favored having
  the actual local ground (0V) reference terminal explicitly defined.  Walter
  proposed that we might say Ext_ref is valid for inputs and outputs, and then
  require that for any IBIS [Model] one of the five [* Reference] DUT values
  must be 0.0.  Radek thought this was one possible approach, but IBIS currently
  had no requirements of that nature.  Bob objected to this suggestion.  He said
  that he was fine with adding Ext_ref, but that RS-232, for example, could be
  handled perfectly well without using Ext_ref to provide the 0v terminal.  He
  felt the offset approach could be used, for example defining the -14V rail as
  the reference terminal and using the -14V offset approach could provide a
  properly functional solution without explicitly providing the 0V local ground
- Discussion: Arpad asked that we not mix too many additional changes and
  proposals into the discussion.  Radek agreed and said that while requiring one
  of the five [* Reference] values to be 0.0 would solve this issue, it was a
  drastic change to the spec.  Walter said he would simply update draft 1 to add
  Ext_ref as a possible terminal and add [External Reference] to the list of
  values in the "other notes:" section.  Arpad and Bob were in favor of this,
  and Bob noted his general agreement with the BIRD.  Walter noted that this
  discussion had grown out of interconnect task group discussions related to
  getting everything to work with package models and floating grounds, etc.  He
  said that at this point everything was working well, unless we had a [Model]
  in which none of the [* Reference] values were zero.  In that case, we still
  don't cover power aware simulations properly.  Arpad noted that he recalled
  that case would cause problems with respect to Vinl, Vinh , threshold values
  in general, but he thought that the power integrity related keywords
  ([Composite Current], [ISSO *]) were among the only ones that already were
  properly defined with respect to referencing.
- Curtis: Motion to adjourn.
- Mike L.: Second.
- Arpad: Thank you all for joining.

AR: Walter to update the BIRD draft to produce draft 2.

Next meeting: 21 June 2016 12:00pm PT

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

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