[ibis-macro] Re: [ibis-interconn] Re: What P370 say about S-Parameter referencing

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: "IBIS-Interconnect" <ibis-interconn@xxxxxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 1 May 2018 12:15:23 -0400 (EDT)

Arpad,

 

The problem is that we are incapable of "verbalizing rules to guide/help
the model maker in making better models, or preventing them from making
gross errors.". We cannot say one should not use Node 0 because many
people make perfectly good and useful models using Node 0. It certainly
does not matter if one is not doing power aware simulations, or if one is
doing GND referenced power aware simulations.

 

BIRD 189 simply is a method of advertising to the EDA tool what the
terminals of the package interconnect models are, and therefor how to hook
it up between the buffers and the pins.

 

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> 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: Tuesday, May 1, 2018 11:55 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: What P370 say about S-Parameter referencing

 

Walter,

 

I wasn't talking about limitations.  I was talking about verbalizing rules
to

guide/help the model maker in making better models, or preventing them

from making gross errors.

 

But now that you mentioned limitations, although it is not a show stopper

because it can be done though IBIS-ISS, we would have gained some

flexibility from using an N+2 syntax for S-parameters.  But the decision

has been made, I am not going to fuss about it.

 

Thanks,

 

Arpad

==========================================================

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, May 1, 2018 7:39 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-interconn] Re: What P370 say about S-Parameter referencing

 

Arpad,

 

The answer is simple, and the same one I have been giving all along: 

 

Can a model maker use BIRD 189 syntax to create package interconnect
models that meets any requirement? The answer is yes. 

 

Can a model maker use BIRD 189 syntax to wrap the interconnect models that
he is currently using or delivering to his customers to represent package
interconnect? The answer is yes.

 

Can a model maker use BIRD 189 syntax to create interconnect models that
do not represent the required functionality to represent the package
interconnect model interconnect correctly? The answer is yes. Is this
because of a limitation of the BIRD 189 syntax? The answer is no!!! This
is a limitation of the ability of a model maker to create proper package
interconnect models, not a limit of the BIRD 189 syntax.

 

I presume that there may be interconnect models that cannot be implemented
in HSPICE (and therefore IBIS-ISS). Can you document such a potential
problem?

 

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 Muranyi, Arpad
Sent: Monday, April 30, 2018 10:31 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-interconn] Re: What P370 say about S-Parameter referencing

 

Walter,

 

Thank you for this quote.  This is exactly what Vladimir and I were trying
to say all along

in recent discussions on this topic.  See, for example, slide 8 in

http://www.ibis.org/summits/feb18/dmitriev-zdorov.pdf

or the last slide in:

http://ibis.org/macromodel_wip/archive/20180227/arpadmuranyi/Referencing%2
0Problems/ReferencingProblems_2018_02_27.pdf

to mention a couple of slides.  I am glad to hear that the "Who's Who of
signal integrity

and s-parameter experts" have the same views on this topic.

 

Our problem is that we have a few "complications" related to this in
BIRD189 which

is what makes it hard for us to write clean and simple rules in for IBIS.

 

One is that our shorthand syntax for S-parameter model instantiation is
defined with

a single, common reference terminal (N+1) for all ports of the S-parameter
model.

Given the requirement that all ports which are connected together have to
use the

same reference (regardless of what that reference actually is), this
implies that all

N+1 terminal S-parameter models which are connected together will end up
having

to use the same reference connection.  This requirement can only be broken
when

an S-parameter block appears with more than a single reference terminal,
acting as

an "isolation transformer" between the "sides".  In our case, this can
happen if the

model maker uses of an IBIS-ISS subcircuit in which the S-parameter model
is

instantiated with independent reference terminals, or if the EDA tool does
similar

S-parameter instantiations between the various IBIS components on the
board

level.

 

We were struggling with defining rules in a few simple words for the
different

situations, i.e. when the content of the IBIS-ISS subcircuit allows for
multi-referenced

