With higher speeds in today’s digital designs, it’s not uncommon to encounter challenges during board turn on that relate to timing or signal integrity. Most of the work is distinguishing whether it’s a logic problem or a signal integrity problem. Spending too much time sorting out such things can reduce time to market and create even more time pressures when what you’d really like to do is design.

Many designers find a real-time oscilloscope and logic analyzer invaluable when it comes time to turn on, validate, and debug the hardware in their system. But they are often used independently – the oscilloscope for signal integrity or timing issues and the logic analyzer for problems with the logic.

But it turns out that these tools are most powerful when used together. You can significantly reduce debug challenges by taking advantage of tools that automate the integration of scopes and logic analyzers. In this article, we’ll describe these tools and how you can more quickly understand digital design problems by capturing the analog characteristics of key digital signals simultaneously with a functional view.

An Example Situation
Consider a packet communication system where something is going wrong at boot up. This system (shown in Figure 1) should be passing packet data across a serial channel to a monitor, but the data is not being received. We can take a variety of approaches to figure out what exactly is causing the problem.

One approach is to view the condition of state machines in the design using a logic analyzer, with the possibility of seeing some improper states. Another approach is to probe onto the serial channel with an oscilloscope in an attempt to find some improper signals, particularly with respect to signal integrity. The best approach is to use both the oscilloscope and logic analyzer to better understand the exact target condition under which the error is occurring.

When Working Independently
When approaching the problem with a logic analyzer, a number of signals are of particular interest. We will certainly want to see what is happening with the transmit state machine driving packet data generation, along with the data and related transaction IDs . We would probably also like to see what is happening over on the receive side of the design, where packets should be collected. Signals of interest there include the state machine, data received, and acknowledge IDs, which get sent back to the transmitter to let it know that data was received and to keep the data coming.

This design is implemented with a Xilinx® Virtex™-II FPGA, so we have the option to use a measurement core inside the FPGA to move our probe points around to various locations, collecting the data on the Agilent logic analyzer by using the logic analyzer-based FPGA Dynamic Probe application. We use a measurement core with four signal banks and 16 FPGA pins for visibility (Figure 1).

Because the data is not being received, a reasonable starting point is to probe these points of interest, set up the logic analyzer to trigger on anything, and just see what’s happening. The answer is not much. In fact, simply looking at the activity indicators before even taking a trace, it becomes obvious that the transmit state machine is locked up. Acquiring data through bank 0 shows that the state machine is stuck at 01H, the “idle” state, and transaction IDs (TIDs) that should be counting are stuck at 0DH.

If we change our probe points to signals of interest over to the receive side through measurement bank 1, things are hung up there too, at 02H, the receive “idle” state.

Smarter Logic Analyzer Triggering
Now that we know the condition of the transmit state machine once it hung up, we can redefine the trigger point to be not that value, which should allow us to view state machine activity leading up to this hung condition. The acquisition reveals what looks like a normal state machine cycle just before the hang up. Similarly, by switching probe points with the FPGA Dynamic Probe over to the receive side and defining our trigger as not “idle,” there is also a normal state machine progression. So we might try next to come at this problem with the oscilloscope.

The Oscilloscope Insight
A point of particular interest for an oscilloscope measurement is to view activity on the serial channel and look for anything unusual. We saw the serial channel between the transmitter and receiver earlier in Figure 1. Because this link is differential and running at 400 Mbps, we used a 1.5 GHz differential active probe and accessories to let us plug in to the 0.1 inch connectors on the board.

As we attach to this link and get a view of the eye diagram on the data, it looks fine. No glitches, closing eye, or noise. Trying again from boot up, we see a flurry of activity for a second or so where there appear to be unexpected glitches or narrow pulses in infinite persistence mode. Fortunately we can trigger on a narrow pulse, and set up the scope to do that for a more detailed view (Figure 2). The resultant capture upon boot up is a singleshot view of a narrow pulse. This is highly interesting and reveals a definite problem in the system, but we’re still left scratching our head as to what’s going on.

