Hi Lenny,
Good interesting feedback.
The port reduction was suggested only as a debug/troubleshoot method for your
large port count S-par... I wasn't implying that it will somehow improve the
issue you are faced with...
If you observe that small cases work as expected... but issues arise when you
scale to a larger problem... are you able to create some intermediate test
cases where you can delineate where the departure from the expected results
starts to show up in your test cases? Perhaps that can provide some clues as
to where to spend some cycles...
Also, if this ends up being a DC point modeling issue with the EDA tool that
leads to some undesirable S-par model behavior, then you may have to simply
collaborate with your favorite EDA AEs to dig into this further. (If it
happens to be mine, then I'd be happy to help!!! :-)
Regards,
Chase
___________________________________________________
Signal and Power Integrity | Siemens EDA (Mentor) | Boston, USA
+1-508-565-8080
yun_chase@xxxxxxxxxx
https://support.sw.siemens.com/
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On ;
Behalf Of L R
Sent: Friday, May 28, 2021 10:06 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: AW: S-parameter reference shift
ve also created a simple resistor based low port count conceptual version of my
setup, where I could easily derive Z parameter, from which I can obtain the
s-parameter as a baseline to put to rest any doubts in numerical solution. In
such simple cases I get expected results. It appears when I scale this to a
large port count the results are not consistent. Port reduction of s-parameter
does not improve matters. The general observation is the voltages/currents
within A group and B group are correct, and as a matter of fact the
propagations between A group and B group ports are preserved. What I mean by
that is signals generated across ports of one side are preserved to across
ports other side exactly as expected -- essentially what Vladimir alluded to.
But there can be a "common mode" (if you will) voltage shift of entire set of B
ports, often outside of valid range of . It is also evident that it is the
s-parameter itself , and not the surrounding circuitry, that is the f orcing
function for operating point calculation of spice engines to force the shift.
Again this is all DC/operating point, and s-parameter contains explicit 0Hz
point from explicit conductive solution rather than extrapolated. Besides the
obvious question why this happens, the other question for me has been how to
best detect this on s-parameter directly. As to avoid the tedium of checking
s-parameter by wiring up 10s to 100s of ports every time for checking by spice
analysis. Best,Lenny
On Thursday, May 27, 2021, 08:22:14 PM PDT, Chase, Yun
<yun_chase@xxxxxxxxxx> wrote:
Hi Lenny,
Starting with your S-parameter model itself:. What does the Insertion Loss look
like on those groups of Ports as you approach DC: Can you make any sense of
it? Does it look reasonable? If not, then are you able to reduce the number
of Ports in your model? Sounded like you have multiple groups of numerous
Ports: then try to reduce it down to just a Port A and a Port B: And then run
through the Insertion Loss and your DC simulation exercise: Do those results
make any sense? Based on that observation, you will have to decide whether to
try a slightly larger model if you got some good results there:or if none of
that makes sense at all, then Yuriy just gave you one of the best advices for
free of charge: "create a very simplified problem and investigate"!
If you suspect a tool issue in the S-par extraction part: then create a simple
Transmission line model: place 2 ports on it: and then run through your
simulation exercise again. Do the DC results make sense now? A simple single
ended Microstrip project for our HyperLynx Advanced Solvers is one I hold
dearly: I always go back to that project if I need to do a sanity check on
anything that might not be so obvious to me at any given moment: I get a lot of
mileage out of it. Actually, I also hold a simple flipchip Package design as
well which can run really fast but can give valuable answers to questions that
I might have for the day. These kinds of simple designs can help you to fast
root cause some simple "uh-oh" moments:
OK, in the worst case if that simple problem fails to make sense: then you
could even create a simple resistor network in a schematic based circuit
simulation tool like HyperLynx LineSim (or any other circuit simulation tool of
your choice) and create an S-par from that resistor network: and then run your
DC simulation using that S-par model: Could that help to increase your
understanding of the problem? Perhaps...
And lastly: are you by any chance working with Package ports where you have to
lump multiple groups of IC Pins to create Ports? At DC, this might not matter
too much but sometimes that could cause some numerical instabilities during the
full system solve: Or how about, do you have any series components embedded in
the model as part of your S-par extraction? If yes, then are you comfortable
with the circuit component model that is being used? There are so many
factors: but without fully knowing what you are working with it's tough to
troubleshoot from the gallery:. But again: using a simplified model to get a
baseline of the circuit behavior will, for sure, should help you to root cause
the issue faster. Certainly does it for me....
If you want, feel free to reach me offline: I'd be happy to go through a web
session with ya to run through some quick examples to validate our thinking
process:
Just my 2 cents...
Regards,
Chase
___________________________________________________
Signal and Power Integrity | Siemens EDA (Mentor) | Boston, USA
+1-508-565-8080
yun_chase@xxxxxxxxxx
https://support.sw.siemens.com/
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Yuriy Shlepnev
Sent: Thursday, May 27, 2021 2:26 PM
To: lrayzman@xxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: AW: S-parameter reference shift
Hi Lenny,
If everything is defined as you described, I think that your expectation are
correct. If S-parameters are properly extracted and include at least asymptotes
to DC, you should see some correlation between voltages at A and B, but only in
the flat parts of a step response (that is also corresponds to the DC
solution). If not, something is wrong. In such cases I would create a very
simplified problem and investigate.
Cross-probing of transients or AC for a distributed electrically large system
may produce some strange useless results, that can be simply explained by the
delays within the system. For instance, AC response of ideal t-line segment
terminated with characteristic impedance and 1 V travelling wave on one end
will give 1 V at the other end, but if we cross-probe (virtually) the opposite
ends we will observe values from 0 to 2 V, depending on the electrical length.
Best regards,
Yuriy
Yuriy Shlepnev, Ph.D.
President, Simberian Inc.
www.simberian.com
Simbeor THz - Accurate, Productive and Cost-Effective Electromagnetic Signal
Integrity Software to Design Predictable Interconnects!
Simbeor SDK - The Industry-First Signal Integrity Analysis Automation Kit!
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On ;
Behalf Of L R (Redacted sender "lrayzman" for DMARC)
Sent: Thursday, May 27, 2021 10:58 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: AW: S-parameter reference shift
Thank you for your feedback.б here may be couple of things I am not clear on
based on below explanation.б ile 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б loop A-B, into let's call it "forward" and
"return"б ub-paths.б y that reasoning I would think then choose A side
reference as reference for entire s-parameter still should still be captured
correctly?б enny
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цTnlich 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