S-parameter blocks, while the shorthand S-parameter syntax is based on the
single

reference concept.  The rules will all of the sudden have a lot of IF-s
and BUT-s

which is hard to write down in a simple way.  Or, if we over simplify the
rules, for

example saying that all references should be connected to node 0, we would
be

making things too restrictive.

 

Add to this the situation with the BIRD158 buffer model schematic, which
has a

"hard coded" reference terminal to that infamous (now) global reference
node

(triangle symbol).  Since the S-parameter block in BIRD158 uses a common

reference (N+1), anything that is connected to that will also have to use
that

same global reference node.  (Not because of the question whether there is

any current flowing through that reference node, but because ports
connected

to each other must have the same reference).

 

So our rules would go something like this:

 

IF there is a BIRD158 buffer model then.

IF the on-die interconnect or package model(s) use the N+1 shorthand,
then.

IF the on-die interconnect or package model(s) use IBIS-ISS subcircuits,
but only

IF those subcircuits contain S-parameter instances with more than one
reference, then.

IF the IBIS-ISS subcircuit contains other types of T-line models or
discrete elements, then.

IF the model is intended to be used for power aware simulations, then.

 

and the list might go on for a while.

 

So our problem is not the question whether we connect the reference
terminals

of the S-parameter blocks to a global or a local reference node, it is not
whether

there is any current flowing through that reference connection, it is not
whether we

require the entire system to be referenced to a single reference node (the
3rd drawing

in BIRD158), etc.  Our problem is that we can't write a few simple and
parseable rules

for all of the possible situations which may arise with the various buffer
and interconnect

modeling options we support.  And, if I understand it correctly, the
latest version of

BIRD189.5 does not guide the model maker with any rules on this, allowing
the

inexperienced model maker to write models with gross errors.

 

I am not saying that we must have such rules in the spec, after all, one
can write all

kinds of ridiculously bad models in SPICE too, but I wonder if such rules
would be

useful to at least guard against the worst of such bad possibilities.

 

Thanks,

 

Arpad

====================================================================

 

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, April 27, 2018 11:36 AM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-interconn] What P370 say about S-Parameter referencing

 

All,

 

The following comes from the currently unapproved draft of:

P370T/D2
Draft Standard for Electrical Characterization of High-Frequency
Interconnects at Bandwidths up to 50 GHZ

 

I point out the following lines from the statement below:

1.      Current flowing in the signal terminal is equal to current flowing
out of the reference terminal at each port.
2.      "the local references can be different for different ports of a
multiport, but they have to coincide with the local reference terminals of
another multiport to be connected."

 

The key point is that if two s-parameters are connected, then each
s-parameter measurement (or extraction from a layout data base) must use
the same reference at each port that is connected. This is a fundamental
part of using s-parameter data. It could be on a "ground" net or a power
rail net, just needs to be the same. Since they are connected, and the
flow in and out of both of the s-parameters are the same, then there is no
net current flowing from the connected s-parameters. So for simulation
purposes, the actual "reference node" connected to the S element is
academic. I see no reason to challenge what the P370 committee is stating,
since the committee members are a Who's Who of signal integrity and
s-parameter experts.

 



 

Figure B.1  Multiport currents and voltages definition

Ports are numbered from 1 to N. Each port has two terminals. One terminal
is the signal and another terminal is local reference or local ground
terminal. Current flowing in the signal terminal is equal to current
flowing out of the reference terminal at each port. Connection of
multiports requires that the definition of the terminals on both sides of
the connection is the same. It means that the local references can be
different for different ports of a multiport, but they have to coincide
with the local reference terminals of another multiport to be connected.
Some groups of ports may share the reference terminals. The currents and
voltages at ports are either actual measurable values or effective
voltages and currents as in microwave theory.  In frequency domain, the
currents and voltages are complex variables and can be united into vectors
with N complex elements:

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

978.461-0449 x 133

Mobile 303.335-6156

 

JPEG image

Other related posts:

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