Logic Instruments Tackle Troubleshooting

To that end, you can select from a wide range of multichannel instruments that can generate test data that you can apply to your designs as well as from logic-analysis equipment that can measure your circuit’s response. Figure 1 illustrates the spectrum of available instruments (the product survey chart lists companies that manufacture such instruments).

Getting a Data Snapshot
To uncover erratic performance, you need to capture a window of UUT data—a snapshot of circuit-state or timing data that can help you determine why a digital circuit behaves in a certain way. At the red end of Figure 1’s spectrum, general-purpose logic analyzers allow you to specify the width and depth of the data window you capture—the width being the number of points captured simultaneously, and the depth being the total time slice that the captured data represents. Shift toward the blue end of the figure, and you’ll find instruments tailored for specific, standards-based types of hardware—gigahertz-rate communications links, for example, or protocol-specific avionics or PC buses. These instruments often condense accumulated data into a single spec—an error rate or a simple pass/fail indication.

If you want more than a pass/fail indication or a single numeric spec, you’ll need a way to interpret the information your instrumentation provides. Most logic analyzers combine two instruments: a state analyzer and a timing analyzer. The timing analyzer approximates an oscilloscope’s time-interval-measurement capabilities. The state analyzer provides the type of information you would expect to see in a well-behaved, clock-driven sequential digital UUT—logic ones and zeros; it does not show glitches, clock skew, or path delays.

State analyzers often can display state information as square-wave patterns representing ones and zeros. This approach can be misleading in that it might suggest to an oscilloscope expert but logic-analyzer novice the presence of timing information that’s not really there. Detailed timing information is available only in timing mode. In state mode, the logic traces represent signals that get sampled once per UUT synchronous clock cycle. The state analyzer provides no information about channel-to-channel timing skew (unless it’s sufficiently severe to generate false states) or glitches that can suggest marginal designs that will intermittently fail in the field.

Figure 1. Logic troubleshooting tools range from protocol-specific instruments to general-purpose pattern generators and logic analyzers that can exercise complex designs. In some instances, you might simply want to start running a problem-prone digital subsystem and record its activity surrounding a trigger event such as a circuit shutdown. In other instances, you’ll want to exercise a UUT using patterns you have generated manually or have derived from design data.

Figure 2 illustrates how state and timing analyzers measure logic signals that exhibit pesky analog behavior. In this simple example, a rising edge on the synchronous clock signal initiates state changes in a sequential-logic UUT, with inputs A and B and output C. The new state data from the UUT becomes valid when the synchronous clock returns low (that is, setup time is one-half cycle). The UUT data remains valid for as long as the clock stays low (that is, hold time is one-half cycle). A rising edge on the asynchronous clock triggers sampling of the A, B, and C signals at the logic analyzer.

Note that initially, channels A and B are high, and channel C, the exclusive-OR of A and B, is low. The logic-analyzer timing and state indicators both reflect this 1-1-0 sequence. If the sequence represents the instruction bus of an arithmetic-logic unit in a microcontroller, the state analyzer might disassemble 1-1-0 into a mnemonic such as shift_left_ac.

When the synchronous clock rises, both A and B begin to fall, with A crossing threshold voltage V_T 0.5 ns before B does. This difference results in a 0.5-ns wide pulse on C.

Note that the state analyzer has nothing to say about this transition period—it speaks only for the data-valid periods highlighted in yellow in Figure 2. The timing analyzer does describe this period. When the asynchronous clock rises at 2.75 ns, A has already fallen below V_T, so the timing analyzer reports a high-to-low transition for channel A. Similarly, the pulse on C is high when the asynchronous clock rises, so the timing analyzer reports a low-to-high transition for C at 2.75 ns. Channel B’s transition lags A’s by only 0.5 ns, but it’s not sampled until 0.75 ns after its actual transition, and the timing analyzer reports a 1-ns total delay between A and B plus a 1-ns pulse
on C.

