[SI-LIST] Re: N-port model limitations in simulators

  • From: "Jian X. Zheng" <jian@xxxxxxxxxx>
  • To: <Raymond.Anderson@xxxxxxx>, <si-list@xxxxxxxxxxxxx>
  • Date: Wed, 23 Apr 2003 08:53:00 -0700

Hi, Ray:

I think the questions you posted are very interesting ones. I discussed such
topics with quite some engineers extensively, and I would like to make some
comments on it:

1. For an N-port structure, normally we should model it as N+1 node
structure if it does have a common big ground.

2. For an N-port structure, if you want high accuracy results, it would be
better to consider it as 2N-port structure. For the 2N-port structure, it is
not neccessary to have a common (2N+1) node. I think the most important
thing is that you need to have some common node for each pair of MATCHING
NODES FOR CONNECTION. What I mean MATCHING NODES FOR CONNECTION is the
following. Assume we are connecting 2 circuits together:

  1                    3 5                   7
  o====================o-o===================o
           Circuit A           Circuit B
  o====================o-o===================o
  2                    4 6                   8

Both A and B are differential structures. Circuit A should be described as a
4-port (ports 1, 2, 3, 4) s-parameters instead of the regular 2-port
s-parameteres. Circuit B should be described as another 4-port (ports 5, 6,
7, 8) s-parameters. Each port of the A and B does not need to reference to a
common node. The most important thing is that the port 3 of circuit A and
the port 5 of circuit B should have a common local reference for them. I
will refer the port 3 of circuit A and the port 5 of circuit B as a pair of
MATCHING NODES FOR CONNECTION. The common reference for the pair should not
be electrically too far away from the port 3 of A or port 5 of B. The common
local reference for the pair should be some metallic structure physically
there.

In case the common reference for the pair is too far away from the port 3 of
A or port 5 of B, the circuit A and circuit B are not separatable. When we
separate them, we are introducing ambiguities into the model.

In some sense, when we try to model a complicated circuit, we should be very
careful in deciding where we should cut them into smaller pieces. We should
try to cut them at where the MATCHING NODES FOR CONNECTION should have some
common reference close to them. It is not necessary the common reference to
be the ground of the system. It just needs the common reference to be a real
piece of good conductor and to be close to the MATCHING NODES FOR
CONNECTION.

In fact, the (N+1) node approach is a special case for this case. The common
refernce for each pair of MATCHING NODES FOR CONNECTION is the same big
ground.

3. For a WELL implemented EM simulator, such problems should be solved.
However, the question is how you use it correctly. For example, you need to
know where you should cut the circuit into pieces and where you should not
cut them.

4. For some circuit simulators, a port is described as 2-nodes. However, the
2-nodes are inseparable. I see users using the 2-port coaxial line
s-parameters in the following way on a circuit simulator:

                    o====outer conductor======o
             Port 1       coaxial section        Port 2
                    o====inner conductor======o
                    |                         |
                    -----------||--------------
                            C
Such a connection on a circuit simulator is completely wrong because all the
circuit simulators will assume the waves inside it is TEM mode. When you
connect a capacitor like that, you are exciting higher order modes. Higher
order modes are not implemented for coaxial structure in a regular
simulator. However, I think quite some circuit simulators allow you to
connect the circuits as above.

Regards
-----------------------------------------------------------------------
Jian-X. Zheng, Ph.D
Zeland Software, Inc., 48890 Milmont Drive, 105D, Fremont, CA 94538, U.S.A.
Tel: 510-623-7162, Fax: 510-623-7135, Web: http://www.zeland.com
---------------------------------------------------------------------

> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx
> [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Ray Anderson
> Sent: Tuesday, April 22, 2003 2:07 PM
> To: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] N-port model limitations in simulators
>
>
>
> This message deals with what I am perceiving as some
> significant limitations in the n-port model implementations
> in current day SI simulators. For those who have the stomach
> to wade through my prose I pose a few questions to base
> further discussion on at the end of the message.
>
> I think many SI engineers will agree that the use of
> s-parameters to characterize certain circuit elements
> has become an important tool in today's high-speed
> simulation environment.
>
>
> S-parameters can fully characterize an arbitrary n-port.
> In this message I'll restrict the discussion to 2-ports
> to simplify things.
>
> A 2-port representation of a network has separate
> reference nodes for each port. Hence a 2-port has
> 4 nodes or terminals associated with it.
> (in general a n-port has 2*n terminals):
>                       _________
>               +_______|       |___________+
>                       |       |
>       Port 1  -_______|       |___________-   Port 2
>                       |_______|
>
>
> Many popular simulation engines now provide native support
> for n-ports characterized by s-parameters. However it seems
> that many of the models utilized by these simulators only
> support n-ports with a common reference node (n+1 nodes):
>
>                       _________
>                       |       |
>       Port 1  --------|       |-------  Port 2
>                       |       |
>                       |_______|
>                           |
>                           |
>                         Common
>
> Having a common reference node limits the utility of these
> n-port models for a variety of purposes:
>
> 1     Can't have a DC offset between the input and output ports
>
> 2     Common nodes that are physically separated can't be modeled
>       as such (connectors for example).
>
> 3     Can't be utilized to accurately model planes which are spatially
>         large.
>
> 4     Can't be utilized for SSN simulations. (seems like return paths
>         are being ignored)
>
> 5     and the list goes on and on ..........
>
> It seems that the restriction of a common reference node harkens
> back to the mythical global ground concept (node 0) of spice.
>
> All voltage measurements are taken in reference to some reference node.
> In DC and low-frequency simulations you can get away with the concept
> of a global ground in a lot of cases, however for high-speed simulation
> one might as well forget the global reference concept as it certainly
> isn't useful in cases where delays in the picosecond range can be
> significant.
>
> In the case where several n-ports are cascaded to model a signal
> propagation path (say from a driver, through a package, through a
> PCB trace, through a connector, through more PCB trace, through
> another package and ultimately to a receiver) the assumption the
> the reference node at the driver package is the same as the reference
> node at the receiver package is just wishful thinking. It isn't so!
>
> Some simulators have a proper n-port model (in the case of ADS there
> is a proper 2-port model [S2pmdim] but all the other n-ports s1p to
> s99p have a single reference. There may be other simulators that
> handle the problem correctly but I'm not sure which ones.
>
> So the question is: How do people handle this issue?
>
>       1) Ignore it and hope it goes away
>
>       2) Use a simulator that supports a correct model
>          (which one)
>
>       3) Create 'black-box' models with an external tool that
>          provides multiple references and use these models
>          in spice or whatever.
>
>       4) Combine n-ports into a 'big' n-port via T or ABCD parameters
>          off-line and then use the composite n-port in a simulator
>          that only supports a single reference in the n-port model.
>
>       5) Come other solution.
>
>
> I'm posing these questions not in search of a simple answer, but as
> a springboard for discussion. Is the problem real? Why the restriction
> to a single reference?        Is the restriction based on programming
> considerations or actual mathematical restrictions? Workarounds?
>
>
> -Ray Anderson
> Sun Microsystems Inc.
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------
> 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 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 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: