[SI-LIST] Re: timing in s-parameters
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: "Alfred P. Neves" <al@xxxxxxxxxxxxxxxxx>
- Date: Fri, 5 Sep 2014 12:21:40 -0400
Al,
My approach is not at all solver-centric, but I do appreciate what you say.
In all measurements and solver modeling, it should always be a goal to
reduce the systematic errors as much as is possible. And I do understand
that test boards are a special case. Passivity is always a problem that
should be considered, but in real systems where you are concatenating
models end-to-end, a little bit of non-passive behavior in one of the
component models does not precluded it from being used, if, and only if,
you perform a frequency domain sweep and resample of the end-to-end model.
I maintain that the non-passive noise then becomes swamped out by losses
elsewhere and is therefore a non-issue.
As for causality, you have to be aware of all possible multipath behavior
in the complete system that is being measured. That multipath behavior can
occur at low frequencies and at high frequencies. At ultra low frequencies,
fields penetrate through pretty much everything. Poor measurement cable and
launch isolation can contribute to the problem. This is where your training
for engineers and technicians is helpful.
Whenever you make a measurement with a VNA, you are truncating the
measurement domain of the system arbitrarily, unless you are measuring all
ports of a closed shielded system. This is no different than what happens
with various EM solvers. You are also extending the measurement domain to
beyond the system black box through cables, adapters, and front ends. On
the measurement side you need to be careful about the measurement domain
and reduce systematic errors to as close to zero as possible. That is the
measurement technician's job.
However, I maintain that even when you reduce measurement error to absurdly
low values, because you have truncated the system measurement space by
instrumenting very specific ports, there are additional perceived
"causality" concerns due to multipath propagation that must be considered.
In fact, a simple single-ended 2-port net that is fully isolated from the
rest of the universe can exhibit what appears to be non-causal behavior
when measured and checked with automated tools, when, in fact, it is
totally causal. This has nothing do do with a real or synthetic measurement
environment (instrument or EM computation). It has to do with the physical
nature of the system under test. Many causality checkers do not adhere to
the strict definition for causality, that is, that the system never
exhibits faster than light propagation from input to output. As a result,
erroneous causality issues are reported.
Often, what is reported are issues that cause leading edge pulse distortion
in an impulse or step response analysis. As you know, Al, there are reasons
why poor measurement technique and noisy instruments can cause these
distortions, which you deal with and evangelize about, but there are also
real physical system causes for leading edge pulse distortion that are
often overlooked. I'm just sayin' ... look for both.
Scott
Scott McMorrow
Teraspeed® Consulting - A Division of Samtec
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
On Fri, Sep 5, 2014 at 10:10 AM, Alfred P. Neves <al@xxxxxxxxxxxxxxxxx>
wrote:
> I see it differently. Even minor passivity measurement error is often a
> symptom of a bad calibration, or a good one that has drifted. Minor is
> .05dB realm. Except for short adapters we do not tolerate raw passivity
> error. Errors in the forward transmission relate to VNA coupler
> directivity or excessive cable movement, which is often an issue at low
> frequency where we us usually see related causality problems.
>
> There is risk in your approach, it is solver-centric and not metrology
> centric.
>
> Sent to you confidentially by ipad2.
>
> > On Sep 5, 2014, at 4:02 AM, Scott McMorrow <scott@xxxxxxxxxxxxx> wrote:
> >
> > In the case of cascaded s-parameters in the frequency domain, minor
> > passivity is never an issue for the individual s-parameters. It
> represents
> > measurement or solver error (or in the case of TD full wave solvers it
> > usually represents insufficient run time prior to the TD-FD
> > transformation.) But as long as the passivity errors are slight, they
> are
> > eaten up in the losses of the cascade. That is one reason why we
> recommend
> > cascading s-parameters in the frequency domain and resampling prior to
> > simulating in the time domain. Multiple venial sins are absolved by doing
> > this.
> > Causality issues should also be reviewed for severity. Again, minor
> > causality violations can be ignored if they are within the bounds of
> > uncertainty of your simulation itself. They may also be real. Causality
> > checking algorithms make the assumption that no signal can travel from
> the
> > driver to the receiver faster than the through path. However, the
> question
> > is: This is not always true with measurements (or even solutions from EM
> > solvers). The real world does things that look like causality issues
> when
> > analyzed, but are in actuality not. Real world systems are multipath
> > problems.
> >
> >
> > best regards,
> >
> > Scott
> >
> >
> >
> > Scott McMorrow
> > Teraspeed(R) Consulting - A Division of Samtec
> > 16 Stormy Brook Rd
> > Falmouth, ME 04105
> > (401) 284-1827 Business
> > http://www.teraspeed.com
> >
> >
> > On Thu, Sep 4, 2014 at 9:25 PM, Alfred P. Neves <al@xxxxxxxxxxxxxxxxx>
> > wrote:
> >
> >> Usually causality/passivity issues are due to inadequate samples in the
> >> VNA, high group delay noise, poor calibration methodology, and possibly
> old
> >> cables with adapters. The new VNA's are much better with respect to
> >> causality because they RX hgas a lot less group delay noise, and most of
> >> the algorithms label group delay noise as a causality issue. Also,
> >> adapters create a lot of problems, so we don't use them.
> >>
> >> We never force causality and only accept minor passivity and causality
> >> issues for short, low-loss interconnects.
> >>
> >> The data we have collected suggests that most causality enforcement in
> the
> >> EDA packages mangles the S-parameter completely. If you disagree, feel
> >> free to present the data. WRT presented comparison of causality fixes
> in
> >> last years DesignCon tutorial that is on our website. Accordingly,
> after
> >> we deem the S-parameters have adequate causality and overall quality we
> >> establish rational compact model or some other form of polynomial fit.
> >>
> >> We are also finding there is major issues with good S-parameters after
> >> de-embedding. Start with a perfect causal and passive S-parameter and
> >> de-embed it with S-parameters derived from simple passive synthesized
> >> networks and you often have a non-causal S-parameter with poor symmetry.
> >> WRT has been working with Keysight and Simbeor and investigating these
> >> issues and will be presenting our data in a tutorial at DesignCon
> (possibly
> >> if accepted).
> >>
> >> - Al Neves
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Products for the Signal Integrity Practitioner
> >>
> >>
> >>
> >> Alfred P. Neves
> >> Chief Technologist
> >>
> >>
> >>
> >> Office: 503-679-2429
> >>
> >> www.wildrivertech.com
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> On Sep 4, 2014, at 5:18 PM, David Vye <david.vye@xxxxxxxxx> wrote:
> >>>
> >>> Cascading s-parameters is fairly straight forward for most EDA tools.
> You
> >>> need to be concerned with the source of the s-parameters (modeled or
> >>> measured) and the accuracy with which they were derived. If your
> >> analyzing
> >>> them in the time domain, you will also want tools that enforce
> >>> causality/passivity.
> >>> This link covers some of the basics regarding requirements for using
> >>> s-parameters in time domain simulations.
> >>
> http://space.ednchina.com/Upload/2009/6/3/0a40b853-3b4a-42d3-820e-67241743cd1d.pdf
> >>>
> >>> BEst,
> >>>
> >>> David
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Sep 4, 2014 at 3:25 PM, Muranyi, Arpad <
> Arpad_Muranyi@xxxxxxxxxx
> >>>
> >>> wrote:
> >>>
> >>>> Eric,
> >>>>
> >>>> S-parameter data is made up of complex numbers, so phase information
> >>>> (delay) is in there.
> >>>>
> >>>> Theoretically you can cascade (connect in series) S-parameter blocks
> >>>> but there are things to watch out for when you do that. As a user
> >>>> you can't do much about it, this is more of an EDA vendor thing. I
> >>>> would highly recommend my employer's product, HyperLynx, which has a
> >>>> lot of good features and capabilities with S-parameters.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Arpad
> >>>>
> =====================================================================>>
> >>>> -----Original Message-----
> >>>> From: si-list-bounce@xxxxxxxxxxxxx [mailto:
> si-list-bounce@xxxxxxxxxxxxx
> >> ]
> >>>> On Behalf Of eric silist
> >>>> Sent: Thursday, September 04, 2014 2:06 PM
> >>>> To: si-list@xxxxxxxxxxxxx
> >>>> Subject: [SI-LIST] timing in s-parameters
> >>>>
> >>>> I know in a simple way that S-parameters are a frequency domain
> >>>> representation of how much of the signal passes through or is
> reflected.
> >>>> Then I have the idea that I could use a tool to extract an
> S-parameters
> >>>> representation of a bus and simulate that in the time domain with
> >> h-spice
> >>>> or some other tool.
> >>>> I don't understand how delay information is derived from the data in a
> >>>> s-parameter model? Or is it not and a simulation like I describe
> above
> >>>> will just assume that all channels have the same delay. I thought
> >> maybe
> >>>> there would be some phase information in the s-parameter model but I
> >> didn't
> >>>> see that in the touch tone file format.
> >>>>
> >>>> I'm also curious if I wanted to combine several sparameter models,
> say a
> >>>> package model, channel model, connector model etc. Are there
> pitfalls
> >>>> (like resonant spikes or something) to watch out for if I just hook
> them
> >>>> all up in series? Should I be doing something more complicated to
> >> combine
> >>>> them?
> >>>>
> >>>>
> >>>> Thank you,
> >>>> -Eric
> >>>>
> >>>>
> >>>> ------------------------------------------------------------------
> >>>> 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
> >>
> >>
> >> ------------------------------------------------------------------
> >> 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:
