View and Control BGA Pins to Debug Hardware and Circuits

New tools make it easy to debug hardware in order to get Intel-based prototype designs up and running quickly.

By Rick Folea

We've all been there: An engineer designs an Intel processor in a ball-grid-array (BGA) package into a circuit. Then he or she sends it off to fab, gets it back, plugs it in, and turns it on. What happens? Nothing. All of the circuit traces are buried in a multi-layered board. Because the processor is in a BGA package, the designer can't use his or her trustworthy O-Scope to see what the pins are doing. In addition, the netlist and schematic are unstable because management yanked the design from the engineer's death grip and sent it off to production before he or she had a chance to finalize or finish it.

The good news is that a new genre of tools is now available to handle such situations. These tools are based on a recently awarded patent. From a laptop, they allow the designer to see and control the pins under a BGA in real time while the circuit is running. The beauty of these tools is that they require no additional design resources on the board. Nor do they need any additional parts or real estate. Everything that's needed is probably already on the board. The designer simply has to:

1. Drop the parts on the screen.
2. Connect the board to the PC via a download cable.
3. Enable scan and instantly see what every pin on every device in the JTAG chain is doing in real time while the circuit is running (see Figure 1).

To help organize and control pins, the designer can even connect virtual light-emitting diodes (LEDs) and virtual switches to pins. Figure 2 shows an example in which the user is monitoring part of an address and data bus on a processor without affecting the processor's normal operation in any way.

How Does It Work?
Every device with a JTAG port has built-in circuitry. This circuitry allows the designer to monitor and control every JTAG-enabled pin on the device. Although that capability is normally used for manufacturing test, there's no reason that it can't be used for real-time debug. A signal that leaves the core silicon passes through a layer of boundary-scan logic before it reaches the analog driver for the pin. The pins are shown in the yellow boxes in Figure 3.

Normally, the boundary-scan logic lets the signal pass unimpeded. As a result, most people don't even know that it's there. Input signals pass through this layer too. The logic is just some muxes and latches that allow the engineer to sample and even drive each individual signal associated with a given pin (Input, Output, and 3-State).

If the designer knows how to access the boundary-scan logic, he or she can monitor all three signals and even control them. The designer will then have total visibility and control over every JTAG-enabled pin on the part. In essence, these new tools replace the tedium of accessing the JTAG port with a graphical user interface (GUI). That GUI makes it easy to view and control the pins on the device(s) while the circuit is running.

Continuity Testing Makes a Comeback
Wouldn't it be great to just touch a BGA pin with an O-Scope to see what that pin is doing? It would be even better to actually drive an individual pin in order to see if the signal makes it out from under the BGA, across the board, and to another device for a simple continuity test. With access to the boundary-scan logic, these scenarios are possible.

Figure 2 shows an example of how this task could be accomplished. DUT1 (a processor) has an 8-bit bus that's connected to a complex programmable-logic device or CPLD (DUT2). Both devices are in the JTAG chain. Virtual switches are connected to the processor output buffers. Virtual LEDs are connected to the input buffers on the CPLD.

The engineer simply has to click on a virtual switch to drive the output buffer on the processor. He or she can then watch the result at the virtual LED, which tells the response of the input buffer at the CPLD. If the processor pin is driven high and the virtual LED lights up, continuity has been achieved. If desired, one also could connect virtual switches to the 3-States.

In a matter of seconds, a real continuity test was just performed out from under one BGA and into another without touching the board. There was no need to provide and test vectors, netlists, test executives, or anything else that's normally associated with traditional boundary-scan test.

The yellow LED in Figure 2 is connected to a clock input on the processor. If the LED toggles, something is clearly driving that pin. The clock, which is probably connected, isn't a problem. Could a bunch of virtual switches be set up to drive a D/A? Sure. The same is true for a memory device. The bottom line is that the designer has total control and visibility of every JTAG-enabled pin on the BGA device. He or she can decide what to do with it. This approach works on any device with a JTAG port--not just Intel processors. It works with CPLDs, DSPs, Ethernet switches, FPGAs, ASICs, and more.

