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

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 22 Mar 2018 21:08:13 +0000

Walter,

Regarding "The following statement is not true:" and your thought exercise, 
consider the drawing on
slide 15 of Sam's 2008 presentation:

[cid:image001.png@01D3C1F6.D7545460]

Do you think that after modifying this drawing the following way you would 
still get the
correct simulation results?

[cid:image002.png@01D3C1F7.446A33D0]

In other words, if you mix "Ground based" models with "non-Ground Based"  
models?
Note that the partial inductance in the ground path of the "non-Ground Based" 
model
in the middle will be shorted by the two Node 0 connections in the "Ground 
Based"
models around it...  This is what I meant by having to consistently model 
everything in
a simulation using the same method.  You are correct that there might be 
exception
cases when the "non-Ground Based" model is on the "end", but I think those 
might be
more of an exception that the norm...

Thanks,

Arpad
====================================================================

From: ibis-interconn-bounce@xxxxxxxxxxxxx 
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, March 22, 2018 8:45 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Putting to Bed A_gnd

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

PNG image

PNG image

Other related posts:

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