[SI-LIST] S-parameter reference shift

  • From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
  • To: "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>
  • Date: Thu, 27 May 2021 02:49:31 +0000

Hi Lenny,
Please be aware that in general, replacing a part of your design with 
S-parameters may not be an equivalent substitution. What S-parameters (and also 
Y, Z) can capture is only relations between port variables (port waves, 
voltages, currents), but not the voltages between the terminals of different 
ports. Think of the S-parameter block as a model which only defines all 
transfer functions between variables of ports (m, n), where m, n are all port 
index pairs. Numerical implementation of such transfer functions inside any 
simulator is equivalent to ideal transformers, with no conductive connection 
between the coils. What it means is that if in the original design you had e.g. 
1V DC shift between nodes that now are (+) terminals of the two different 
S-parameter ports, you may get a very different "voltage" if it is not a port 
voltage.

The two things to remember about S-parameters:
1. Port constraint: the current that enters positive terminal of the port and 
the current that leaves negative terminal of this port are forced to be the 
same. If such restriction didn't exist in the original design, you may get a 
different solution.
2. No conductive connection exists between different ports inside S-parameter 
model (it should be defined outside). If such connection existed in your 
design, the result could be different.

If two above restrictions make sense for your design, you should be getting 
correct port variables, but don't try to compare voltages between "A" and "B" 
ports.

If I remember correctly, spice instance of the S-parameter model has two 
formats. In one, you only need to define "positive" terminals of each port, by 
associating them with node names. In this case, Hspice will automatically 
connect all reference terminals of each port to a "global reference". After 
connecting each port's reference terminal to the global reference, you can 
measure voltages between distant terminals, however the result might be 
different from your expectation. Indeed, did you have the voltage at nodes 
which now become port reference terminals be all zero? If not, that's an 
explanation of why you have different results. There is a more general syntax 
for S-parameter ports' terminals assignments, in which you need to explicitly 
define the nodes for both positive and negative (reference) terminal of each 
port. In this case, you have more flexibility, but still no guarantee that you 
will get the same voltage across different ports.

Vladimir
 
 

From: "L R" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "lrayzman" for
Subject: [SI-LIST] S-parameter reference shift

Hello SI-Listers,
I am describing a physical model with s-parameter, where I have a group of 
ports, call them A-group, referencing a local plane. There is then another 
group of ports, B-group, referencing another local plane.  There are general 
paths between A-group and B-group which is what I am interested to describe by 
s-parameter. An important detail is that all B-group connections, including 
returns, are ports which are referenced to B-plane as opposed to conventional 
method where a port represents both forward and return paths. (This is done 
intentionally for reasons that are not as relevant here.)Suppose the planes are 
interconnected through a conductive path, with conductivity perhaps few orders 
of magnitude higher than conductivity of local planes.  Logically this is 
similar to a split plane scenario except there is a weakly conductive path 
connecting the planes, to  ensures a predictable conductive path from A-plane 
to B-plane at DC. The s-parameter is solved with an explicit conductive s  olve 
at 0Hz, presumably correctly. I then use this parameter in spice, where I am 
careful to properly connect circuits to ports such that there is no improper 
cross-plane interaction. What I mean by that is, if A-group ports are 
referenced to same spice node as a reference for s-parameter, then connectivity 
for B-  ports referenced only with respect to each other. In this way my 
intention is allow currents to flow through through immediate paths between 
A-and B- group with (theoretically) no/negligible DC currents to flow through 
path between planes. Now, I energize a set of A- ports with known voltage 
source. This will energize the circuit on B- side.  What I expect is voltages 
on any B-side node to remain within levels of A- side (since B- circuitry is 
drawing and not sourcing, and as measured both relative to B-side and A-side). 
What I may often see on B- side is the entire group is shifted *outside* of the 
range of the A-group voltage, typically below the reference level of A-group.  
However, without looking ac  ross A- to B- boundaries, each A- or B- side 
locally is behaving as expected. Note that this entire discussion is at 0Hz as 
computed by spice DC operating point for the complete circuit. I don't think 
all this is some illegal use of s-parameters -- this is just simply calling out 
a different location as port reference. I am wondering if any one has some 
insight into what could be causing this. More importantly is there a method to 
detect this condition? It seems satisfying passivity is not sufficient here.
Best regards,Lenny Rayzman


------------------------------

End of si-list Digest V2 #91
****************************

------------------------------------------------------------------
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 forum  is accessible at:
               http://tech.groups.yahoo.com/group/si-list

List archives are viewable at:     
                //www.freelists.org/archives/si-list
 
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu
  

Other related posts: