[SI-LIST] Re: s parameters and transient simulation

  • From: Ege Engin <engin@xxxxxxxxxx>
  • To: "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>,steven.corey@xxxxxxxxxxxxxx
  • Date: Tue, 23 Dec 2003 12:08:49 +0100

Hi Steve,

Thanks for the clarifications. I agree with you that such an
interconnect can also be defined as a 2n-1 port. Other possibilities are
to define it as an n-port as I did, or as a 2n-2 port by defining a
reference node on each side (note that I'm neglecting the capacitances
in this example; there are only inductors and resistors in series). In
all cases we can define the port voltages and currents, therefore they
are valid definitions. I agree with you that a general n-port does not
define voltages between nodes belonging to different ports (non-port
voltages). But I think it doesn't mean that the non-port voltages
"should" be undefined in a network including an n-port. The non-port
voltages are only undefined for some cases (e.g., networks including
spatially distributed systems). The complementary network (i.e., the
rest of the network) can define non-port voltages, as long as the port
definitions of the n-port are not violated. The common ground node
approach for general n-ports does not allow such complementary networks.
I don't think that this is a major problem though, since workarounds
exist.

Ege

Steve Corey schrieb:
> 
> Hi Ege -- We may be getting hung up on nomenclature here.  What you are
> calling an n-port in which the voltages between the reference nodes are
> defined, is really a 2n-1 port in network theory.  If the voltages of
> two nodes are defined with respect to each other, they can't both be
> reference nodes.  Such a system has 2n-1 unknowns and 2n-1 equations are
> required to describe it, which is what makes it a 2n-1 port.  You're
> right -- arbitrarily setting nodal voltages to zero when they are
> independent variables will affect the network's behavior.
> 
> You touched on this in describing an augmented system with 2n ports.
> The 2n port results if you take none of the 2n nodes to be reference
> nodes, and instead reference all of them against a yet-to-be-defined
> reference node, for a total of 2n+1 nodes. This is what SPICE does when
> you add elements (including subcircuits) to it -- it implicitly
> references all of them against its global ground node.
> 
>    -- Steve
> 
> Ege Engin wrote:
> > Hello Steve,
> > Common ground nodes are certainly not a bad recipe, if the multiport
> > network represents a spatially distributed circuit such that no unique
> > voltages between local reference nodes can be defined. I think this is
> > the most common case.
> >
> > I can think of another case, where the common node approach fails. This
> > issue was discussed some time ago in this list; quoted below was my post
> > to the list:
> >
> > "As an exception, in some cases a network matrix (like the S parameter
> > matrix or the impedance matrix Z) can be used to characterize a system
> > whose reference nodes are close to each other, such that the voltage
> > drops between the reference nodes are defined as well. In this case, the
> > connections between the reference nodes cannot be done arbitrarily. A
> > well-known example is an n-port Z matrix representing the partial
> > inductances and resistances of an n-conductor interconnect. To implement
> > this n-port Z matrix in a circuit simulator, n reference nodes have to
> > be given explicitly (if all the reference nodes were connected to a
> > common node, then one side of the interconnect would be
> > short-circuited). If such a model does not exist in the circuit
> > simulator, a possible workaround would be to create an equivalent
> > 2n-port chain matrix with some math, and use this chain matrix in a
> > model with a common reference node."
> >
> > Ege
> >
> > Steve Corey schrieb:
> >
> >>Geoff -- your statements are true about network theory.  However, I
> >>don't see where common ground nodes become a "bad recipe".
> >>
> >>When you take a measurement, you connect a reference conductor and a
> >>signal conductor from your measurement system to the device.  By
> >>connecting the reference conductor to a specific point, you're stating
> >>that you don't care what the voltage is at that point -- you're only
> >>interested in the difference between the reference conductor and the
> >>signal conductor.  If you're taking two-port measurements, you can't
> >>truly know how the voltages at the two signal nodes are varying with
> >>respect to one another, since you don't know how the voltages at the two
> >>ground reference nodes are varying with respect to each other.
> >>
> >>When you connect a receiver, be it digital or analog, to a port, you are
> >>roughly making the same statement.  You don't care what any of the
> >>voltages is with respect to some global ground, or some faraway port,
> >>you care about the difference between the receiver circuit's nodes and
> >>the local reference.   All these voltages are local -- theoretically,
> >>the power rail, vin+, and vin- at the receiver could all be measured
> >>against a single local "ground", and those are the same voltage
> >>differences the device will see.
> >>
> >>When you drop a multiport network into SPICE, you have to be aware that
> >>you're making the same assumptions.  Your simulation needs to be set up
> >>-- the same way your circuit design is -- so that the behavior doesn't
> >>depend on the difference between reference voltages of distant ports.
> >>This is the same partitioning into "groups" that is outlined in the MTT
> >>paper you referenced.  The paper does little more than to cast the logic
> >>outlined above into modified nodal analysis (MNA) matrix notation which
> >>casts all local references to zero volts by zeroing out their
> >>rows/columns in the MNA matrix.
> >>
> >>The bottom line is, if you can't know the voltage between two faraway
> >>points, you need to make sure that you don't care what it is -- by good
> >>design, good measurement setup, good simulation setup.  It should be
> >>reassuring that they all have to comply with the same set of limitations.
> >>
> >>   -- Steve
> >>
> >>-------------------------------------------
> >>Steven D. Corey, Ph.D.
> >>Time Domain Analysis Systems, Inc.
> >>"The Interconnect Analysis Company."
> >>http://www.tdasystems.com
> >>
> >>email: steven.corey@xxxxxxxxxxxxxx
> >>phone: (503) 246-2272
> >>fax:   (503) 246-2282
> >>-------------------------------------------
> >>
> >>Geoff Stokes wrote:
> >>
> >>>Hi Ray
> >>>
> >>>With reference to your posting earlier this year regarding n-ports etc.,
> >>>here is a thought on simulation of interconnects at high frequencies where
> >>>the concept of common voltage reference nodes seems to become a bad recipe,
> >>>thinking particularly of RF modelling of IC packages.
> >>>
> >>>As Khalil and Steer (paper cited below) have pointed out, the voltage
> >>>between two points is undefined in general.  This is an aspect of field
> >>>theory which becomes relevant when the frequency is high enough that the
> >>>phase delay between two points in a structure is a significant proportion 
> >>>of
> >>>the wavelength.  The significant proportion of course depends upon the
> >>>application, so we can't define a specific threshold frequency even for a
> >>>specific mechanical dimension.  In analog or mixed-mode circuit designs,
> >>>relatively small values of couplings or impedance may be significant, but
> >>>such values might be ignored in a purely digital circuit.  In addition, for
> >>>a correct DC simulation of the operating point and power supply currents,
> >>>together with broad band accuracy, the effect of internal inductance and
> >>>frequency dependent resistance
> >>>(both arising from skin effect and providing several percent effects) will
> >>>need to be included.
> >>>
> >>>In an earlier posting, Ege Engin wrote this helpful comment:
> >>>
> >>>"If an S parameter matrix is implemented in a circuit simulator, it
> >>>actually divides the rest of the circuit (all the other linear and
> >>>non-linear elements) into groups, that are only coupled to each other by
> >>>means of this S parameter matrix (due to the fact that an S parameter
> >>>matrix represents a distributed circuit). Since the voltage drops
> >>>between the local reference nodes in various groups are undefined, they
> >>>can be connected to each other in an arbitrary manner."
> >>>
> >>>I would just add that in practice, from the s-parameters obtained by
> >>>electromagnetic simulation or measurement, we have to formulate a 
> >>>polynomial
> >>>or lumped-element solution to feed into the nodal transient circuit
> >>>simulator (Spice or Spectre).  Ege Engin's final sentence would then apply
> >>>to the interconnection of the extracted n-port model with the chip
> >>>schematic.
> >>>In Khalil and Steer, "Circuit Theory for Spatially Distributed Microwave
> >>>Circuits" (IEEE Transactions on Microwave Theory and Techniques, Vol. 46 
> >>>No.
> >>>10, October 1998), we find:
> >>>
> >>>"The essence of the problem is that a global reference node cannot
> >>>reasonably be defined for two spatially separated nodes when the
> >>>electromagnetic field is transient or alternating.  In this situation, the
> >>>electric field is nonconservative and the voltage between any two points is
> >>>dependent on the path of integration and, hence, voltage is undefined.  
> >>>This
> >>>includes the situation of two separated points on an ideal conductor."
> >>>
> >>>So we see that each port requires its own separate local return pin in 
> >>>order
> >>>to describe the distributed structure with sufficient accuracy over the
> >>>required frequency range.  Two or more ports can only use a common ground 
> >>>if
> >>>they are physically close enough to one another (for the specific case).
> >>>
> >>>Finally, we make the arbitrary (?) decision to join the local ground(s) to
> >>>the common ground and hope it's OK.  From the network theory it seems OK,
> >>>but is a little hard to swallow.
> >>>
> >>>Any comments?
> >>>
> >>>Best wishes,
> >>>
> >>>Geoff
> >>>
> >>>______________________________________________
> >>>
> >>>Geoff Stokes
> >>>Applications Engineer, Signal Management Group
> >>>
> >>>Zetex plc
> >>>Lansdowne Road, Chadderton, Oldham, OL9 9TY,  UK
> >>>Tel direct:  +44-161-622-4857   Switchboard: +44-161-622-4444
> >>>Fax:  +44-161-622-4469
> >>>http://www.zetex.com <http://www.zetex.com/>
> >>>e-mail:  gstokes@xxxxxxxxx
> >>>
> >>>
> >>>
> >>>
> >>>_________________________________________________________
> >>>
> >>>Zetex Semiconductors - Solutions for an analog world
> >>>
> >>>EID Award Winners for  'Best Use of Technology' 2003 for the
> >>>AcoustarTM ZXCW8100 End-to-End Digital Audio Amplifier Controller
> >>>
> >>>http://www.zetex.com
> >>>_________________________________________________________
> >>>
> >>>######################################################################
> >>>E-MAILS are susceptible to interference. You should not assume that
> >>>the contents originated from the sender or the Zetex Group or that they
> >>>have been accurately reproduced from their original form.
> >>>Zetex accepts no responsibility for information, errors or omissions in
> >>>this e-mail nor for its use or misuse nor for any act committed or
> >>>omitted in connection with this communication.
> >>>If in doubt, please verify the authenticity with the sender.
> >>>######################################################################
> >>>
> >>>------------------------------------------------------------------
> >>>To unsubscribe from si-list:
> >>>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
> >>>
> >>>or to administer your membership from a web page, go to:
> >>>//www.freelists.org/webpage/si-list
> >>>
> >>>For help:
> >>>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >>>
> >>>List technical documents are available at:
> >>>                http://www.si-list.org
> >>>
> >>>List archives are viewable at:
> >>>              //www.freelists.org/archives/si-list
> >>>or at our remote archives:
> >>>              http://groups.yahoo.com/group/si-list/messages
> >>>Old (prior to June 6, 2001) list archives are viewable at:
> >>>              http://www.qsl.net/wb6tpu
> >>>
> >>>
> >>>
> >>>
> >>
> >>--
> >>
> >>------------------------------------------------------------------
> >>To unsubscribe from si-list:
> >>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
> >>
> >>or to administer your membership from a web page, go to:
> >>//www.freelists.org/webpage/si-list
> >>
> >>For help:
> >>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >>
> >>List technical documents are available at:
> >>                http://www.si-list.org
> >>
> >>List archives are viewable at:
> >>                //www.freelists.org/archives/si-list
> >>or at our remote archives:
> >>                http://groups.yahoo.com/group/si-list/messages
> >>Old (prior to June 6, 2001) list archives are viewable at:
> >>                http://www.qsl.net/wb6tpu
> >>
> >
> >
> > -- Binary/unsupported file stripped by Ecartis --
> > -- Type: text/x-vcard
> > -- File: engin.vcf
> > -- Desc: Visitenkarte für Ege Engin
> >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from si-list:
> > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
> >
> > or to administer your membership from a web page, go to:
> > //www.freelists.org/webpage/si-list
> >
> > For help:
> > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >
> > List technical documents are available at:
> >                 http://www.si-list.org
> >
> > List archives are viewable at:
> >               //www.freelists.org/archives/si-list
> > or at our remote archives:
> >               http://groups.yahoo.com/group/si-list/messages
> > Old (prior to June 6, 2001) list archives are viewable at:
> >               http://www.qsl.net/wb6tpu
> >
> >
> >
> >
> 
> --
> -------------------------------------------
> Steven D. Corey, Ph.D.
> Time Domain Analysis Systems, Inc.
> "The Interconnect Analysis Company."
> http://www.tdasystems.com
> 
> email: steven.corey@xxxxxxxxxxxxxx
> phone: (503) 246-2272
> fax:   (503) 246-2282
> -------------------------------------------
> 
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
> 
> or to administer your membership from a web page, go to:
> //www.freelists.org/webpage/si-list
> 
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> 
> List technical documents are available at:
>                 http://www.si-list.org
> 
> List archives are viewable at:
>                 //www.freelists.org/archives/si-list
> or at our remote archives:
>                 http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
>                 http://www.qsl.net/wb6tpu
>

-- Binary/unsupported file stripped by Ecartis --
-- Type: text/x-vcard
-- File: engin.vcf
-- Desc: Visitenkarte für Ege Engin


------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List technical documents are available at:
                http://www.si-list.org

List archives are viewable at:     
                //www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu
  

Other related posts: