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