Figure 2. Logic analyzers can employ a two-clock approach to derive state and timing information. A synchronous clock from the UUT defines the time slice (highlighted in yellow here) during which state data is valid; an analyzer-generated, higher-frequency asynchronous clock pinpoints transition times and detects glitches.

Just as in digital oscilloscopes, the timing accuracy of a timing analyzer depends on the sampling frequency of your timing analyzer’s internal clock. The clock of your UUT determines the required speed of your state analyzer—100 MHz for a 100-MHz system. You might, however, choose a timing analyzer whose asynchronous clock runs up to 20 times faster—2 GHz for a 100-MHz UUT.

Special Considerations
When choosing a logic analyzer, you’ll need to consider aspects of your design that go beyond the simple example of Figure 2. For instance, you’ll need considerable memory depth if you want to record the entire boot sequence of a typical Intel processor running Windows. Even if you don’t need that extreme, you should note that your depth requirements may be greater than what you might first estimate.

Suppose you want to capture signals for a few cycles before and after your processor executes a particular instruction. You can trigger your analyzer when that instruction reaches the processor pins, but keep in mind that the instruction may hide within the processor’s internal pipeline for several cycles before it executes (if in fact it ever does). When selecting depth, you’ll need to account for time in the pipeline as well as the cycles of interest. Alternatively, you can employ an instrument with a trigger-offset function, which inserts a delay of a selectable number of UUT clock cycles between detection of the trigger condition and actual data capture.

If you are employing multiplexed address and data buses, you will want an analyzer that can decode data and addresses based on your UUT clock plus address-valid and data-valid signals. If your design employs multiple levels of logic power supplies, you might consider an analyzer that allows you to independently set threshold levels on different sets of inputs.

Finally, you’ll have to consider how to stimulate the UUT so it generates meaningful data that you can capture and analyze. If you’re evaluating a communications channel, you might employ a pattern generator to produce a pseudo-random bit sequence, and you can use an analyzer to see how well the channel transmits that sequence. If you want to capture data when your UUT processor executes a certain instruction, you might just push the start button and let the UUT run until that instruction surfaces.

If you are working on a multiple-chip design and awaiting the arrival of an ASIC, you can use a pattern generator to simulate the missing ASIC, letting you get started with hardware-prototype debug. You can develop the required patterns manually, or you can select software tools to convert the design files of your missing ASIC into data for your pattern generator.

Adapting Your Instrumentation
Ultimately, you might find that commercial instrumentation just doesn’t meet your UUT’s bandwidth needs. In this case, you can work with logic-analyzer vendors to develop custom multiplexer circuits that let you acquire high-speed data at the expense of memory width. Or, you might believe you need more types of instrumentation than you can afford. Rather than buy a bunch of specialized bit-error-rate testers, bus analyzers, and other instruments to complement your general-purpose logic analyzer, you might be able to adapt your logic analyzer to specific tasks.

For example, you can use some multichannel logic analyzers to capture data from a serial port such as the USB, with the logic analyzer converting the serial data stream into parallel state information. That’s overkill, but if you have the logic analyzer, you save the cost of a dedicated USB analyzer. In addition, you can buy adapters that convert general-purpose logic analyzers into bus-specific analyzers.

As digital design speeds and complexity increase, you’ll increasingly rely on such tricks to adapt your instruments to your performance needs without breaking the bank. Careful consideration of your immediate and long-term needs can help you choose cost effectively from among the spectrum of general-purpose and product-specific instruments and options. T&MW

FOR FURTHER READING

“8 Hints for Solving Common Debugging Problems with Your Logic Analyzer,” Application Note 1326, Agilent Technologies, Palo Alto, CA, 1999. literature.agilent.com/litweb/pdf/5968-5700E.pdf.

“Using Deep Memory to Find the Cause of Elusive Problems,” Application Note, Tektronix, Beaverton, OR, 1999. www.tek.com/Measurement/App_Notes/mustang/eng.