Minutes from the 12 January 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>FORMATS12-JAN-2016Bob
RossTeraspeedReferences in IBIS draft1(zip
<http://ibis.org/macromodel_wip/archive/20160112/bobross/References_in_IBIS_draft1.zip>
)(pptx
<http://ibis.org/macromodel_wip/archive/20160112/bobross/References%20in%20IBIS%20draft1/references_draft1.pptx>
)
IBIS Macromodel Task Group
Meeting date: 12 January 2016
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Avago (LSI): 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
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
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:
- There will be no ATM meeting on January 19th (next week) because of DesignCon
and the associated IBIS summit.
- Arpad noted that the following changes he had made to the ATM agenda's Pending
BIRDs section:
- BIRD179 "New IBIS-AMI Reserved Parameter Special_Param_Names" was removed
from the list because it was Accepted by the Open Forum during the December
18, 2015 meeting.
- A TBD entry was added for the "C_comp modeling with IBIS-ISS" topic that had
been introduced by Randy Wolff and discussed in previous ATM meetings.
- Arpad noted that Bob Ross had prepared a presentation on Voltage References in
IBIS and asked to review it at today's meeting.
--------------------------
Call for patent disclosure:
- None.
-------------
Review of ARs:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Radek: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
New Redriver Flow BIRD:
- Discussion: Arpad asked Fangyi if he had any updates on this topic. Fangyi
said that he is working on a solution and preparing slides. He will
distribute them when they are ready.
Fixing [Pin Mapping]:
- Walter: [sharing the presentation he plans to deliver at the DesignCon IBIS
summit next Friday].
- Discussion: Walter's presentation highlighted a particular sentence in the
[Pin] section of the spec:
"The second column, signal_name, gives the data book name for the signal
on that pin."
Walter said this statement should have ramifications in terms of the way we
allow IBIS [Component]s to connect things via the [Pin] section and the bus
labels in [Pin Mapping]. The bus labels defined in the [Pin Mapping] section
are generally identical to the signal_names from the [Pin] section. The spec
does not require this, arbitrary bus label names can be created and used.
However, this sort of indirection in the bus label names can lead to non-
sensical connections that neither the spec nor the parser explicitly disallow.
His presentation includes nonsensical cases in which an arbitrary bus label
name is used to short [Pin]s with model names POWER and GND. He also pointed
out an example in which the [Pin] section used the same signal_name for one
POWER Pin and one GND Pin. He noted that it was self-evident that this should
be a spec violation, given the signal_names = data book names statement.
However neither the current spec nor the current parser explicitly prevented
such nonsensical connections. Walter proposed two new rules to formally
codify the intent of the spec:
1. All [Pin]s with the same signal_name must use the same [Model] name.
2. All POWER/GND [Pin]s connected to the same bus label must have the same
signal_name.
Walter stated that every IBIS [Component] he had ever seen with a [Pin
Mapping] section had used bus label names identical to the signal_names. He
felt that introducing these rules would not in practice break our rules about
backward compatibility. He felt that it was likely a bug in the initial spec
that these types of nonsense connections weren't already explicitly illegal.
Walter also introduced the concept of a "Signal_names_are_bus_labels" option
to explicitly state the case and also allow simplifications in the [Pin
Mapping] section, such as not needing to include the POWER and GND [Pin]s in
the [Pin Mapping] section. This might even be considered the default
assumption (no need for the new option). Bus label names could still be used
to further subdivide groups of [Pin]s that had the same signal_name (in this
case it would be necessary to introduce bus label names different from the
signal_name itself).
Bob expressed general support for this enhancement, though he thought there
might be a detail or two to be worked out with respect some of the
interconnect discussions. Arpad objected to a statement on the final summary
slide that these new rules were required to make [Pin Mapping] "useable."
He stated that just because the model maker could do silly things didn't make
[Pin Mapping] unusable, and used the analogy of mistakenly using a .connect
statement in SPICE to connect different voltage rails (Bob agreed). He said
that we usually wanted the parser to focus strictly on syntax, not enforcing
reasonable models. Radek pointed out that that we have the parser check
rules from the spec, and we could introduce new explicit rules.
Additional open questions left from the discussion:
1. Radek asked if Walter also intended to clarify that only POWER [Pin]
connected bus labels could be used in the pu_ref column, and only GND
[Pin] connected bus labels could be used in the pd_ref column. That
is, only a POWER [Pin] could be the pu_ref for an I/O Pin and only a
GND [Pin] could be the pd_ref. Walter said that this was another
decision that we could make, but that the example for bug 172 had
provided a case in which one I/O Pin used VSS as its pu_ref and VDD
as its pd_ref. It was an open question if we wanted to decide not to
allow that.
2. In reviewing ibischk BUG 172 with Curtis and Bob, Radek had noticed an
additional issue with the parser. The spec says that a POWER [Pin]'s
entry in the [Pin Mapping] section should have its bus label specified
in the pu_ref column. Similarly, a GND [Pin]'s entry should have its bus
label specified in the pd_ref column. However, the current parser only
issues a warning (not an error) if this rule is violated and a bus label
is specified in one of the other columns. Should we have the parser
report an error in this case? This may be part of the BUG 172 discussion.
Discussion of Voltage References in IBIS:
- Bob: [Sharing his presentation on the history of voltage references in IBIS.
Presentation is now available in the ATM work archive.
http://ibis.org/macromodel_wip/archive-date.html]
- Discussion: Bob reviewed his presentation. He stated that IBIS was full of
implicit references to "node 0" [referred to as 0.0V in his presentation]. The
presentation covered a long list of IBIS keywords, terminal names, etc. Bob
stated that for a variety of historical reasons and syntactical reasons (e.g.,
no separate reference node provided anywhere in the syntax) node 0 was an
implicit reference for all of them. Ultimately, Bob suggested that fixing
this would require an intensive page-by-page scrub of the spec to see exactly
what had been intended in each case and how it could be resolved. Walter
objected to Bob's interpretation. He said that the implicit references to
zero arose out of the discussions of test fixturing for the measurement of
I/V and v(t) curves. The test fixture assumes the pd_ref is tied to "0",
but at simulation time things would be calculated with respect to the floating
pd_ref node. Arpad also disagreed, and said that his recollection of
[Voltage Range], for example, was that it was the voltage between the pu_ref
and pd_ref terminals for the device, not between the pu_ref and absolute
ground. Radek mentioned one example, A_gnd, and said he thought it was
probably a mistake to have the expression "similar to SPICE ideal node '0'"
in its description in the spec. He said it was actually a local ground
reference that needed to be defined. He said it was important that all
these implicit references be clarified. Everyone agreed that Bob's
presentation provided good historical context for the discussion.
- Arpad: Thank you all for joining.
-------------
Next meeting: 26 January 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
