[SI-LIST] Re: N-port model limitations in simulators
- From: Zhangkun <zhang_kun@xxxxxxxxxx>
- To: Raymond.Anderson@xxxxxxx, si-list@xxxxxxxxxxxxx
- Date: Wed, 23 Apr 2003 11:29:27 +0800
Dear Ray:
I have worried about the same problem. When I measure or simulate s-parameter,
there is no common reference node. But when I simulate by means of s-parameter,
there is common reference node.
I am using s-parameter to simulate power ground plane. In simulation, the two
ports use common reference node. Comparing the simulation and measurement
results, they agree with each other very well.
I guess the method, which use common reference node, has some problem. But I
have not find out some example to verify it.
Best Regards
Zhangkun
2003.04.23
----- Original Message -----
From: "Ray Anderson" <Raymond.Anderson@xxxxxxx>
To: <si-list@xxxxxxxxxxxxx>
Sent: Wednesday, April 23, 2003 5:07 AM
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:
