Mobile technology is clearly a force in the market. Laptop-PC sales have overtaken those of desktops. Compact multimedia devices ranging from DVRs (digital video recorders) to set-top boxes and gaming platforms are now in millions of homes. The Pentium M from Intel, Cell technology from Sony and IBM, and, in the future, Uniphier from Matsushita exemplify the powerful silicon components that are fueling the mobile revolution. Demand for mobile processors such as these, and the end products that use them, makes minimizing time to market an urgent priority.

When designing for mobility, designers must take some unique issues into account. These issues include space constraints due to product miniaturization and the increasing use of low-amplitude/low-power signals to preserve battery life. Mobile products are under constant pressure to deliver more features and more performance, with longer battery life in smaller form factors. Designers are looking for measurement approaches to help them evaluate, validate, and troubleshoot emerging mobile products under crushing time pressure. These approaches must provide state-of-the-art performance and adapt to the special requirements of the mobile platform.

In some functional respects, a measurement or a debugging task on a mobile platform is similar to its desktop counterpart. For examining CPU and bus events, the preferred measurement tool is the logic analyzer. It is the only tool that can acquire the full width of a data stream, map it into a comprehensible format, and display time-correlated results as a binary timing diagram or as a series of states expressed in hexadecimal form. In addition, disassembly tools are available to map the code to even higher level mnemonics. The same logic analyzer serves all digital-acquisition needs, including those of compact and mobile products.

But mobile platforms present a special challenge. They often require the measurement tool to adapt to a cramped, delicate environment that makes difficult demands on the hardware, particularly in regard to signal probing. Designers of mobile platforms can simplify their future troubleshooting work by paying attention to KOVs (keep-out volumes) and the requirements of interposers and midbus probes. The term "KOV" is a simple expression with complex implications for probe design. In the context of practical measurement tools, KOV dictates the allowable size of a probe. Component manufacturers handed down the KOV as a specification to ensure that their sockets have a physical buffer zone or clearance around them. This clearance area guarantees that designers can easily install and remove the device and its heat sink.

A by-product of the KOV guideline is its effect on the size of logic-analyzer probes, which must be small enough to fit the device-under-test socket without violating the KOV. In effect, the entire probe front end must be as small as or smaller than the device itself. The KOV is a defining specification for interposer probes.

Interposer probes typically fit into a socket or a connector to divert signals to a logic analyzer without interrupting the path to the device under test. In the case of a processor-bus interposer, for example, the probe plugs into the CPU's board socket, and the device plugs into a socket on the probe. The interposer must provide a means of attaching a standard heat sink so that the device will operate under normal thermal conditions. Some interposers target use in mobile devices. For example, a probe for SODIMMs (small-outline dual-inline memory modules) commonly finds use in laptops and other compact platforms. This probe provides better signal fidelity than conventional techniques might deliver in densely packed mobile circuits.

In serial-bus architectures, the interposer probe carries the device's signals to a logic-analyzer interface. These interfaces span a range of complexity, depending upon the width, data rate, and protocol of the device under test or bus they are monitoring. The logic-analyzer interface buffers data rates that exceed those of the logic analyzer and fans out serial data to the instrument's innately parallel acquisition channels. If the device under test itself is a parallel device with a compatible data rate, the interface may be unnecessary, but the interposer probe is still essential for accurate signal acquisition.

A midbus footprint is a group of contact pads or a test connector sitting astride a bus trace on the pc board in the middle of the bus. The logic analyzer picks off the signals directly from the trace, gaining the advantages of lower capacitive loading and better signal fidelity. The needs of mobile platforms call for flexibility in probing. The same laptop motherboard may require two interposers on two buses, a midbus footprint on another, and simple clip-on leads for a component elsewhere on the board. All of these probe media will be in action at the same time. Compactness and accurate delivery of signals from all of these multiple buses are essential.

The practice of simultaneously probing multiple buses, once a luxury, is now a necessity. Time-to-market pressures have driven designers to seek troubleshooting approaches that quickly yield actionable answers. Designers have discovered that the best way to trace a problem often involves triggering on the error while viewing its origins in one subsystem and its consequences in another. Interactions and dependencies among buses that are not electrically connected can reveal much about a system's stability.

Suppose a prototype for a new laptop motherboard has emerged from fabrication and, during design validation, regularly encounters problems in its routine functional exercises. In the worst case, the device freezes and requires rebooting. In other instances, the device seems to operate normally, but the display is garbled and meaningless.

