[ibis-macro] Re: [ibis-interconn] Re: Putting to Bed A_gnd

  • From: David Banas <capn.freako@xxxxxxxxx>
  • To: Walter Katz <wkatz@xxxxxxxxxx>
  • Date: Thu, 22 Mar 2018 10:49:04 -0700

Hi Walter,

Thanks for your thoughtful comments in reply.
They helped me better understand the disparity between our two perspectives.

Regarding your presentation, I read it when you first sent it out.
And, when I got to slide 15, I followed up by rereading my copy of Brian’s book
(well, I mean, not the whole thing, but the section that pertains).
It all makes sense to me.
However, you don’t actually define the term, “Ground Based,” formally on slide 
15.
Rather, you allude to what it might mean, by referencing Scott’s comment, re: 
“ground referenced” simulations.
Sorry to be so persnickety about this, but I really think a formal definition 
of the term, “Ground Based,” would help.
I offer:

A so called “ground based” simulation is one in which no component resides in 
between any two nodes considered to be voltage reference nodes.

In suggesting this definition, I’m looking at Brian’s Fig. 5.21 and am noting 
that I’m suggesting something more restrictive than what he outlines. For 
instance, he allows an inductor between two reference nodes to be “correct”, as 
long as the two reference nodes are different. (See his Fig. 5.21a.) And 
because of this extra strictness, I think it’s important that we all be on the 
same page, regarding the formal meaning of the term, “ground based.”

Thanks,
-db


On Mar 22, 2018, at 9:51 AM, Walter Katz <wkatz@xxxxxxxxxx> wrote:

David,
 
Please look at slide 15 of the presentation (enclosed) I sent out to this 
group on 3/13 to answer the question of what is meant by ground based 
simulation.
 
Other comments below:
 
Walter
 
 
 
Walter Katz
wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>
978.461-0449 x 133
Mobile 303.335-6156
 
From: ibis-macro-bounce@xxxxxxxxxxxxx 
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> <ibis-macro-bounce@xxxxxxxxxxxxx 
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On Behalf Of David Banas
Sent: Thursday, March 22, 2018 11:36 AM
To: Walter Katz <wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>>; 
arpad_muranyi@xxxxxxxxxx <mailto:arpad_muranyi@xxxxxxxxxx>
Cc: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx 
<mailto:ibis-interconn@xxxxxxxxxxxxx>>; ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: [ibis-interconn] Re: Putting to Bed A_gnd
 
Walter, Arpad, class, anyone, Bueller?,
 
1. Re: the term “Ground Base”:
    a. Has it been formally defined in this thread, and I just missed it?
    b. Does it simply mean that no component is ever placed in between two 
nodes that are considered to be reference nodes by something?
    c. Is it a term "commonly and intuitively" understood by the participants 
in this thread?
    (If so, would someone mind taking a crack at a formal definition?)
 
2. Re: this statement by Walter:
Of course the measurements at the buffers will need to be relative to the 
buffers local “ground” signal.
Doesn’t this immensely complicate simulation of such models?
And doesn’t it break many (i.e. - all the SPICE variants I’m familiar with) 
simulators, which assume that each node voltage is with reference to “0”?
At the very least, it seems to demand the introduction of MANY 
differential-to-single-ended converters be added to the model, to translate 
from the model’s internal “floating ground” world to the simulators “global 
ground” world.
 
WMK> No. All I/O voltage measurement at the I/O pad must be made relative to 
the pulldown reference or ground clamp reference at the buffer. All I/O 
voltage measurement at the Pin must be made relative to the  pulldown 
reference or ground clamp reference signal at a nearby pin of that signal 
name. (Note MECL, PECL, ECL may require a difference reference node – Bob can 
explain that to you). The EDA tool decides what rail voltages get supplied to 
the “B” element. HSPICE allows the “B” element to supply these voltage – in 
which case pulldown reference and ground clamp reference is Node 0. If not 
doing power aware simulations, then EDA tools short pulldown reference and 
ground clamp reference to Node 0. If doing Ground based power aware 
simulations, then EDA tools short pulldown reference and ground clamp 
reference to Node 0. In all of these cases, all I/O voltage measurements can 
be made relative to Node 0, since the local  
 
