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

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>, IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 1 May 2018 17:50:11 +0000

Walter,

I think we are in "violent agreement" on that one.  This is not about whether 
someone uses node 0
or not.  The fundamental requirement, as you summarized it from P370(tm)/D2 is:

"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."

I wish we could put something like that into BIRD189 (or the IBIS spec. 
somewhere), because the
way we have it now allows a model maker to write models which do not satisfy 
this fundamental
requirement.  But this might be considered as "educational material", and as 
such it may be
debatable whether it should be in the spec.

Thanks,

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

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

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
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: Tuesday, May 1, 2018 11:55 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

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
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: 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%20Problems/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:
P370(tm)/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.

[https://lh4.googleusercontent.com/ElUqNClc9FT7o1jGla7mphEBJd4g9WoUufRVtMmQEVvxxUF9N9cJrLCBw65P_J4-7R9dB72vBF_D-cJoD2GQgqgci7GC9pcDxss5y8fwX1Vxec7rVgGVjLvVKidxH_Z2FsvizjhmIZCBD_w8iw]

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
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
978.461-0449 x 133
Mobile 303.335-6156

JPEG image

Other related posts: