Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
978.461-0449 x 133
Mobile 303.335-6156
From: Walter Katz <wkatz@xxxxxxxxxx>
Sent: Wednesday, April 11, 2018 11:31 AM
To: Mike LaBonte <mlabonte@xxxxxxxxxx>
Cc: IBIS-Interconnect (ibis-interconn@xxxxxxxxxxxxx)
<ibis-interconn@xxxxxxxxxxxxx>
Subject: RE: [ibis-interconn] Re: BIRD 189 [Interconnect Model Set]
[Description] and [Manufacturer]
All,
I think the following IBIScheck informational message would be useful:
The following interconnect models use Node 0 (aka GND, !GND, GROUND and
GND!) in their IBIS-ISS subckts (and A_gnd on terminals). Using Node 0 in
IBIS-ISS subckts may not account for all currents going to "ground" pins,
and therefore potentially cause incorrect simulation results when doing
power aware simulations where ground and power loops are fully modeled.
<Interconnect model name> <Interconnect model name> <Interconnect model
name>
<Interconnect model name> <Interconnect model name> <Interconnect model
name>
We can discuss in tomorrows meeting the following I propose adding to
BIRD 189.
The historical usage of "Ground" is implemented as Node 0 (GND, !GND,
GROUND and GND!) in IBIS-ISS and A_gnd in IBIS and this BIRD):
* All voltage measurements were made relative to the global
simulator reference Node 0.
The modern usage of "Ground" is "Ground is for potatoes and carrots).
Some power aware simulations need to account correctly for return path
currents. Also the reference node for any voltage measurement should be
close to the measurement point. (Note that in order to compare
measurement/simulation to Data Book Thresholds). "Close" is generally
excepted as 1/10 of a UI wavelength. Twenty years ago "Close" was measured
in feet, today "Close" is ~20 mils. Many existing tools historically and
continue to generate package, connector and board level interconnect
models using Node 0 in w-line, t-line, s-parameter, capacitor and resistor
elements. These are valid models if the power rail interconnect is
adjusted for this:
. Circuit theory says that we can go from a partial element system
where ground and power loops are fully modeled to a ground referenced
system where node 0 ground is applied to every element in the path. But,
ground bounce inductance and resistance is then lumped into power circuit
and signal path circuits, and the discrimination between the these is
lost. From a differential node voltage perspective at the receiver, the
result is the same. The voltage between the signal and ground will remain
the same. If there is a difference, then somewhere in the circuit, the
ground partial inductance has not been reduced into the loop inductance
for the signal path and power paths.
. This is a pretty standard transformation from partial
inductance/resistance matrices to loop inductance/resistance matrices, and
is covered quite extensively in Brian Young's book, which is still the
best on the subject.
.
http://www.amazon.com/Digital-Signal-Integrity-Simulation-Interconnects/dp
/0130289043
BIRD 189 also supports package models "where ground and power loops are
fully modeled". This requires that Interconnect Models to not contain Node
0 (unless there is no net current flowing to Node 0). If some of the
return path currents flow to Node 0, then this would take away currents
from ground paths and thereby change the voltage at the close reference
node. Note that even if all of the package models fully support models
ground and power loops, the other models in the channel (e.g. board,
connector, SPICE buffer models, and package models on other components in
the channel) should fully support models ground and power loops. This is
only important for Power Aware simulation. For non-power aware
simulations, the EDA tool can supply DC voltage sources to all "Power"
rails, and a 0.0 voltage source (relative to Node 0) to all "Ground"
rails.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
978.461-0449 x 133
Mobile 303.335-6156
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
<ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx> > On Behalf Of Bradley Brim
Sent: Tuesday, April 10, 2018 4:40 PM
To: Mike LaBonte <mlabonte@xxxxxxxxxx <mailto:mlabonte@xxxxxxxxxx> >
Cc: IBIS-Interconnect (ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> ) <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >
Subject: [ibis-interconn] Re: BIRD 189 [Interconnect Model Set]
[Description] and [Manufacturer]
Hi Mike,
If this condition is worth a warning, then it is worth end users relying
on it and therefore worth implementing in other than an optional keyword
in an arbitrary string format.
Any text in the spec saying model makers could/should include arbitrarily
formatted text in the [Description] string concerning explicit or implicit
application of global node 0 (or its equivalent A_gnd) is a redundant
statement (because by definition they could address this or any other
condition with such string) and serves absolutely no reliable purpose for
the end user. One could argue such ambiguity does not belong in a formal
specification, even if only a comment.
I am in favor of such warning but believe it must be in a clearly
specified location/format and must be reliable and include all explicit
and implicit applications of the global node 0 (or its surrogates). If it
is part of the model, then there may need to be a parser and/or runtime
validation of the condition?
Best regards,
-Brad
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
<ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx> > On Behalf Of Mike LaBonte
Sent: Tuesday, April 10, 2018 1:19 PM
To: ibis-interconn@xxxxxxxxxxxxx <mailto:ibis-interconn@xxxxxxxxxxxxx>
Subject: [ibis-interconn] BIRD 189 [Interconnect Model Set] [Description]
and [Manufacturer]
EXTERNAL MAIL
After the discussion in IBIS ATM about whether to warn tools/users when a
BIRD 189 interconnect model makes use of node 0, I looked into how we
would do that, if we wanted to. One possibility would be yet another new
keyword or subparameter. But if it's OK to have something that is not
machine parseable, a simple approach would be simply to suggest that
[Interconnect Model Set] [Description] contain a note about the use of
global node 0. We could even include an example to show that.
But I noticed that [Description] is limited to one line, so such a note
might need to be short. For example (addition highlighted):
Keyword: [Manufacturer]
Required: No
Description: Specifies the name of the [Interconnect Model Set]
manufacturer.
Usage Rules: The length of the manufacturer's name shall not exceed 40
characters (blank characters are allowed, e.g., Oklahoma Instruments).
Example:
[Manufacturer] NoName Corp.
Keyword: [Description]
Required: No
Description: Provides a concise yet easily human-readable description
of what kind of interconnect the [Interconnect Model Set] represents.
Usage Rules: The description shall fit on a single line, and may contain
spaces.
Example:
[Description] 220-Pin Quad Ceramic Flat Pack (uses node 0)
On another note, are the usage rules for [Manufacturer] sufficient to
exclude multiple lines? I would say yes, as long as "blank characters"
means spaces and not line ending characters. For that matter, why do we
say "blank characters" for [Manufacturer] and "spaces" for [Description]?
Mike