3. Re: this statement by Walter:
Brad has the other problem, he cannot convince the people generating SPICE 
models for the I/O buffers. If an I/O buffer has Node 0 internal to it, then 
any current flowing to Node 0 inside of the SPICE I/O buffer will not be 
accounted for. 
Doesn’t that only matter when the package model maker has split the package 
loop inductance into two or more partials, placing one of those partials in 
between the buffer-to-package “ground” connection and the package-to-board 
“ground” connection? And don’t we all understand (believe?) now that doing so 
is unnecessary?
The paper I referred to, a week or so ago, does a wonderful job of convincing 
the reader of this.
It would be great to have someone, whom remains unconvinced, post a 
counterargument to that paper’s thesis for us all to digest.
 
WMK> I will not contest your assertions. You say that sometimes it does not 
matter, and sometimes it does matter. I do not disagree with Brad that the 
conservative thing to do is not use Node 0 inside of SPICE I/O buffer models. 
IBIS does not support SPICE I/O buffer models. [Externa Model] does support 
Berkley SPICE (which has no w-lines or S-Parameters) and IBIS ISS (which is 
LTI, and really only supports what can be done in BIRD 158 with a convoluted 
syntax). 
 
4. Re: this statement by Walter:
If any customer of Cadence is worried about this, they can insist on getting 
Board models from their EDA tool and package models from all of their IC 
vendors that do not use Node 0, and they can do their power aware 
simulations based on this. Nothing in BIRD 189 prevents this.
But, maybe, Arpad’s point is that it should?
Maybe, this committee needs to be a little more careful about prompting 
technically misguided impulses through the chip-package-PCB co-design 
community?
Perhaps, we should be a bit more mindful of the demands we prompt from 
systems vendors on IC vendors, especially if we’re prompting demands that 
don’t make sense technically?
Perhaps, if we did this, we’d see better participation/representation by/of 
IC vendors in this committee?
 
WMK> If you go back to the papers I presented several years ago, the 
requirements of BIRD 189 is to define package models that are being created 
today and needed in the future. Specifically it was never a requirement of 
BIRD 189 to tell people how to create package models. Please remember that 
IBIS is a specification that defines format for IV tables, VT tables, 
measurement thresholds, legacy package models, Berkley SPICE, IBIS-ISS 
subckts, Verilog and  VHDL models for a Device Under Test (DUT). It describes 
the conditions used to generate this data. IBIS does not tell you how to use 
these models.
We have IC Vendors on the committee. I will point out that Michael at one 
point wanted to disallow Node 0 in BIRD 189 IBIS ISS subckts, but later came 
back and said that his package model makers rejected this – I hope I remember 
this correctly.
 
5. Re: this statement by Walter:
Let the market decide how they want their tool vendors to generate package 
models, board models and connector models.
Whenever I hear someone place such ultimate faith in the decision making 
prowess of the free market, I’m reminded of Henry Ford’s words:
 
“If I’d asked the market what it wanted, it’d have said, ‘faster horses’.”
 
Committees like this one have a responsibility to guide the market with a 
superior technical understanding of the issues at hand.
In particular, with something as subtle and easy to get wrong as the “ground 
bounce” myth, we would be acutely remiss in our duties to simply toss the 
choice to the market for making.
 
WMK> This committees does not have the responsibility to “guide the market 
with a superior technical understanding of the issues at hand.”, and in 
particular it does not have members with the skill set to do this. We have a 
responsibility to create a standard format for generating models for Devices 
Under Test, and give the flexibility to make these model to meet the 
simulation requirements of the industry. BIRD 189 does that. The way to 
handle things like the “ground bounce” myth is to state that all measurements 
should be made relative to a local reference node (which needs to be added to 
the standard) if they are to be compared with measurement thresholds, and to 
publish presentations and pointers to things that are relavent.
 
 
On Mar 22, 2018, at 6:45 AM, Walter Katz <wkatz@xxxxxxxxxx 
<mailto:wkatz@xxxxxxxxxx>> wrote:
 
Arpad,
 
The following statement is not true:
 
The problem is, that he would have to build the models that way for every 
model in a simulation, including all
the models for the buffers (Tx and Rx), all of their packages, and 
everything else that is between them on
the PCB, but the current BIRD189 allows people make their models using other 
conventions also. 
 
