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

  • From: Scott McMorrow <Scott@xxxxxxxxxxxxx>
  • To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>, "capn.freako@xxxxxxxxx" <capn.freako@xxxxxxxxx>, "arpad_muranyi@xxxxxxxxxx" <arpad_muranyi@xxxxxxxxxx>
  • Date: Thu, 22 Mar 2018 17:16:24 +0000

You had me at “Scott McMorrow says:”

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Walter Katz
Sent: Thursday, March 22, 2018 12:52 PM
To: capn.freako@xxxxxxxxx; arpad_muranyi@xxxxxxxxxx
Cc: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: [ibis-interconn] Re: Putting to Bed A_gnd

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:

  1.  IBIS 189 should state that A_gnd is the Simulator Reference Node (Node 0 
in IBIS-ISS)
  2.  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] 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

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] 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:

  1.  IBIS 189 should state that A_gnd is the Simulator Reference Node (Node 0 
in IBIS-ISS)
  2.  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

This email and any appended documents are only for the intended person/entity 
and may contain information of Samtec, Inc., that is PRIVILEGED, PROPRIETARY, 
CONFIDENTIAL, AND/OR PROTECTED BY LAW. If you are not the intended recipient 
you are hereby notified that any dissemination, disclosure, use or copying of 
this email or its contents is prohibited. If you received this message in 
error, please notify Samtec immediately and delete the email, attachments and 
all copies. The intended recipient should not disclose the content to third 
parties or reproduce the content without Samtec’s written consent.

Other related posts: