Planning for Signal Integrity
Today's advanced digital products are built using PCI, GTL, BTL, and other popular high-performance bus driver chips designed to run at 33, 66, 100-MHz or more. These products are fast. It takes planning, experience, and more than a little lab work to get digital designs to work with such fast parts. At these extremes of speed, even simple problems, like ringing, can become complex. For example, a typical 3.3-V gate does not need a terminator to drive a 2-inch unloaded trace. The results just naturally work out all right (see the Figure 1 CL=0).
Figure 1—Increased ringing due to capacitive loading
But, add a single 5-pF load to the end of that same trace and it will begin to ring violently, taking an extra 2 ns to settle to within acceptable voltage margins after each transition. Is that kind of extra time built into your timing calculations? Nowadays, it had better be. Capacitive loading can sometimes (but not always) markedly worsen ringing and settling problems on unterminated lines.
If you are trying to cut it close with logic timing (and who isn't), loading effects like this can really ruin your day. To get some help, check out the nifty new simulation tools now available for dealing with signal integrity problems.
The basic assumption with all computer simulations is this: If you can develop a simulation method that has good correlation to the real world, then you can use it to simulate your pc-board trace layouts before you build them. And what's more, you can make the computer check every single trace, with every combination of worst case loads, which is something most of us don't have the time to do in the lab. With the right software, a computer can debug a whole month's worth of signal integrity problems without ever committing to a pc-board's fabrication cycle. Of course, the key to this whole approach is a good correspondence between your simulator and the real world.
Presently, there are (at least) three approaches to signal integrity simulation:
- General-purpose Mathematical calculation environments, like MathCad, Mathematica, and Matlab.
- Analog simulation tools, like Spice, HSPice, and Pspice.
- Specialized signal integrity simulators, like HyperLynx, Cadence, Mentor/Interconnectix, and View Logic/Quad Design.
General-purpose mathematical calculation tools will let you mix together pictures, equations, and explanatory text in the same document. Using their general-purpose math libraries, it is possible to simulate the performance of practically any digital transmission structure.
Especially good for long-distance LAN communication problems involving frequency-dependent losses (like the skin effect) the flexibility of these tools is invaluable. They also have the advantage of being able to simulate a great number of different worst-case scenarios, including random topologies, peculiar noise sources, and various flavors of crosstalk.
The biggest disadvantage to the general-purpose tool approach is the degree of customization required to model any particular problem. If you do the customization yourself, it probably won't have much of a user interface. It may also be extremely awkward to import your trace layout database and work with it. 'Nuff said.
Traditional analog simulation tools can adequately simulate the most common digital scenarios. Spice, HSpice, PSpice, and all the other Spice variants have good models for handling simple loss-less, distortion-less transmission lines. These models are appropriate for simulating ordinary printed circuit boards with only a few traces. One nice advantage of working with analog simulation tools is that many of them have a good GUI front-end, with schematic capture capability. That lets you draw a pictorial representation of your circuit, double-check the drawing to make sure it's right, and then submit the completed circuit to the simulator. The pictorial process cuts down on errors.
Spice works exceptionally well when you have good circuit models of both the transmitter and receiver circuits. Its prediction of overshoot and ringing waveforms are surprisingly accurate, given good enough models. The biggest drawbacks to using Spice are that it has no provision for importing a trace layout database, and it has no general way to properly assess crosstalk on your layout.
Specialized signal integrity tools attack the trace simulation problem from two new angles. First, they use IBIS models for the driver and receiver. The IBIS models specify, for each driver, a V-I curve to be used in the low state, a V-I curve to be used in the high state, and a finite speed at which the driver transitions from one curve to the other. This arrangement is not perfect, but it's definitely useful. Second, they offer a compact, user-friendly interface, optimized for signal integrity work. The user interfaces for most signal integrity tools provide for "what-if" operation and "post-processing" operation.
In the "what if" mode, a digital engineer can sit down, punch in a topology, and get a quick feel for how a design will perform. That's the forte of tools like HyperLynx and the Mentor/Quad Design package called Preview.
In the "post-processing" mode, the software scans your layout database to extract the relevant topological information, picks up an appropriate set of IBIS models from the component database, and then simulates every net, when driven from every possible source. Ringing in excess of desired specifications (as assigned by net class) for any net is flagged for the user's attention. Mentor/Interconnectix, Cadence, View Logic, and others all have this.
The Mentor/Interconnectix tool goes one step further than the others. It actually adds terminators to fix broken nets, re-simulates them to verify compliance with specifications, and then generates change files as needed to show the additional parts. Pretty neat stuff. Of course, the problem with this level of automation is that the raw source information that you type into the system (that is, the IBIS models, the ringing specifications, and the allowed terminator topologies) must be 100% correct for the system to function properly. As with any CAD automation tool, the quality of your library determines the quality of the final result.
Whatever method you choose, start simple and keep it closely tied to physical reality. Try simulating one lowly NAND gate driving a 10-inch unterminated line, and check to see if your results match what you see on the bench. If there are discrepancies, work on the simulator (or your probing technique) until they match. If you are working with logic as fast as 1 ns, your model will need to include packaging parasites (IBIS can do that). As your confidence with the simulator increases, branch out to more complex topologies.
Periodically, return to the bench for corroboration. Remember, simulation is always fun, but it's only helpful if you are sure the simulator matches what's really going on in your design.