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