How About a Little Cooperation?
What if we cross-trigger the logic analyzer when we catch this narrow pulse on the oscilloscope? We could see what condition the logic is at when this situation presents itself on the serial channel.

It turns out this is a relatively easy thing to do because of application software in the logic analyzer, enabled by the E5850A time-correlation fixture created to automate the process. By time-correlating the logic analyzer and oscilloscope and pulling the oscilloscope capture into the logic analyzer, we should be able to get a very helpful view to track down the problem.

Time-Correlating the Instruments
Time-correlation is accomplished by double-probing a common reference signal with both the logic analyzer and oscilloscope. Common BNC cables are placed between one instrument’s trigger-out connector and the other instrument’s trigger input. The instruments are also connected together via the LAN, which allows the logic analyzer to control the oscilloscope and pull out its data.

A calibration routine that runs on the logic analyzer makes repetitive measurements in both the “logic analyzer triggers scope” direction and the “scope triggers logic analyzer” direction, to determine the delay in the cross-trigger for each direction. Once these delays are known, they can be applied to the oscilloscope data after importing to the logic analyzer, time-aligning the logic analyzer and oscilloscope data.

A Better Look
Now we’re going to trigger the oscilloscope on the narrow pulse occurring on the serial channel, cross-trigger the logic analyzer, and bring both captured scope and logic analyzer data together on one screen. The goal is to see exactly what state machine activity is occurring inside the FPGA when the narrow pulse happens on the serial channel.

This cross-trigger is set up through the time-correlation application. All we have to set up is the scope trigger on the narrow pulse; the rest is taken care of. Rebooting the system, we observe the capture on the logic analyzer, which fortunately is very revealing. The trigger point for the oscilloscope where the narrow glitch occurs is visible, and we can also see time-correlated to this event the transmit states of the state machine. That actually looks okay.

As we switch over to the “receive” state machine with the FPGA Dynamic Probe, the state machine also looks okay, at least initially (Figure 3). But with a change of time/division for a “macro” view, we see that the state machine stalls 12 packets after the serial channel glitch (Figure 4). The transaction IDs and acknowledge IDs increment for a time, but then stop. That’s not acceptable, and it points to the possibility of invalid data being input to the state machine, somehow related to this narrow pulse on the serial channel.

Time-correlated measurements have helped show that these are interrelated events. The next step would be to isolate which one causes the other – correcting the logic causing a serial channel narrow pulse, or fixing the narrow pulse causing incorrect state machine logic.

Cross-Triggering in the Other Direction
We’ve determined that the first time we have a narrow pulse, it appears that it coincides with problems in our state machines. But does a narrow pulse always exist in the serial channel when the state machines lock up? One approach to determine the answer is to have the logic analyzer cross-trigger the oscilloscope and have the logic analyzer trigger on the lock up.

Fortunately, to switch the direction of the cross-trigger simply requires checking a box in the user interface; the application already has determined the cross-trigger delay from the calibration performed earlier.

Because we know that the receive state machine locks up on a value of 02H (idle) immediately following 10H (TID), we can set up the logic analyzer to trigger when it sees TID, followed by idle for greater than one clock cycle.

Doing this, importing the related scope capture from the serial channel, and making multiple runs, we see that indeed there is a direct relation between the first narrow pulse and the state machines locking. We can search through the serial stream capture on the oscilloscope and find the location of narrow pulses with the E2681A EZJIT jitter analysis software package, validating that there are always multiple narrow pulses in the vicinity of the lock up. We’ve made an important step to narrow down the possible causes of the problem.

Conclusion
With complex interactions between asynchronous digital circuitry and the fast data rates that are susceptible to signalintegrity issues, it makes sense to pair up your logic analyzer and real-time oscilloscope. With the ability to automate the time-correlation of each instrument’s capture to the other and import scope waveforms into the logic analyzer, it becomes much easier to track down elusive cause-and-effect problems, whether the source is logic or signal integrity.

For information about logic analyzers and oscilloscopes from Agilent, visit www.agilent.com/find/logic/ and www.agilent.com/find/scopes/.

Printable PDF version of this article with graphics.  (4/18/05) 255 KB