[SI-LIST] Re: AW: S-parameter reference shift

  • From: "L R" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "lrayzman" for DMARC)
  • To: "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>
  • Date: Thu, 27 May 2021 17:58:26 +0000 (UTC)

Thank you for your feedback.  There may be couple of things I am not clear on 
based on below explanation. While by definition s-parameter does not 
explicitly internalize any conductive connections between ports, it is my 
understanding that it does describe all and any conductive paths that exist in 
my physical problem. If this is correct, then in my scenario all ports, 
including B, not isolated of each other but rather do have non-ambigous 
predictable path (it would be ambiguous if no predictable path exists between A 
and B planes at DC). Here I am simply breaking up  a loop A-B, into let's call 
it "forward" and "return"  sub-paths.  By that reasoning I would think then 
choose A side reference as reference for entire s-parameter still should still 
be captured correctly? 
Lenny
    On Wednesday, May 26, 2021, 10:41:21 PM PDT, Havermann Gert 
<dmarc-noreply@xxxxxxxxxxxxx> wrote:  
 
 Hi Lenny,
Vladimir is correct. I think the main problem in your case is how you defined 
the reference. S-Parameters only allow one global reference. If you are 
interested in seeing differences between planes, then you should define all 
planes as nodes and add a separate reference (a plane far away from other ports 
and metals) for the S-parameters.
BR
Gert



----------------------------------------
HARTING Stiftung & Co. KG | Postfach 11 33, 32325 Espelkamp | www.HARTING.com
Persönlich haftende Gesellschafterin:
HARTING Führungsstiftung | Amtsgericht München | HRA 108479 | München
Vorstand: Dipl.-Kfm. Philip F. W. Harting (Vorsitzender), Dipl.-Kffr. Maresa W. 
M. Harting-Hertz, Dipl.-Kfm. Dr.-Ing. E. h. Dietmar Harting,
Dipl.-Hdl. Margrit Harting, Dr.-Ing. Kurt D. Bettenhausen, Dipl.-Ing. (FH) 
Dipl.-Wirtsch.-Ing. (FH) Andreas Conrad, Dr. iur. Michael Pütz
Sitz der Gesellschaft: Espelkamp | Amtsgericht Bad Oeynhausen | HRA 9021 | 
UST-ld Nr. DE812136745

-----Ursprüngliche Nachricht-----
Von: si-list-bounce@xxxxxxxxxxxxx <si-list-bounce@xxxxxxxxxxxxx> Im Auftrag von 
Dmitriev-Zdorov, Vladimir
Gesendet: Donnerstag, 27. Mai 2021 04:50
An: si-list@xxxxxxxxxxxxx
Betreff: [SI-LIST] S-parameter reference shift

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


------------------------------------------------------------------
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
  

  
------------------------------------------------------------------
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: