Minutes from the 28 June ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
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
28-JUN-2016 Walter Katz SiSoft Pin Reference BIRD draft 5 (zip
<http://ibis.org/macromodel_wip/archive/20160628/walterkatz/Pin_Reference_BIRD_draft_5.zip>
)(pdf
<http://ibis.org/macromodel_wip/archive/20160628/walterkatz/Pin%20Reference%20BIRD%20draft%205/Pin_Reference_5.pdf>
)
IBIS Macromodel Task Group
Meeting date: 28 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 reminded everyone that the July 5th meeting has been cancelled.
-------------
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]
- Walter: Motion to approve the minutes.
- Bob: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
IO Buffer Reference Terminal proposal:
- Walter: [sharing draft 5 of the Pin Reference BIRD]
- This version contains lots of cleanup and detail improvements.
- It is significantly improved over the last version and ready for a thorough
review.
- What do you do when you're simulating a device-in-action (DIA) and the rail
voltages are not the same as the fixed [* Reference] values from the device
under test (DUT) measurements?
- This BIRD clarifies this by stating that the EDA tool should use the same
model terminal as the reference terminal during DIA that was used as the
reference node during DUT measurements/simulation.
- Arpad: How do we know which node that is?
- Walter: If any one of the [* Reference] values is 0.0, then the corresponding
*_ref terminal was the reference terminal during DUT and should be
used as such during DIA.
- If the test fixture reference node at DUT is not connected to a Component
Pin that is one of the *_ref terminals of the I/O buffer, then none of the
five [* Reference] values would be 0.0.
- In that case, this BIRD enhances the IBIS spec to define the POWER or GND
signal_name that the EDA tool should use as the reference node for all I/O
buffer terminal measurements.
- Discussion: Bob noted that he was concerned about going back to this proposal
and abandoning the DUT_Ref_term BIRD. He felt we were giving up on some
progress that had been made on that BIRD including special handling for non-
zero reference terminals and threshold testing. Walter noted that the special
handling was no longer needed since the Pin Reference BIRD provides the actual
local reference itself. In addition, he noted that the DUT_Ref_term BIRD did
not handle the case in which all five [* Reference] values were non-zero.
- Radek: This is certainly moving in the right direction. We should clearly
state that a buffer model in general contains five terminals (*_ref),
then we have to say what happens when any [* Reference] values are
the same, which is an indication that the corresponding *_ref nodes
are collapsed to the essentially the same node. Then we have the
special cases with fewer terminals than the general case. We would
certainly like to have this Pin Reference BIRD in case the connection
to the reference node is different from any of the *_ref terminals.
This is particularly useful for a power aware simulation. This is
good, and we may also want to keep the DUT_Ref_term BIRD as well, and
we can discuss that later.
- Arpad: We have to be careful about saying the corresponding nodes are
"collapsed into one node" when the [* Reference] values are the same.
Even if the [* Reference] values are the same, one might have a quiet
Pin vs. another with a noisy Pin providing the connection to their
*_ref terminals at simulation time.
- Radek: Agreed, we have to reconcile this specifically with the Pin Mapping.
Here this BIRD is talking about the case where any [* Reference] values
are the same and the value is zero, in terms of choosing one to use
for the reference terminal. But we must have text to put this in
context with Pin Mapping, which could allow those connections to be
made separately. (Note: Walter added a line in the "Other Notes:"
section of the BIRD draft to remind us to address this issue).
- Walter: [Reviewing the three editorial changes upon which the BIRD relies,
which are defined in the "Definition of the Issue" Section.]
- 1. [Addition to Guideline #2 on page 9]
- Pin name and signal_name are defined as coming from the data book, so
we can't apply/enforce any special reserved-names rules with them.
- 2. [New Guideline #15 to be added on page 10]
- Definition of the way to interpret the meaning of the term "GND" and
any Earth Ground Symbols seen in the document.
- (Radek noted that he would like "unless otherwise noted" added to this
section, as certain voltages like those for the I/V tables are not
measured relative to the reference node. Walter added a note to the
draft to remind us to address this).
- 3. [New rule for the [Pin] section on page 21]
- If two Pins have the same signal_name, they must have the same model_name.
- Walter: [After reviewing the ECL example provided with the BIRD, in which
none of the [* Reference] values are 0.0]
- This handles the general case.
- It's a simple change for the specification and the parser.
- If this BIRD is passed, the editorial group's work becomes very simple.
- We would know how to make measurements when the test fixture ground is
provided by something other than one of the five *_ref terminals.
- Discussion: Mike brought up the issue of how to choose one when multiple
[* Reference] values are zero, and asked if we should state that any one of
them could be used. Arpad reiterated his earlier point that we can't assume
the corresponding *_ref terminals are shorted, and cited as an example Randy
providing IBIS models that defined VSS and VSSQ. Walter replied that no
one IBIS buffer in one of Randy's models would be connected to VSS and VSSQ,
it would be connected to one or the other. Radek noted that he had used the
term "collapsing" (into one node) in the context of not having a
[Pin Reference] or a [Pin Mapping] specified. In the absence of those two,
the values of the five [* Reference] values actually establish connectivity.
If [Pin Reference] or [Pin Mapping] were specified it could provide enough
information to override this apparent "collapsing" of the nodes into one
when necessary. Radek suggested that we carefully spell out exactly what is
done if neither [Pin Reference] nor [Pin Mapping] are provided, and then
spell out how any assumptions we make when we only have the [* Reference]
keywords are overridden or enhanced if [Pin Reference] and/or [Pin Mapping]
are provided. Bob noted that he had expected this BIRD to do what Radek was
describing, declare the reference node when none of the [* Reference] values
were 0.0 and you need to pull out a "0V" reference from somewhere else on
the component. He said he was fine with that, but felt we still needed to
keep the DUT_Ref_term BIRD as well, particularly for thresholding issues.
Radek agreed that we might want to keep both, though he noted that the
thresholding discussion was tricky since it also could involve [External
Reference]. Walter said he thought the only remaining issue related to
thresholding was the "scaling" issue that had been discussed, and that Bob
could handle that in an entirely separate BIRD once this [Pin Reference]
BIRD clarified the proper way to make the measurements. Radek noted that
he saw no real fundamental disagreement between Walter's and Bob's positions.
Bob said he would review this latest draft 5 since his concerns were based
on earlier drafts, and he said he would prepare a presentation on this topic
for the next meeting.
- Radek: Motion to adjourn.
- Mike L.: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 12 July 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