A little gedanken experiment here. Imagine a component with a package model 
written according “Brad’s rules” with no Node 0 or A_gnd, and everything is 
properly reference to the rail signals at all of the appropriate places in 
the component (buffer/pad/pin). Brad says he can do this.
 
Now image this component placed on a board that VSS, VSSQ and all other 
signals that are “ground” in the component are on planes made of 
superconducting material. The Board models in this case can all reference a 
single node and it can be Node 0.
 
The package model written according to Brad’s rules will work perfectly 
fine. Brad’s model will properly account for all currents in the component. 
The Board will add or subtract current from the “ground” pins to keep them 
at a constant potential, but the currents on the “ground” signals inside of 
the package will “float” the reference voltages at the buffers. Of course 
the measurements at the buffers will need to be relative to the buffers 
local “ground” signal. So the package model does not care if Node 0 is used 
externally to the package.
 
Brad has the other problem, he cannot convince the people generating SPICE 
models for the I/O buffers. If an I/O buffer has Node 0 internal to it, then 
any current flowing to Node 0 inside of the SPICE I/O buffer will not be 
accounted for. 
 
If any customer of Cadence is worried about this, they can insist on getting 
Board models from their EDA tool and package models from all of their IC 
vendors that do not use Node 0, and they can do their power aware 
simulations based on this. Nothing in BIRD 189 prevents this.
 
So why waste any more of our time on this. All we need to do is agree to the 
following:
IBIS 189 should state that A_gnd is the Simulator Reference Node (Node 0 in 
IBIS-ISS)
We add the following Note: 
Using A_gnd as Interconnect Model Terminals or Node 0 in IBIS-ISS subckts 
may not account for all currents going to “ground” pins, and therefore 
potentially introduce simulation results when doing power aware simulations 
that are not ground based.
 
Let the market decide how they want their tool vendors to generate package 
models, board models and connector models.
 
Walter
 
 
Walter Katz
wkatz@xxxxxxxxxx <mailto: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 Muranyi, Arpad
Sent: Wednesday, March 21, 2018 10:12 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx 
<mailto:ibis-interconn@xxxxxxxxxxxxx>>; ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: Putting to Bed A_gnd
 
Walter,
 
I don’t think the current BIRD189 would prevent Sam to build his models as 
described in his 2008 presentation.
The problem is, that he would have to build the models that way for every 
model in a simulation, including all
the models for the buffers (Tx and Rx), all of their packages, and 
everything else that is between them on
the PCB, but the current BIRD189 allows people make their models using other 
conventions also.  Models 
with different conventions will not work together properly, unless they are 
converted somehow to follow the
same convention.  If the IBIS specification claims that we are promoting 
model portability and interoperability,
this would need to be addressed somehow.
 
Regarding Sam’s Model Extraction Methodology, that was exactly my point.  He 
describes how to or how not to
make models, and I have not seen yet any IBIS files with data that seems to 
follow his technique.  My point was
that the IBIS files I have seen so far do not not follow the Ground Base 
extraction methodology (which is what I
see in Sam’s presentation), as opposed to your statement that almost all 
package models are universally Ground
Base.  I admit that just because I haven’t seen it yet, it doesn’t mean that 
they don’t exist, but I am not sure
that they are so universal at this time that we could count on practically 
no models made with other conventions
even if BIRD189 allows them to be written… 
 
Anyway, I am simply concerned about interoperability and portability, and I 
think we should write BIRD189 in
a way that increases the chance (or guarantees) that models and EDA tools 
will work together properly, and
without any requirement for pre-processing the model files before they can 
be simulated.
 
The interesting thing about the conversation on the question of whether 
A_gnd is a global or local reference
is that it doesn’t quite solve the problem of the question of the choice of 
modeling convention (Ground Base
or not).  Even though they are related in many ways, they have quite a few 
unrelated issues too, and making
a decision on how A_gnd is defined is not enough to solve the problem with 
the different modeling conventions.
 
Thanks,
 
Arpad
======================================================================================
 
From: ibis-interconn-bounce@xxxxxxxxxxxxx 
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx ;
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>] On Behalf Of Walter Katz
Sent: Wednesday, March 21, 2018 7:26 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx 
<mailto:ibis-interconn@xxxxxxxxxxxxx>>; ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: Putting to Bed A_gnd
 
Arpad,
 
Is there anything in the current BIRD 189 specification that prevents Sam 
Chitwood from building the models he thinks are required?
 
You say that “And I haven’t seen any IBIS package models yet, which had 
ideal shorts for the GND pins and “double” values on the POWER pins.”. But 
if you read  Sam’s [Model Data] Extraction Methodology  he picks one GND net 
and excludes if in the [Model Data] pin list, and makes the pulldown node 
the “ref” node. This is shorting GND pins and making them the “ref” node. 
This is “ground based” power aware simulation. This paper was written in 
2008 (presented by Brad Brim), so I do not know if their position has 
changed, or if they are saying they need to do “ground based” simulation 
because of other limitations in [Model Data].
 
Walter
 
 
 
Walter Katz
wkatz@xxxxxxxxxx <mailto: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 Muranyi, Arpad
Sent: Wednesday, March 21, 2018 7:25 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx 
<mailto:ibis-interconn@xxxxxxxxxxxxx>>; ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: Putting to Bed A_gnd
 
Walter,
 
Regarding “Almost universally, package interconnect, board interconnect and 
connector interconnect SPICE
models use Node 0, and almost universally power aware simulations are 
“ground base”.”:
 
If the first half of this statement is true, why don’t we just say in 
BIRD189 that the N+1th reference terminal
is connection to A_gnd, and give no other options?  That could eliminate a 
lot of the “problem cases” we
have discussed in this thread…
 
I tend to disagree with the second half.  If we can make power aware IBIS 
[Model]s, and if the IBIS [Pin]
and various package keywords allow for package RLC on POPWER and GND pins, 
we are talking about
non-Ground Base modeling.  And I haven’t seen any IBIS package models yet, 
which had ideal shorts for
the GND pins and “double” values on the POWER pins.   This “problem” in IBIS 
was actually pointed out
and heavily critiqued in several IBIS summit presentations by the then 
Sigrity folks a long time ago…
 
http://www.ibis.org/summits/mar08/chitwood.pdf ;
<http://www.ibis.org/summits/mar08/chitwood.pdf>
 
Other than that, I am not totally opposed at making A_gnd a global reference 
(like Node 0), but I would
prefer something less restrictive…  I still don’t see what the problem is 
with making it a [Component]
level local reference, and let the EDA tool decide whether to connect it to 
their global reference in
simulation or not…
 
Thanks,
 
Arpad
===================================================================================
 
 
 
 
 
 
From: ibis-interconn-bounce@xxxxxxxxxxxxx 
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx ;
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>] On Behalf Of Walter Katz
Sent: Wednesday, March 21, 2018 3:01 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx 
<mailto:ibis-interconn@xxxxxxxxxxxxx>>; ibis-macro@xxxxxxxxxxxxx 
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Putting to Bed A_gnd
 
All,
 
This discussion of A_gnd has gotten way out of control, unnecessary and a 
huge waste of time. 
 
A_gnd should be defined as a Global Simulator Reference Node (e.g. Node 0). 
If a simulator supports IBIS-ISS then it must support Node 0. 
BIRD 189 is based on IBIS-ISS.
 
It is very important to note that the model maker who creates BIRD 189 
models can choose to
Not use A_gnd in his Interconnect model terminals and not use Node 0 in any 
of his IBIS-ISS files. 
Use A_gnd in his Interconnect model terminals or use Node 0 in any of his 
IBIS-ISS files. 
The currents that go to the component “ground pins” (as defined in the 
Component Data Book)” may not account for the currents that go to Node 0.
 
Almost universally, package interconnect, board interconnect and connector 
interconnect SPICE models use Node 0, and almost universally power aware 
simulations are “ground base”. 
 
I would like to make the following motion:
IBIS 189 should state that A_gnd is the Simulator Reference Node (Node 0 in 
IBIS-ISS)
We add the following Note: 
Using A_gnd as Interconnect Model Terminals or Node 0 in IBIS-ISS subckts 
may not account for all currents going to “ground” pins, and therefore 
potentially introduce simulation results when doing power aware simulations 
that are not ground based.
 
Anyone can write a supporting document on why it is better to make models 
that do not use A_gnd or Node 0. This does not belong in the BIRD, but can 
be submitted as a supporting document to the BIRD.
 
Walter
 
 
Walter Katz
wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>
978.461-0449 x 133
Mobile 303.335-6156

 
<Ground Recommendations.pptx>

Other related posts: