Minutes from the 15 December ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 15 December 2015
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:
- Arpad reminded everyone that meetings on December 22nd and 29th were
cancelled, as was the meeting on January 19th because DesignCon and
the associated IBIS summit occur that week.
- Mike L. asked if there would be an ATM task group report at the DesignCon IBIS
summit. Arpad stated that he would draft the report, and someone else could
present it if he were unable to attend the summit.
--------------------------
Call for patent disclosure:
- None.
-------------
Review of ARs:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Discussion of language corrections regarding "ground":
- Arpad: [Sharing Walter's proposed new paragraph on the screen]
- New paragraph:
"GND is used in many places in this document as the signal_name of Pins that
have Model Name GND. GND in many "buffer example schematics" use this name
GND as a signal name such as VCC, VDD, VSS. The string GND in this document
shall refer to either a Model Name in the Pin list or a signal name on one
or more pins that coincidently also have Model Name GND. GND shall never be
interpreted as the reference node in many SPICE simulators that is often
called Node 0. Since IBIS defines signal_name as a component Data Book Name,
we must assume that all Pins that have Model Name POWER or GND and have the
same signal_name are assumed to be connected together on the components
board or module. Each buffer can have one or two ground terminals (pdref
and/or gcref) that are local nodes of the of the power distribution circuit
of Pins that has Model Name GND. [Pin Mapping] is required to determine
which signal_name is the local ground nodes of each Buffer."
- Bob: My issue is that adding this definition under section 3 goes too far.
- It introduces new restrictions that don't exist in IBIS.
- It documents rules with respect to keywords, terminals, etc., that aren't
defined at that point, and makes forward references to things throughout a
240 page document.
- Listing what can be done with "GND" excludes some things that are done now.
- For example: While the original intent of IBIS was perhaps that "GND" was a
reserved model name, and you could do anything with signal name (we made the
suggestion they comply with data book names), it turns out that since
ibischk2 you can use "GND" or any of the five other reserved names as
[Pin Numbers] if you want. Perhaps this was unintentional, because it was
flagged as an error in ibischk1. But, I don't propose changing it. There
might be a good reason to call a specific pin GND because it's your ground
plane pin.
- Radek: So you are saying the pin name can be called GND?
- Bob: Yes, or NC or anything and it will pass the parser after ibischk2.
- Radek: That's inconsistent with the opening statement that they shouldn't be
used for other purposes.
- That can be rectified.
- Bob: That's why I didn't want to go too far down that path here.
- For example, it could also be used as a node name in multilingual.
- It would be a 50 page document to enumerate where it can and can't be used.
- Making an overly restrictive generalization here opens up trouble.
- Arpad: Would it help if we took Walter's paragraph and started by marking it
up sentence by sentence as to whether we agree or disagree?
- Then if we disagree we have to fix something.
- Michael M.: We want to agree on the objective of the paragraph.
- Is the object to permanently disassociate "GND" and node 0?
- Arpad: I think another motivation on Walter's part is to associate a
connectivity meaning with the signal name column.
- In other words, signal name is not just a meaningless column containing data
book names. There are connectivity assumptions based on the names.
- Radek: As far as I recall, we really don't have an association of "GND" with
node 0 in the spec, except for one particular statement we can modify.
- On the other hand, we have to clearly define what "GND" is.
- We need to have the GND node clarified 100%.
- Whether it is node "GND" or we call it the "reference node for the I/O port"
we have to have it properly defined.
- Bob: It's referred to as a model name, and you mention it could be used as a
local reference, and not necessarily a global reference such as would
exist as node 0 in SPICE.
- I think that's as far as we should go in defining it there.
- It may be used as a signal name and unless explicitly stated in other areas.
- Arpad: From an IC perspective:
- GND on an IC can only, at best, be the silicon substrate on the die.
- From a Buffer [Model]'s perspective GND at best could be the die substrate.
- But it doesn't always have to be, it could be -15V or something else.
- The main point is that we really don't have a node 0 type ground on the die.
- Bob: In many SPICEs, I think use of "GND" is interpreted as global ground.
- Arpad/Radek: That's correct.
- Radek: We need to clearly disassociate ourselves from those concepts.
- But we still need to have the local ground properly defined.
- The signal (input or output), it's a port concept and we need to have two
nodes clearly defined. Whether that's the substrate or whatever, is up to
the model maker but there must be a way to indicate what it is and to
connect to it, including for packages and interconnect models.
- Arpad: The IC comment was just the first half of my thought:
- From a buffer's perspective on the silicon we are pretty clear, we just have
to define what pad the substrate is connected to and how the pad goes out to
the pin.
- But when it comes to the package and transmission line type models I think
the problem gets more complex. In a w-element type environment we have the
"reference node", and that reference node is not supposed to be used to
model a ground plane or anything carrying non-ideal currents or voltages.
But even then the reference node has to be there for numerical purposes.
What do we do with that?
- Radek: It has to be clearly defined.
- We have to make the connections properly.
- Arpad: If you have a package model with w-elements that has signal and power
and ground traces, a w-element signal terminal will be used for the
ground traces as well. But the w-element that carries the ground still
has a reference node. Where does that go?
- Radek: It goes to whatever is the reference node. If that's local ground it
goes to local ground, but we have to know what it is.
- If you have two traces and you consider another substrate as the local
ground, then you have two transmission lines so the w-element has two traces
and six connection pins. Preferably the reference node is the same for both
ends because we don't have enough information for different reference nodes.
- Discussion: As fodder for a thought experiment, Arpad proposed an example with
a buffer containing only power, signal, and ground terminals. Therefore, it
has a die with 3 pads and a package with 3 pins. Arpad and Radek had
differing opinions on how this would be modeled. Arpad suggested that to get
from the board-side of the package to the die-side one would model a 3
conductor w-element, with one conductor each for power, signal and ground. He
said that 3 conductor w-element would still have a fourth reference node (or
possibly a fifth if a reference node were specified on each end), and that
this ideal reference node had nothing to do with the ground pin or ground
pad on the die. All 3 conductors would appear in the [Package Model]
matrices. Radek countered that if the ground pin provided the local ground
then it should be the reference node. He stated Arpad's example would be
modeled as two traces (power and signal) with ground serving as the local
reference. You would therefore have two ports on each end. Two traces and
the local ground or substrate would form two coupled transmission lines.
Only
the signal and power pins would appear in the [Package Model] matrices.
- Arpad [sharing the IBIS-ISS spec's W-element syntax description, and noting:
i1 i2 ... in ir o1 o2 ... on or]
- Discussion: Arpad referred to his example and suggested it would be modeled
with i1 i2 i3 and o1 o2 o3 as the input and output terminals of the 3
conductors (power, signal, ground) and that the ir and or were the ideal
reference terminals. Radek again countered with an s-element
type port concept and said that the ground conductor would serve as the local
reference ir and or, and that it would not itself appear in the [Package
Model] matrices. Bob pointed out that it was a "reference conductor" from
ir to or, so they couldn't be arbitrary reference nodes at different
voltages.
Arpad, however, noted that years ago he could not put two different DC sources
on the ir and or. But more recently, however, SPICE simulators allowed him to
do it. Radek said that in general it did not make much sense to have two
separate ir and or nodes, but that it is available, and it is also true that
some simulators allow per port references for s-parameters. It's generally
best for circuit simulation for ir and or to be the same node. Arpad worried
that losses through the ground trace would not be modeled if it's the
reference. Radek suggested a losses through the whole loop approach.
- Arpad: Isn't this ground reference question central to Walter's paragraph.
- Bob: I think Walter's GND statement is just with respect to buffer models.
- You need the interconnect spec for transmission lines.
- We've dealt with it there, where you bring out a reference line.
- Radek: All you have for the [Component] is the external [Pin]s.
- Arpad: We're relatively well defined with reference terminals on the die.
- What happens though, when you start putting W-elements in the package and
on the die?
- Radek: In the [Pin Mapping] we really need a local ground entry.
- We have pullup_ref, pulldown_ref, etc., even the rarely used ext_ref.
- We don't have a local ground specified. That would be the reference we are
talking about.
- Bob: That's what Walter is proposing, that we define pulldown_ref or gnd_clamp
ref as the local ground.
- Radek: If there's no conflict with other issues (like -15V).
- Arpad: That's why I'm not sure if that solution would work.
- Bob: Plus it's confusing, and C_comp to local ground would not resolve the
power-aware IBIS issues any better than C_comp to node 0. You need to
split up C_comp to distribute it to achieve that.
- And as Arpad said, sometimes any terminal can be the local ground.
- We've just seen an example on the reflector from a model maker. The input
swings from 0 to 3v, but the output swings from 9.9 to -6.6. The output
doesn't technically have a local ground terminal. All of the numbers in
the model are multiples of 3.3v. It's got an internal voltage multiplier
as
its reference. The reference terminals aren't even attached externally.
- Radek: Additionally, if you have a pseudo-differential buffer consisting of
two single ended buffers, how do you connect them?
- We simply need those nodes.
- Bob: In our early days the thinking was that global node 0 was as good as any.
- Radek: But the idea is that node was there from the beginning. It was just
assumed to be node zero. Now we want to call it "GND"ť and say it is
not necessarily node 0, but the node was there from the beginning.
- Discussion: Arpad asked if Randy would be willing to weigh in on the topic
since Micron develops high quality package models and IBIS models in general.
Randy mentioned that Curtis had recently been asking him similar reference
related questions about package models. Randy said that when simulating a
package substrate, their package modeling tools require the definition of
a ground reference for that simulation. In the 2.5 or 3D field solver one
might define that at infinity, but they usually define a reference plane by
defining a metal structure some distance below the package substrate. When
that package is solved, ground traces or planes within the package are defined
as though they are signals, not used as any sort of reference. When you
get the data out of the package simulator you have capacitance not only from a
particular signal to your ground trace, but also from that signal to your
external reference, which is more like node zero. Randy acknowledged that
when many tools output a SPICE sub circuit for the package model, they have
a ground node for the actual ground trace but end up using node 0 inside the
sub circuit to serve as the external reference. He said that how to deal with
that and avoid the implicit connection to node zero was on open question for
us. Radek expressed his concern that without giving the IBIS user more
information about the external reference node they had insufficient
information, and we were left with no choice but to use node 0. He suggested
that one of the actual ground traces should be defined as the reference.
Arpad asked whether the capacitances with respect to the external reference
node were significant in value or perhaps negligible. Randy said that it
depended upon the structure of the package and that, for example, a structure
with a single layer and no ground plane might show significant coupling
between
a signal and the external reference layer. Arpad said that with a far away
reference he would expect the terms to be very small, but it sounded like
Randy's simulations needed to use a closer reference. Randy said that they
tend to model their packages using a reference plane just below the solder
balls because that's the closest description of the way the package is
actually attached to a real circuit board. He said this placement tended to
give them simulations with the best correlation with measured data.
- Arpad: We've talked a lot, but I'm not sure if we are making progress.
- Discussion: Mike L. noted that we started with the goal of going over Walter's
paragraph, and then the question was raised about the whether we all agreed on
the objective of the paragraph. Mike said that he felt Walter's initial
statement on "GND" read more like a style guide, or upfront warning to the
user that they might encounter "GND"ť as a model name or a signal name. He
said that the spec actually used GND as a signal name in relatively few
places, and that we might be able to remove those uses from the spec by
simply renaming things where GND had been used as a signal name. He said this
would eliminate confusion in the spec and obviate the need for Walter's
statement. Arpad and Bob objected to this idea. Neither felt that it was
necessary to alter the way GND had been used in the spec. Bob felt that since
it was legal to have GND as a signal name, perhaps if a data book name really
was GND, we should not attempt to remove such usage from the spec. Arpad felt
that we could simply clarify the meaning in each instance where GND was used
in the spec. Radek pointed out that the interconnect proposal went in that
direction and designated whether something was a pin name, signal name, etc.
- Mike L: [sharing IBIS 6.1, Section 6.1, page 33, paragraph 2]
- Discussion: Mike L. pointed out that this paragraph, which describes how the
capacitors related to C_comp_xxx values are connected, uses GND in the context
of a ground node. He felt this hadn't been properly defined. Bob agreed and
said that it should be "local ground reference" in a rewrite. Michael M. was
even more critical of the last sentence. He said we already overloaded the
four [Pullup Reference], [Pulldown Reference], [POWER Clam Reference], [GND
Clamp Reference] keywords in the sense that they could be values or reference
nodes, and pointed out that this paragraph strongly implied that [Voltage
Range] itself was some sort of power rail instead of just a value representing
the potential difference between two particular nodes. Everyone agreed that
this paragraph will need to be rewritten.
- Arpad: It seems that Walter's proposal was an attempt to define a general rule
at the outset that could allow us to resolve many issues with one
statement.
- I'm beginning to wonder if it is going to work that way.
- Perhaps we would be better off to start reading the document sentence by
sentence and hashing out the details for each necessary change. Then, as we
are doing that, if we run into something that could be generalized up front
we can add an upfront statement.
- Right now it seems that we've spent two meetings trying to tackle the
generalized concept and still have confusion and or disagreement.
- Mike L.: I was thinking the same thing.
- Arpad: With that let's close the meeting today.
- Thank you all for the good work in 2015. Happy Holidays and Happy New Year.
-------------
Next meeting: 05 January 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
