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.б= 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ц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