Assume that this exercise is a deliberate validation test, not an online operation. The test proceeds as follows: First, the CPU issues a write command and sends data 13FFh to an address location in the DDR2 (double-data-rate 2) memory. Looking at Figure 1, the instruction follows an obvious path: from CPU through the processor bus to the chip set and ultimately through the DDR bus to the memory devices. Then the graphics card issues a read command targeting the same address. The command goes over the PCI Express bus, through the chip set, and to the DDR2 memory. Lastly, the CPU issues a second write command and sends new data to the same location in the DDR2 memory.

Because no other instruction should have modified the data before the read, the result of the query should be 13FFh—exactly the same data that was written during the first cycle. But the result is 13EFh, and the PCI Express card reports an error. The fastest and easiest way to track down the problem is to simultaneously monitor all three of the buses involved in the transaction. In Figure 1, logic-analyzer units connect the PCI Express-bus and processor-bus interposers to logic-analyzer acquisition modules, and a midbus probe brings the DDR2 data directly to a group of logic-analyzer channels.

Looking at the transactions from the PCI Express bus in their parallelized form that the logic-analyzer interface delivers, it becomes clear that the PCI Express graphics card is receiving the incorrect 13EFh data word; it is accurately reporting flawed data (Figure 2). Neither the graphics card nor the PCI Express bus is the source of the problem. The next step is to look at the DDR2 bus. Here, a read operation confirms that the bus wrote the correct address, which brings the processor into question. Did it send the data it was supposed to send? Monitoring the processor bus via its interface box establishes that the processor wrote the correct data to memory. All three buses seem to be doing their jobs correctly, and the CPU is correctly issuing data and sending it to the desired memory location. The only remaining possibility is a timing conflict. One potential suspect is the read/write timing. Yet the previous steps have established that the CPU is issuing the write command at the expected time.

For suspicious timing and synchronization problems, the logic analyzer's ability to display correlated traces from all three buses is a time-saver. A look at the memory bus reveals that the second write cycle precedes rather than follows the read (Figure 3). The PCI Express card thus receives data stored one operation later than intended. The time-correlated view of the read, write, and data values on respective buses reveals a classic problem: The chip set, which should act as a traffic director, is incorrectly timing the graphics card's read request. The read fails to access the memory after the first CPU write cycle as intended.

Laptop computers implement a sleep mode wherein elements other than the system memory power down during periods of inactivity. The objective is to conserve battery energy. When the device wakes up from this mode, it should come back to life and immediately be ready for use. But suppose that the laptop freezes during its attempt to resume regular operation. A logic analyzer can trace the conditions that caused this failure.

After connecting an interposer, troubleshooting begins with an examination of the last valid transactions on the processor bus. Disassembly software residing on the logic analyzer converts the raw hexadecimal data into the human-readable instructions of the original development language. As a result, you see that the code-fetch instructions become corrupt. The actual data may comprise legitimate codes that are incorrect in this context or may contain random sequences that the disassembler simply can't interpret.

The next step is to view the memory bus to see whether the chip set is altering code fetches as they pass through it. If the system-memory data matches that on the processor bus—that is, if the data still contains the corrupted fetch instructions—then the chip set's data transfer is not at fault. This condition implies that the data degraded while it was in the memory during sleep mode or that incorrect data was stored before the sleep mode began. If the logic analyzer offers appropriate triggering features, it is simple to determine whether the data was correctly stored to begin with. With a trigger condition stipulated, the instrument acquires transactions only when valid, active transactions occur. The logic analyzer captures data both before and after the sleep state, no matter how long that state lasts. If the incoming data is correct, then the only possible conclusion is that the information was corrupted while waiting in memory during the sleep mode.

The logical suspect is the CKE (clock-enable) signal, a common chip-set feature that puts the system memory into sleep mode. Further examination of the CKE0 signal reveals that it experiences momentary glitches as it signals the memory devices to enter sleep mode (Figure 4). The timing view that the logic analyzer acquires makes these glitches clear. The glitches unintentionally disable the self-refresh and allow the memory chips to "forget" their data. Although the chip set isn't to blame for transferring incorrect data, it is at fault for creating the failing condition in the first place.

In this example, the logic analyzer's triggering facilities simplify the capture of events that are widely separated in time, whereas multibus probing saves time when a system must acquire signals from diverse buses. With the aid of these tools, the troubleshooting process moves quickly from a theory to a conclusion.

Densely populated mobile system boards present hundreds or thousands of signals to the logic analyzer. More often than not, a problem in a mobile prototype impacts several subsystems. Simply connecting to all these tiny test points is a major challenge, as are triggering, acquiring, and displaying time-correlated results from multiple buses. The logic analyzer must provide tools that speed and simplify troubleshooting, especially by addressing unique problems, such as space constraints driven by product miniaturization and the increasing use of low amplitude/low-power signals to preserve battery life.