[SI-LIST] Re: (no subject)
- From: "Raj Raghuram" <raghu@xxxxxxxxxxx>
- To: "Yu Liu" <yu_liu@xxxxxxxxxxxxx>
- Date: Wed, 11 Dec 2002 18:43:05 -0800
Yu,
Actually we are in agreement. Simulation of s-parameters in the time domain
can be tricky and all the more reason for the kind of verification I
proposed.
The check is only the first step towards a more complex simulation with
on-chip and off-chip elements. If we fail the simple check, we cannot trust
the results of the more complex simulation.
Best Regards,
Raj Raghuram
Sigrity, Inc.
"Achieve what others can't"
raghu@xxxxxxxxxxx
http://www.sigrity.com
4675 Stevens Creek Blvd. , Ste 130
Santa Clara, CA-95051
PH: 408-260-9344 x116
CELL: 408-390-7614
FAX: 408-260-9342
> -----Original Message-----
> From: Yu Liu [mailto:yu_liu@xxxxxxxxxxxxx]
> Sent: Wednesday, December 11, 2002 6:14 PM
> To: raghu@xxxxxxxxxxx
> Cc: si-list@xxxxxxxxxxxxx
> Subject: Re: [SI-LIST] Re: (no subject)
>
>
> Hi, Raj,
>
> Let me rephrase the question: Suppose you use the average error criteria
> in the curve fitting, then there could be large errors at local parts
> even though the overall error is small. If the transient simulation
> happens to use just the large error part in the frequency domain (one
> worst-case would be a single frequency signal at the large error point),
> the results would generate large errors in time-domain. And in addition,
> maybe you could give us a rough idea about the complexity of the
> technique (number of states/elements vs frequency viriations)?
>
> The fairly easy S-parameter check is a good way to check the
> implementation. However, it is not the goal of what people want. In the
> end, any technique is rendered useful only when it can perform close to
> real-case simulations. In this case, it means combining the on-chip and
> off-chip circuits and generating close-to-measurement eye-patterns.
>
>
> Best Regards,
>
> Yu
> ===
>
> Apache Design Solutions
> 1881 Landings Drive
> Mountain View, CA 94043
> Tel: (650)237-5410
> Fax: (650)969-4170
> Email: yu_liu@xxxxxxxxxxxxx
> web: www.apache-da.com
>
>
> Raj Raghuram wrote:
>
> > Yu,
> >
> > Your point about verification was the one I wanted to make in the first
> > place. When you extract a model, you can run a time domain
> simulation and
> > verify through Fourier Transforms (as I originally described)
> that you are
> > able to get back your original S-parameters. When you directly do a time
> > domain simulation with various other circuit elements
> connected, there is no
> > way to ensure that the internal representation used in the
> simulator for the
> > s-parameters is accurate.
> >
> > Best Regards,
> >
> > Raj Raghuram
> > Sigrity, Inc.
> > "Achieve what others can't"
> > raghu@xxxxxxxxxxx
> > http://www.sigrity.com
> > 4675 Stevens Creek Blvd. , Ste 130
> > Santa Clara, CA-95051
> > PH: 408-260-9344 x116
> > CELL: 408-390-7614
> > FAX: 408-260-9342
> >
> >
> >
> >>-----Original Message-----
> >>From: Yu Liu [mailto:yu_liu@xxxxxxxxxxxxx]
> >>Sent: Wednesday, December 11, 2002 2:40 PM
> >>To: raghu@xxxxxxxxxxx
> >>Cc: si-list@xxxxxxxxxxxxx
> >>Subject: Re: [SI-LIST] Re: (no subject)
> >>
> >>
> >>Hi, Raj,
> >>
> >>Thanks for the explanation - I hope there is less than 400,000 elements
> >>needed to model a 2-port S-parameter network, just like Steve Corey's
> >>-good- compression tool does, although my original post does not mean
> >>for a 2-port.
> >>
> >>However, one can't help to raise the question about the rational
> >>function fitting techniques: When your data does not have a smooth
> >>variation, how many orders are needed for a certain accuracy? What
> >>is the complexity of the technique (order/state-variable vs
> "variation")?
> >>
> >>Also, assuming the fitting is performed in frequency domain, how is the
> >>frequency fitting going to affect the accuracy in time-domain? In other
> >>words, a fitting may look very "good" in frequency domain, how would one
> >>know it will be accurate for transient response?
> >>
> >>Best Regards,
> >>
> >>Yu
> >>===
> >>
> >>Apache Design Solutions
> >>1881 Landings Drive
> >>Mountain View, CA 94043
> >>Tel: (650)237-5410
> >>Fax: (650)969-4170
> >>Email: yu_liu@xxxxxxxxxxxxx
> >>web: www.apache-da.com
> >>
> >>
> >>Raj Raghuram wrote:
> >>
> >>
> >>>Yu,
> >>>
> >>>The calculation that 400,000 circuit elements are needed to
> >>>
> >>represent 2-port
> >>
> >>>S-parameters is misleading and here is why. The number of
> >>>
> >>circuit elements
> >>
> >>>needed to represent the frequency variation of one of the
> >>>
> >>S-parameters is
> >>
> >>>usually not anywhere near the number of frequency points. The
> >>>
> >>fit is done
> >>
> >>>using rational functions and the order of the rational function
> >>>
> >>is far less
> >>
> >>>than the number of frequency points. If you have a smooth variation, a
> >>>relatively low order transfer function would do the job.
> >>>
> >>Assuming 10th order
> >>
> >>>rational functions, the number is closer to 40 i.e you have 40 state
> >>>variables.
> >>>
> >>>Best Regards,
> >>>
> >>>Raj Raghuram
> >>>Sigrity, Inc.
> >>>"Achieve what others can't"
> >>>raghu@xxxxxxxxxxx
> >>>http://www.sigrity.com
> >>>4675 Stevens Creek Blvd. , Ste 130
> >>>Santa Clara, CA-95051
> >>>PH: 408-260-9344 x116
> >>>CELL: 408-390-7614
> >>>FAX: 408-260-9342
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: si-list-bounce@xxxxxxxxxxxxx
> >>>>[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Yu Liu
> >>>>Sent: Tuesday, December 10, 2002 7:21 PM
> >>>>To: si-list@xxxxxxxxxxxxx
> >>>>Subject: [SI-LIST] Re: (no subject)
> >>>>
> >>>>
> >>>>
> >>>>Hi,
> >>>>
> >>>>I agree with Raj that mixed-domain simulation is a challenging job.
> >>>>
> >>>>However, the fairly easy S-parameter checker as proposed only reflects
> >>>>an idealized linear situation. In real applications, people
> combine the
> >>>>nonlinear circuits (e.g. on chip Tx/Rx) with linear parts
> (e.g. off-chip
> >>>>packages/FR-4),(see the following figure), and perform transient
> >>>>simulation and generate eye-patterns. For Multi-Gbps applications, the
> >>>>integrated SPICE approach seems to be the only viable method.
> >>>>
> >>>> +------------+
> >>>> +----+ +---+ | BackPlane | +---+
> +----+ ______
> >>>> PRBS>----| Tx |---|Pkg|---| |---|Pkg|---| Rx | / \
> >>>> >----| |---| |---| FR-4 |---| |---|
> | _\__/_
> >>>> +----+ +---+ | | +---+ +----+
> >>>> +------------+
> >>>>
> >>>>
> >>>>As for the first proposed approach, let's suppose you have a 2-port
> >>>>S-parameter data. For each frequency, there are four things
> you need to
> >>>>model: reflection at both ports, as well as forward/reverse
> >>>>transmission. Suppose you need one element for each parameter (there
> >>>>could be more), then there would be four elements. And
> suppose there are
> >>>>1000 frequency points, then the total number of elements will be 4000.
> >>>>
> >>>>Now suppose you need to model a 20-pin connector, with 1000 frequency
> >>>>points, you would need 400,000 elements (could be more) to describe
> >>>>the whole S-parameter data. So the computer resource is quite
> demanding.
> >>>>Yes, you can look at those elements. But how are you going to
> handle any
> >>>>deficiencies in program generated elements when they are beyond the
> >>>>users control?
> >>>>
> >>>>In the integrated SPICE approach, which is the (2) proposed from Raj's
> >>>>post, no matter how many ports you have, and how many frequency
> >>>>points there are, you just need one element in your netlist. You don't
> >>>>go through the lengthy model generation/curve fitting/optimization
> >>>>procedures. And the user retains full control of the DC
> >>>>S-parameter values.
> >>>>
> >>>>--
> >>>>
> >>>>Best Regards,
> >>>>
> >>>>Yu
> >>>>===
> >>>>
> >>>>Apache Design Solutions
> >>>>1881 Landings Drive
> >>>>Mountain View, CA 94043
> >>>>Tel: (650)237-5410
> >>>>Fax: (650)969-4170
> >>>>Email: yu_liu@xxxxxxxxxxxxx
> >>>>web: www.apache-da.com
> >>>>
> >>>>
> >>>>Raj Raghuram wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Mick, Ege, Hassan, and others,
> >>>>>
> >>>>>As mentioned, there are primarily two approaches to do SPICE
> >>>>>
> >>>>>
> >>>>type transient
> >>>>
> >>>>
> >>>>>simulations for components described in S-parameters.
> >>>>>
> >>>>>(1) Convert S-parameters to certain forms, either
> >>>>>
> >>equivalent circuit
> >>
> >>>>>representations or certain table lookup format, from which
> >>>>>
> >>>>>
> >>>>SPICE engines can
> >>>>
> >>>>
> >>>>>read and run.
> >>>>>
> >>>>>(2) Enable a SPICE solver to read S parameters directly. The
> >>>>>
> >>>>>
> >>>>SPICE solver
> >>>>
> >>>>
> >>>>>will then internally do the things in (1), or do convolution
> >>>>>
> >>>>>
> >>>>directly which
> >>>>
> >>>>
> >>>>>can be quite demanding for computer resources for large
> number of such
> >>>>>circuit components.
> >>>>>
> >>>>>While it may appear more attractive to have the time domain circuit
> >>>>>simulator directly read in and use the S-parameters,
> >>>>>
> >>deficiencies in the
> >>
> >>>>>representation used are not then easily seen. Often the original
> >>>>>S-parameters or the circuit model representing them may not
> be stable,
> >>>>>causal, and passive. Also, extrapolation of the S-parameter
> >>>>>
> >>>>>
> >>>>data to DC is
> >>>>
> >>>>
> >>>>>often a problem and separate DC values may be needed.
> >>>>>
> >>>>>It is technically very challenging to have accurate and
> >>>>>
> >>>>>
> >>>>reliable transient
> >>>>
> >>>>
> >>>>>simulations from S-parameters of complicated responses. There
> >>>>>
> >>>>>
> >>>>are quite a
> >>>>
> >>>>
> >>>>>number of tools out there. A tool that is claimed to have such a
> >>>>>capability, either through (1) or (2), does not necessarily
> >>>>>
> >>>>>
> >>>>mean it can do a
> >>>>
> >>>>
> >>>>>good job.
> >>>>>
> >>>>>One of the major issues, in time domain simulations by a
> SPICE circuit
> >>>>>solver, is whether the circuit really behaves in the way it
> >>>>>
> >>>>>
> >>>>should behave,
> >>>>
> >>>>
> >>>>>as characterized by its original S parameters.
> >>>>>
> >>>>>Here is a way to check whether the tool really does the job it
> >>>>>
> >>>>>
> >>>>is supposed
> >>>>
> >>>>
> >>>>>to do. Assume you have a two-port circuit described by S
> parameters.
> >>>>>You have a SPICE equivalent circuit of the two-port network or
> >>>>>
> >>>>>
> >>>>your solver
> >>>>
> >>>>
> >>>>>can directly read-in S parameters. Connect port one with a
> >>>>>
> >>>>>
> >>>>time-varying
> >>>>
> >>>>
> >>>>>voltage source Vs(t) and a 50 ohm resistor, connect port 2 with a 50
> >>>>>resistor as shown in the following graph. Run the SPICE
> >>>>>
> >>>>>
> >>>>engine to get the
> >>>>
> >>>>
> >>>>>transient voltages V1(t), V2(t) and Vs(t).
> >>>>>
> >>>>> 50 ohms --------------
> >>>>> |-------| | |
> >>>>> |-----| |------o| |------|
> >>>>> | |-------| + | | + |
> >>>>> --- | | ---
> >>>>>Vs(t)|+| V1(t) | |V2(t)| | 50 ohms
> >>>>> |-| | | | |
> >>>>> --- - | | - ---
> >>>>> |--------------------o| |------|
> >>>>> ----- | |
> >>>>> --- --------------
> >>>>> -
> >>>>>
> >>>>>Take Fourier transforms of Vs, V1 and V2; then the S
> parameters of the
> >>>>>two-port circuit can be extracted as follows:
> >>>>>
> >>>>> S11 = (V1(f)-Vs(f)/2)/(Vs(f)/2)
> >>>>> S21 = V2(f)/(Vs(f)/2)
> >>>>>
> >>>>>One can find S22 and S12 in a similar way by moving Vs to port 2.
> >>>>>
> >>>>>The S parameters extracted from the above procedure represent
> >>>>>
> >>the actual
> >>
> >>>>>S-parameters of the two-port circuit in transient simulations;
> >>>>>
> >>>>>
> >>>>the amount of
> >>>>
> >>>>
> >>>>>their deviation from the original S-parameters reflects how
> >>>>>
> >>>>>
> >>>>accurate the job
> >>>>
> >>>>
> >>>>>is done.
> >>>>>
> >>>>>The above tests are fairly easy to do with any SPICE solvers.
> >>>>>
> >>>>>
> >>>>I have some
> >>>>
> >>>>
> >>>>>netlist templates available and I would be happy to provide you
> >>>>>
> >>>>>
> >>>>if you are
> >>>>
> >>>>
> >>>>>interested.
> >>>>>
> >>>>>
> >>>>>Best Regards,
> >>>>>
> >>>>>Raj Raghuram
> >>>>>Sigrity, Inc.
> >>>>>"Achieve what others can't"
> >>>>>raghu@xxxxxxxxxxx
> >>>>>http://www.sigrity.com
> >>>>>4675 Stevens Creek Blvd. , Ste 130
> >>>>>Santa Clara, CA-95051
> >>>>>PH: 408-260-9344 x116
> >>>>>CELL: 408-390-7614
> >>>>>FAX: 408-260-9342
> >>>>>
> >>>>>
> >>>>>
> >>>>>------------------------------------------------------------------
> >>>>>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 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 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 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 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 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:
