Test & Measurement
The clock is ticking
Reg Waller looks at how non-intrusive tools can be used to reduce the pressure on engineers of prototype board bring-up
D
esigners often find themselves in a pressure cooker. The first prototypes of the circuit board they’ve been working on for six months have just arrived and to meet the new product introduction schedule the boards have to be brought up in a hurry. That means testing the structural integrity of the hardware (and repairing it if necessary), validating that the hardware meets its performance requirements (and doing a board re-spin if necessary), loading and verifying the operation of the firmware (and editing, compiling and reloading it if necessary) and eventually, loading and verifying the operation of the software (and recoding and reloading it if necessary). Then and only when the design has been fully brought up can it be declared ready for volume manufacturing. Every day or week of delay can cost the company dearly in terms of missed sales in the marketplace.
Figure 1: The Board Bring-Up Cycle
Another aspect that adds to the pressure many designers feel is, in many cases, they’re using 30-year-old validation, test and debug methods even though hardware has advanced light years from where it was 30 years ago. Needless to say, board bring-up can be a challenge.
No place to test
Most of legacy diagnostic and debug tools rely on probing the board. Unfortunately, the physical access that a probe needs is disappearing for a variety of reasons. For example, the test pads on the surface of a circuit board where a probe could gain
10 April 2012
access to test device interconnects are becoming problematic. There’s no place for them on multilayer, very dense circuit boards. Moreover, not too long ago probes could gain access through a device pin, but now more devices are being placed in pin-less packaging, like ball grid arrays where the pins are tiny balls underneath the silicon die. Probes can’t reach under the silicon. This all points up the great need board bring-up teams have for non-intrusive software-based tools that don’t rely on physically probing the board. Consider the following typical example. The first prototypes arrive later than expected and they won’t boot. They won’t even come up and they don’t give any hint why. Without any access to a working processor and memory, traditional software-based troubleshooting tools can’t be brought online. The X-ray team might be asked to detect structural assembly problems, but the results are often ambiguous. Next, the board could end up with the In-Circuit Test (ICT) group, but the fixture is likely still being fabricated and, besides, there may not be enough test points on the board for verifying all the BGA connections. If the engineer is fortunate, he might be able to apply non-
intrusive software-based tools like those based on the IEEE 1149.1 boundary scan (JTAG) standard, processor-controlled test (PCT) methods or signal integrity validation routines based on instruments embedded in components on the board.
First things first Most high-end processors today have implemented the boundary-scan JTAG port and some of its extensions, like IEEE 1149.6 for testing high-speed AC-coupled devices. In a board bring-up environment,
Components in Electronics
boundary scan can quickly give the team a feel for how dead the board is or isn’t. First, the boundary-scan chain must be tested. In most cases, this will also partially verify the processor’s debug port, since it commonly shares the same pins on the processor with boundary scan’s Test Access Port (TAP). If the scan chain is not functional, then a boundary-scan tool can isolate the fault on the scan chain so it can be repaired. Once the prototype’s scan chain is up and running, automatically generated interconnect tests from a boundary-scan test tool can be applied to the board. On
a typical design these interconnect tests will find shorts and opens on devices and nets connected to processors, DRAM memory, flash memory, bridges, chipsets and other critical interfaces. Once structural shorts-and-opens faults are found and debugged, it’s time to load the board’s firmware and take further bring- up steps. In many cases, the firmware may still be in development, but this doesn’t necessarily stop the board bring-up team from the next round of interactive testing and validation on the hardware. The next step would be to deploy another tool, PCT, which can apply at-speed functional
Figure 2: IBIST eye diagram
www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64