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
<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>
)
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.
--------------------------------------------------------------------------------
Opens:
- 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
terminals.
- 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
want
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
Ext_ref,
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
