[SI-LIST] Re: Preparing S-Parameters for Simulation
- From: Peter.Pupalaikis@xxxxxxxxxx
- To: <si-list@xxxxxxxxxxxxx>
- Date: Wed, 25 Feb 2009 18:35:58 -0500
Okay, I can't resist. My two cents.
I agree more or less with most comments, but here are mine:
1) ideally you have DC. If you are using a VNA to measure, then you can
use a digital multi-meter
to obtain the DC measurements and insert them. If you are using TDR, you
get these points. Otherwise,
if you are using a VNA, do not try to get close to DC. VNAs have very bad
accuracy even in regions where
they allow measurement. As most extrapolations are performed using the
first few points, you do not want these
points in error. typically, I would determine my frequency spacing and
then just omit the DC point - usually the
frequency spacing can be such that you stay away from the VNA trouble
spots.
2) regarding frequency spacing, it is really about the length of your
circuit. If the length is short, you can sample
very coarsely. If the length is long, you will need finer resolution. I
don't think about this from the standpoint of
preserving frequency domain bumps and wiggles, but rather from the
time-domain perspective of how much
length do I need to avoid time aliasing. I use a rule of thumb of taking
the length of the circuit, in seconds, take
1/2 the reciprocal of this, and then divide this by a cheat factor where
the factor can be as low as 1 for very lossy
and well matched devices to 5 or 10 for poorly matched, lossless devices.
This gives the linear frequency spacing.
3) linear frequency spacing is easier to deal with. As pointed out, we'd
like to use an IFFT to get back to time and
then Chirp-Z transform to get back to frequency if we need to do some
interpolation. This interpolation might only
be required to combine s-parameters of many devices with different lengths
and therefore different frequency resolutions.
4) I don't like the idea of the rational function fit, unless it
incorporates the things that we should be concerned with. A
transmission line or anything with lots of delay is a poor fit to a
rational function. I've seen the idea (used in Matlab) of
a single principle delay (i.e. a rational function multiplied by a complex
exponential containing the delay) but this ignores
the reflections. What we really want are sums of delayed rational
functions. This seems complicated to figure out.
5) regarding causality and passivity, there is much made about things like
this and often much more made than the problems
caused. A passivity or causality violation is only a special type of error
made in measurement or simulation. For some reason
we are more concerned about the error when it causes passivity violation
than we are when it doesn't (it's still an error, right?).
I may be way off-base, so please don't think I'm trying to generalize for
everyone, but if you are simulating relatively simple
channels (which it doesn't sound like everyone is doing), causality and
passivity violations, if small, don't really cause any problems
aside from the problems with having errors.
6) We fix passivity violations, if desired, by making minimum-norm changes
to the s-parameters to make the s-parameters passive.
Even though it is the minimum, it does affect the s-parameters and does not
change the fact that there are errors. It may even
make things worse. Passivity violations are very easy to detect and the
extent of the violations can be examined to see if one
even wants to use the model generated - but again, we cannot detect the
other errors that did not cause passivity violations!
7) I'm not sure what Vladimir was talking about regarding realness from
s-parameter data. Whenever you inverse transform to get
back to the time domain, you enforce realness by producing the negative
frequency data as the complex conjugate of the positive
frequency data provided. Vladimir, if you can explain this further, I'd be
interested to know what you're thinking.
Only my two-cents - I don't consider myself an expert.
Pete
"Dmitriev-Zdorov,
Vladimir"
<vladimir_dmitrie To
v-zdorov@xxxxxxxx <si-list@xxxxxxxxxxxxx>
om> cc
Sent by:
si-list-bounce@fr Subject
eelists.org [SI-LIST] Re: Preparing
S-Parameters for Simulation
02/25/2009 05:39
PM
Hi Timothy,
I agree with those already commented in this thread.
The topic is interesting and virtually endless.
Please find my comments below.
Vladimir
Going along the bullets in your original mail:
#1
Ideally, we need to start from DC, support sufficient resolution and end
up either where the dependence reaches its high frequency asymptotic, or
at least 2-3 times the upper frequency limit of interest (that depends
on desired resolution in time domain).
"Sufficient resolution" during AC sweep means being able to track all
important changes. For example, if we consider trajectory plot (Imag
part versus Real, as it develops in frequency), it should demonstrate
smooth trajectory, leaving no doubts about directory of rotations and
location of turning points.
Good resolution does not mean linear spacing. On the contrary, linear
spacing prevents us from having equally smooth representation at low and
high frequencies, and if needed, at sharp resonances. For example, with
1Mhz step, we have only 10 points per decade below 10MHz that in most
cases means undersampling and inability to accurately represent low
frequency portion of the data. Same step, at 1GHz or more gives us 1000
points per decade that is likely an oversampling. Some wide band systems
may require up to 6-7 or more decades. We cannot accurately represent
with systems with linear spacing. Logarithmic? Well, this one could be
better, but there is a danger of missing important details on high
frequency side, especially if the model exhibit some delay. The best
strategy that we support is adaptive sampling in AC sweep that shows
everything of importance without taking too much simulation efforts and
disk space to store the points.
Interesting, that linear spacing appeared for a reason not directly
related to accuracy. Many of existing S-parameter tools perform IFFT to
convert frequency into time domain responses and then use convolution to
generate solution in time domain (C-tools). IFFT requires linear
spacing; even if the data is sampled differently, such tools convert it
into linear spacing and add interpolation errors. However, there are
other tools exploiting the idea or pole-zero representation or vector
fitting (F-tools). They don't care about spacing but require sufficient
resolution and 'complete definition'.
About DC point definition. If it is not possible to extract DC point
directly, it is better to leave it missing. NEVER try to insert this
point or close points manually, or by some brute force correction tools.
Practically, the tools based on vector fitting are able to precisely
restore DC point if there is a sufficient resolution within low
frequency region, next to it. However, if there is an important portion
of the dependence missing, then unambiguous restoration could be a
problem.
#2 When fixing causality or/and passivity, we always change the original
model. There is no single way of doing corrections; they could be based
on certain - different - assumptions and criteria. This creates
ambiguity and difference between solutions from different 'good' tools.
The model by itself should be causal and passive, as much as possible.
Then, the process becomes less ambiguous.
#3 Perhaps, rational polynomial approximation or vector fitting is the
best cleaner. Possibly, we'll have to try different order of
approximation, perhaps normalization and/or asymptotic settings if the
data at DC or high frequencies is missing or not reliable. It is very
important to use the interactive tool with complete visualization of
every step, including control on causality and passivity. In Mentor, we
have such tool. On each step, the user can visually compare solutions
from different parameter choices. Finally, the cleaned up model is saved
ready for simulation. Sometimes, it is useful to contact to the source
of model, e.g. measurement lab. They can say that "the data above 10GHz
is not that reliable". This is a useful info.
Separate question is whether the Touchstone is the best way of storing
models. Yes, it is an accepted standard and is supported everywhere.
However, being a tabulated model - more or less precise - it is not a
ready to eat thing. Some additional cooking/processing is always needed
to allow time domain simulation. Not only this processing is sometimes
parameter-dependent, it also takes considerable time. For example, we
simulated several models described by Touchstone files with large number
of ports (from 60 to 230). With hundreds of MB file size, it takes up to
15-20 minutes just to read such file. That's why for our internal use we
prefer pole/residue tables to represent such models. Typically, the file
size of such table is 20-40 times smaller than original Touchstone. More
importantly, this model is completely unambiguous (analytical) and ready
to use.
#4 The inspection tool must evaluate passivity (show passivity plot),
resolution (trajectory plots help a lot!). Causality is somewhat
difficult to tell from the screen. Roughly, you should not observe
counter-clockwise rotation on the trajectory plot, this is indication of
non-causality. However, some smooth nicely looking dependencies may
happen to be non-causal. We can see this as inability to find close
rational fit. (Of course, we trust our tool and know that it works fine
with good models).
As Yuriy mentioned, symmetry of the matrix is an important indicator.
Reciprocal systems possess symmetrical matrices of S, Y and Z
parameters. If we know that the model is reciprocal but see asymmetry,
this is an indication that the data is not precise and by evaluating
asymmetry quantitatively, we can make conclusions about overall
accuracy.
Another criterion is "realness". As we know, the time domain response is
a real function. From here it follows that real part of the dependence
should be even, imaginary - odd function. Since S-parameters are bounded
by norm, this implies that the odd derivatives of real part close to DC
must be zero. Similarly, even derivative of imaginary part should be
zero, too. This can be visually checked on the plot. If we see opposite,
there is a problem with the model.
>From: "Timothy Coyle" <tim@xxxxxxxxxxxxxxxx>
>Subject: [SI-LIST] Preparing S-Parameters for Simulation
>Date: Tue, 24 Feb 2009 12:51:34 -0500
>Hi,
>I am working on a tutorial for the next issue of XrossTalk Magazine
about >getting S-Parameter models ready for simulation. I see a lot of
S-Parameter >models from lab measurements and simulation tools that have
a lot of quality >issues (causality and passivity) and have to do a lot
of clean up to make >them suitable for simulation. I have my own bag of
tricks I use as well as >some good books on S-Parameter theory and
application notes but I would like >to hear from other people what their
approaches are or some good resources.
>For some particular specifics review the list below:
>
>. What considerations should go into setting up a simulation
tool to
>extract an S-Parameter model? (bandwidth to be used, number of points,
>importance of linear spacing of points, starting at DC, etc)
>
>. A lot of tools will automatically "fix" causal and passivity
>issues or enforce them. What's the pros and cons for this? What do
engineers >need to look out for when they do this?
>
>. What's the best way to clean up a lab measured S-Parameter
model
>with poor resolution?
>
>. What type of quality checks should you perform on an
S-Parameter
>model before simulating? (what do you look for in the S21 plots, do you
use >smith charts, ect?)
>
>
>
>Thanks for any and all suggestions and links.
>
>
>
>Best,
>
>
>
>Timothy Coyle
>
>Editor In Chief
>
>XrossTalk Magazine
>
>405 Western Ave #430
>
>South Portland, ME 04106
>
>Tel: 617.297.2566
>
>Fax: 207.510.8099
>
>Email: tim@xxxxxxxxxxxxxxxx
>
>http://www.xrosstalkmag.com <http://www.xrosstalkmag.com/>
<http://www.xrosstalkmag.com/>
>
------------------------------------------------------------------
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 technical documents are available at:
http://www.si-list.net
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 technical documents are available at:
http://www.si-list.net
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:
