[ibis-macro] Re: [ibis-editorial] Re: [ibis-interconn] What IEEE says about referencing

  • From: Scott McMorrow <scott@xxxxxxxxxxxxx>
  • To: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • Date: Tue, 19 Jul 2016 14:45:58 -0400

From a black-box s-parameter type of modeling approach, those ground nodes
are functionally identical.  All local ground behavior has been "rolled"
into measurements of the box and is incorporated into the network
parameters..  A model created in such a way may now be used in a node-0
referenced simulation.

If you want to include ground behavior separately, then twice the number of
ports would need to be added, and another point of measurement would need
to be used for ground. This is pretty much impossible in measurement, but
possible in EM modeling.

There is absolutely nothing wrong with this drawing.  It is exactly how a
VNA works.


Scott McMorrow
Technical Director SI/PI
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com





On Tue, Jul 19, 2016 at 2:40 PM, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
wrote:

Walter,



The issue is not whether that ground symbol means node 0 or not,

the issue is that using that symbol on multiple nodes implies

that all those nodes are shorted together.  I don’t think that

the IEEE people intended that short to be there…



Thanks,



Arpad

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



*From:* ibis-editorial-bounce@xxxxxxxxxxxxx [mailto:
ibis-editorial-bounce@xxxxxxxxxxxxx] *On Behalf Of *Walter Katz
*Sent:* Tuesday, July 19, 2016 12:46 PM
*To:* Bradley Brim <bradb@xxxxxxxxxxx>; IBIS-Interconnect <
ibis-interconn@xxxxxxxxxxxxx>; IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>;
IBIS-Editorial <ibis-editorial@xxxxxxxxxxxxx>
*Subject:* [ibis-editorial] Re: [ibis-interconn] What IEEE says about
referencing



Brad,



Thank you for your response. Fundamentally, the design engineer at the PCB
level must know for each signal path routed to an I/O pin which GND plane
should be above and/or below the path to insure a proper return path for
signals to the I/O pin.



I suspect, that for special circumstances, there will be one obvious
“ground” plane to use as the reference for all signal paths routed from
each package.



I do not think the figure is in error. The “ground” symbol represents “another
terminal is local reference or local ground terminal.” This “ground”
symbol is not meant to imply “Earth Ground” or “Node 0”.



Walter



*From:* Bradley Brim [mailto:bradb@xxxxxxxxxxx ;<bradb@xxxxxxxxxxx>]
*Sent:* Tuesday, July 19, 2016 1:30 PM
*To:* wkatz@xxxxxxxxxx; 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>;
IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>; 'IBIS-Editorial' <
ibis-editorial@xxxxxxxxxxxxx>
*Subject:* RE: [ibis-interconn] What IEEE says about referencing



Hi Walter,



The figure is in error. The “ground” symbol should not be present on the
reference terminals. This is an important point, especially if this figure
is for a standards document in the context of a precise discussion.



*Summary*:

What high-level point are your building-up to? That trying to enforce or
even to check port definition consistency is beyond the scope present
effort by the IBIS interconnect team? That we document the situation and
encourage model generators to document their port definitions? Does any of
this change your desire an EDA tool be able to apply either common or
individual reference terminals – alternately stated, either (N+1) or 2N
netlisting?



*Detail*:

The first of the two sentences you highlighted is definitional and your
discussion is centered around the second sentence. It says that when you
connect two S-parameter ports together, each from a different S-parameter
element, *the port terminals must be defined exactly the same for that
interconnected port of each of the two S-parameter elements*. For
example, if your PCB defines a port with ball pin/pad DQ1 as the signal
terminal and one adjacent VSS ball pin/pad as the reference terminal, then
the corresponding package S-parameter port terminals must be defined with
pin DQ1 as the signal terminal and the same single VSS pin as the reference
terminal. Would using a different single VSS pin as the package reference
terminal be wrong?  Yes. Would using all VSS pins collectively as the
package reference terminal be wrong?  Yes. How wrong?  “It depends.”



You are correct. IBIS cannot enforce this consistency of port definition
across S-parameter to S-parameter connection boundary. At least not without
much more information than now in an S-parameter file.



No EDA code can check this unless it has access to the model
generation/extraction design databases for each of the two S-parameters.
Alternately, each port terminal could be documented in some *broadly
understood* (avoiding use of the word *standard*) format. For
chip/package/board systems a list of physical connections might be applied
for the ball/pad/buff names and locations for each port terminal. This
implicitly requires definition of the underlying ball/pad/buff entities as
well. This can become a significant amount of information. A few EDA
companies have implemented the latter of these sets of info: e.g.
Ansys/Apache CPP and Cadence/Sigrity MCP and more recently Si2 CPIP.
However, the former header info for port terminals has not been fully
implemented by anyone that I know of. Some model generators include a
subset of such info, such as net names and pin names of port signal
terminals but rarely, if ever, document port reference terminals. Even if
the above header info were included, it may be incomplete to allow rigorous
checking for consistency. For example, in hybrid solvers (combination of EM
and circuit theories) one may apply all VSS pins of a package as a [common]
reference terminal of all port signal terminals. No additional geometry
need be added to the design to serve as a physical quasi short circuit
among these VSS pins. However, in a 3DEM solver or in a measurement fixture
there must be a physical connection added to the design to implement such a
“net-level” port referencing scheme. This is typically an additional
dielectric layer, vias through it and a sheet of metal that spans the
lateral dimensions of all VSS pads. Though the differences may be small
between the original and the augmented designs, it represents an
inconsistency in port definition between the two extractions. Even for the
single-pin signal and single-pin reference case, how is the port defined?
Is it a coax-like port with a frill in its entire antipad or is it a small
gap port localized to only one portion of the antipad? The two are slightly
different and would require even more detail than mentioned above.



I agree if you note that the previous paragraph is painful detail given
many of the interconnect models you propose will be at best informed
guesses with less than even first-order accuracy. However, some
applications will require this type of consistency to produce accurate
simulations.



Best regards,

-Brad



*From:* ibis-interconn-bounce@xxxxxxxxxxxxx [
mailto:ibis-interconn-bounce@xxxxxxxxxxxxx
<ibis-interconn-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Walter Katz
*Sent:* Tuesday, July 19, 2016 7:07 AM
*To:* 'IBIS-Interconnect'; IBIS-ATM; 'IBIS-Editorial'
*Subject:* [ibis-interconn] What IEEE says about referencing



All,



What S Parameter experts say about Port Referencing. The following is from
a proposed section of the IEEE P370 working group on measurement quality of
S parameters. Note the sentence highlighted in red. To me, this says that
the “reference” or more importantly the return flow terminals of I/O
terminals of package interconnect at the pin interface should connect to
the corresponding I/O terminals and return flow terminals of the PCB
interconnect.



So if a wline is referenced to VSS inside of the package, then the wlines
it connects to on the PCB should also be referenced to VSS on the board.



This is obviously a rule that IBIS cannot inforce on package and die
interconnect models at the Pin, Die Pad or Buffer interface, and we must
rely on the model maker, and the PCB designer to get that right.



Walter



*7.3 Definitions*

*7.3.1 Network Parameters in General *

This chapter briefly describes the theory of multiports in general and
scattering parameters (S-parameters) descriptors of multiports in
particular.

Multiport is a natural and scalable black-box description of linear
time-invariant system.  It reduces a system description to a simple
input-output relationship irrespective of possible complicated internal
structure. It is suitable for systems smaller that, comparable with or
larger than wavelength (literally DC to daylight and beyond). Any
interconnect or wave-guiding structure can be described as a multiport with
possible inclusion of radiation. In general, multiport theory facilitates
description of a complex interconnect system of any type – PCB and
packaging traces, fiber optics, waveguides and so on.

A multiport or N-port with equivalent currents and voltages is shown in
Fig. 7.3.1.1 according to the classic circuit theory definition [7.3.1.1] –
[7.3.1.3].

[image: cid:image001.jpg@01D1E1A2.983A3C80]

*Fig. 7.3.1.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 Katz

wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 303.335-6156

JPEG image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 07-2016