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

  • From: David Banas <capn.freako@xxxxxxxxx>
  • To: Walter Katz <wkatz@xxxxxxxxxx>, arpad_muranyi@xxxxxxxxxx
  • Date: Thu, 22 Mar 2018 08:36:17 -0700

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.

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.

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?

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.

On Mar 22, 2018, at 6:45 AM, Walter Katz <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 
<ibis-interconn-bounce@xxxxxxxxxxxxx> On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 21, 2018 10:12 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>; 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

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 03-2018