From: Scott McMorrow ([email protected])
Date: Fri Jan 14 2000 - 13:53:06 PST
Michael,
I have found several areas of errors.
1) Certain simulator algorithms, such as the Hspice W-element,
have errors which accumulate when multiple trace segments are
simulated. These errors are due to the approximations being
used in the algorithm and can be seen with a simple experiment.
Create a circuit with a simple voltage source with 50 ohm
source impedance and attach it to a line with frequency dependent
losses that is one meter long. Terminate it at the end to 50 ohms at
half the voltage swing. Then break up the w-element line into
100 segments and perform the same simulation. Most likely you will
see about a 50 ps difference in delay. If simulated at a time step
of 1 ps the w-element will have about a 0.5ps error per cascaded
section. If you remove the frequency dependent Rs and Gd, then
you will see no difference between either the 1 section or the
100 section simulations.
2) Approximations used in the extraction of trace environments from
PC boards can contribute to cumulative errors, especially in coupled
transmission lines. When the resolution of the extraction is too high,
the minimum segment length used in a trace extraction can be too small
to be appropriately extracted. In this case the algorithm can either:
a) lump the small section into another section.
b) ignore the small section.
c) increase the small section to the step size.
Options b) and c) introduce errors. However, option a) can also introduce errors
when coupling is considered. Take the case of two coupled differential
pair transmission lines. At a 45 degree bend there is a question about what is
really coupled to what and where. The actual situation is quite complex. What we
really have are non uniform transmission lines at the bend. However, this is
usually modeled as a coupled section, followed by an uncoupled
section, followed by another coupled section. The uncoupled section is placed
on the trace at the outside of the bend radius, since it is the longer trace. This will
correctly model the increased delay in the trace at the outer bend radius of the
differential pair. If we now zag the trace -45% the same conditions occur, but the
other trace of the diff pair is now the outer trace and so the extra lump needs to
be placed on it. It is not uncommon for this selective lumping to be performed
incorrectly. Also, since these sections have extremely small dimensions they are
usually under the resolution of the extraction step size (or bandwidth, if you will).
Then there is a question about what to do with this tiny section. Does it get
added to one of the coupled traces?
If you extend this to highly coupled systems (like pcboards) with 2, 3, 4, 5 ... adjacent
coupling neighbors, you can see that the algorithmic decision on how to extract
and model traces is an interesting one. Each error in modeling coupling segments
becomes a cumulative one. In a particular differentially branched clock trace that
I am working with, I can count 305 individual extracted trace segments at a resolution
of 1 ps. It wouldn't take much error per segment here to cause a large delay
variation from the actual. I am now in the process of determining what is "real"
and what is "Memorex".
3) There are, of course, also inaccuracies in LC based simulation methods.
Here we model the continuous system of fields with a lumped approximation.
The approximation accuracy is related to the size increment of the lumped
elements. The U-element is an example where we can increase the number
of lumps to increase the accuracy ... with a sacrifice in simulation performance
(and sometimes stability.) Ultimately the issues are the same as in 2) above.
If our LC lump is too large (or has too low a bandwidth) then we introduce errors
in simulations of cascaded systems. If our extraction LC lump is too large, then
it becomes an algorithmic decision about how to handle board features smaller
than the lump. What works in the frequency domain will not necessarily work
accurately in the time domain and vice versa. With board feature sizes decreasing,
it is very easy to extract garbage without knowing you have done so.
I hope this long winded explanation answers your question.
regards,
scott
-- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.comMichael Vrbanac wrote:
> Scott, > > What you have commented on may explain some of the frequency > domain "distortions" that I note from time to time but haven't dug into > it fully to find out. > > I have a question re: "I have also seen simulation algorithms which > show cumulative error when the number of individual trace segments > is large, as is the case with most signal traces on PCB's." > > Why do you suppose that is? Do you think it is because of the > cumulative errors in the segments or is it something else like > increase in simulation errors in bends (90deg or not) which have > increased in count... or both/none? > > Michael > > Scott McMorrow wrote: > > > Doug, > > > > I always start with basic theoretical structures for simulator testing. > > You'd be surprised just how many simulators and algorithms have > > dc offset errors when simulating lines with losses. Like you, I can > > calculate the proper results by hand. > > > > I find that often errors are not so much in the simulator as they > > are in the method of parameter extraction and approximation of > > elements in the system. > > > > Comparing simulator results to measured data is not a very > > accurate science unless you have previously characterized the > > simulator in a theoretical environment and therefore trust it's > > basic correctness. Then, the next layer of the puzzle becomes > > verifying the parameter extractor and trace modeler, which is > > a bit tricky ... especially if you are looking for timing accuracy > > of less than 10 ps. I have found parameter extraction and trace > > modeling algorithms which create networks which have > > cumulative error across multiple cascaded trace segments. > > I have also seen simulation algorithms which show cumulative > > error when the number of individual trace segments is large, as > > is the case with most signal traces on PCB's. > > > > Then comes the case of validating a know theoretically good > > simulator, parameter extractor, and trace modeler to reality. > > Yuck! Of course, first one must verify all parameters in the > > target real design, which is not a simple task. But that is another > > long story best left for other days. > > > > regards, > > > > scott > > > > -- > > Scott McMorrow > > Principal Engineer > > SiQual, Signal Quality Engineering > > 18735 SW Boones Ferry Road > > Tualatin, OR 97062-3090 > > (503) 885-1231 > > http://www.siqual.com > > > > Doug Smith wrote: > > > > > Hi All, > > > > > > I am interested in ways that people use to verify simulation results, > > > that is to check that the results reflect reality. In the past, I have > > > built up similar, but simple enough to calculate or build, structures > > > and made sure the simulator agreed with what I measured/calculated by > > > hand. Sometimes, I have also looked at the convergence history of some > > > of the requested output. Occassionally, a simulator would produce an > > > answer that was not properly converged. Seems like is a good idea to > > > know beforehand the general nature of the answer so you know when the > > > simulator is not working as expected. > > > > > > What other techniques have been used? Any war stories out there? > > > > > > Doug > > > > > > -- > > > ---------------------------------------------------------- > > > ___ _ Doug Smith > > > \ / ) Manager EMC Development & Test > > > ========= Auspex Systems > > > _ / \ / \ _ 2300 Central Expressway > > > / /\ \ ] / /\ \ Santa Clara, CA 95050-2516 > > > | q-----( ) | o | Phone/FAX: 408-566-2157/2020 > > > \ _ / ] \ _ / Email: [email protected] > > > ---------------------------------------------------------- > > > > > > **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. > > > si-list archives are accessible at http://www.qsl.net/wb6tpu > > > **** > > > > **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. > > si-list archives are accessible at http://www.qsl.net/wb6tpu > > **** > > **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. > si-list archives are accessible at http://www.qsl.net/wb6tpu > ****
**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu ****
This archive was generated by hypermail 2b29 : Thu Apr 20 2000 - 11:34:39 PDT