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
<http://ibis.org/macromodel_wip/archive/20160615/walterkatz/DUT_ref_term_BIRD_draft_2.zip>
)(docx
<http://ibis.org/macromodel_wip/archive/20160615/walterkatz/DUT_ref_term%20BIRD%20draft%202/DUT_ref_term_2.docx>
)
14-JUN-2016 Walter Katz SiSoft DUT_ref_term BIRD draft 1 (zip
<http://ibis.org/macromodel_wip/archive/20160614/walterkatz/DUT_ref_term_BIRD_draft_1.zip>
)(docx
<http://ibis.org/macromodel_wip/archive/20160614/walterkatz/DUT_ref_term%20BIRD%20draft%201/DUT_ref_term.docx>
)
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.
--------------------------------------------------------------------------------
Opens:
- 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
terminal.
- 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