Of course, there are some inherent limitations when using boundary-scan logic for debug. The first issue is that boundary scan is slow. Every time the engineer wants to do anything, he or she has to shift the entire scan chain. Say a device has 250 pins. If each pin has three scan cells associated with it, the scan chain will be 750 bits long. If five of those devices are in the JTAG scan chain, 5 x 750 = 3750 bits (plus some additional overhead) will need to be shifted to flip the logic level on just one pin. Fortunately, simple continuity tests are usually being performed. As a result, this issue isn't much of a problem.

Suppose a virtual LED is connected to a 100-MHz clock input. It won't be possible to see the 100-MHz clock--especially because these tools only update the screen at about a 10-Hz rate. If they updated any faster, the result wouldn't be seen anyway. A blinking virtual LED will appear, which indicates activity on this pin. When engineers place an O-Scope on the pin of a part, they usually want to know if the pin is high, low, or toggling. These tools communicate that pin activity.

Programming Flash Memory
Interestingly, boundary scan can program a Flash-memory device in-circuit from any JTAG-enabled device--not just processors. Suppose, for example, that a Flash device is connected to a CPLD. Using the boundary-scan chain, one can simply shift the programming vectors into the chain to set up the data and addresses. The engineer can then shift to activate the WE and shift again to de-activate it. He or she will have just completed a write cycle. After performing that task a few million times, he or she has programmed a Flash device in-circuit.

It's also possible to get a little boot loader into the Flash device to bring up the processor when its ICE isn't working. With boundary scan, one can drive the pins to prove that the signaling between the processor and Flash are good (or not). This approach helps the designer figure out where the problem lies. It also provides an independent way to verify the connections between the Flash-memory device and the processor.

The ability to program Flash devices is built into the boundary-scan tools. No special algorithms or device tables are required. The engineer just fills in a dialog that tells the tool which pins on the Flash device are connected to the JTAG chain. He or she then supplies a data file and hits Program.

Because boundary scan is dependent on the operation of the processor function, serial or parallel Flash can be programmed from any set of pins--not just the dedicated address/data buses. For example, say a serial-peripheral-interface (SPI) Flash device is connected to some general-purpose I/O (GPIO) pins. Now, there's a way to get data into that device independent of the processor.

Mini Production Testing
This type of real-time boundary-scan testing is ideal for quick low-level debug. But what if a designer has a couple dozen boards that he or she wants to check out quickly? Although it's possible to manually drive all of the I/Os, that task would quickly get very tedious. Thankfully, these tools have built-in script recorders that can record a test performed on a known good board. The script can then be "played" back on other boards to see if the results are the same.

This article has focused on using boundary scan for low-level, manual, real-time debug. Don't forget, however, to explore traditional boundary-scan tools. With these tools, one can provide a netlist. The tools will then generate test vectors that will check every net on the entire board that's accessible by JTAG. Simply run the test vectors through the chain. The results will indicate where potential problems lie.

The main difference between the two methodologies is that the traditional tools are run on boards in known static states. Everything is automatic and there's usually a fair amount of setup involved (test vectors, test executives, CAD data, etc.). The tools discussed in this article are used on boards that are running. The engineer simply wants to see what pins are doing and control those pins manually while the board is running. There's no setup involved. The designer just places the parts on the screen, attaches a cable, and hits Scan. An indication of what every pin is doing is instantly provided.

The traditional tools are primarily for the manufacturing end of the product cycle. In contrast, the low-level debug tools described here are for the early debug stages of the product design. At that point, netlists aren't stable and test fixtures aren't developed. In addition, the engineer doesn't want to take the time to generate test vectors and test executives just to verify a few interconnects.

There's a new way to do old-fashioned, low-level continuity testing on the board while the design is running. Just drop the parts on the screen, add a download cable, and hit Scan. Add a few virtual LEDs and switches. With the resulting control panel, it's possible to quickly diagnose issues on the board.

The screen shots used in this article were taken from a product called "J-Scan," which is produced and sold by Macraigor Systems. The J-Scan GUI and design are licensed from the holder of the patent for doing low-level, real-time debug via boundary scan. For more information, visit www.J-Scan.com or www.macraigor.com.

Rick Folea has been supplying tools and consulting with the JTAG debug market for 15 years. Macraigor Systems is a supplier of JTAG and BDM interfaces and debug tools for a wide range of processors.