08 May 2006
Finding fault
Boundary scan tools have shaved days, if not weeks, off the development phase of a wireless platform. By Jonathan Healy and Dominic Plunkett.
Most engineers have experienced the frustration of being unable to start up a freshly delivered board, even though it carries a full set of test passes. Locating even trivial hardware faults in a dense multilayer board can take a day or more and today's engineers require a faster, more certain way to do this.
Test coverage is now significantly challenged by the scarcity of physical test probe access points, since functionality has the first claim on board real estate. The use of multilayer pcbs - where many tracks never reach the surface - the advent of lead free construction and progressively finer board geometries are increasing the instances of hard to find faults such as broken vias.
The usual solution to finding obscure hardware faults is a combination of painstaking manual labour and intuitive use of an In Circuit Emulator (ICE). However, using an ICE to track down a particular defect requires significant engineering judgement and is not guaranteed to be conclusive.
Widespread use of large fpgas is another major challenge to test technologies that rely on easy access for probes. In the mobile market, developers have to start work on new handset designs, even while the applicable protocols and standards continue to evolve quickly and continuously. This is usually accomplished by building the system within reconfigurable fpgas, but these tend to come in high I/O packages with bga interconnects.
A board with multiple large fpgas can have many thousands of inter fpga signals. These interconnects may exist several layers beneath the surface. In general, bringing large numbers of such signals to the surface of a board can compromise the routing of critical circuitry and thereby impair system performance. A custom fpga test image can be used to detect faults in the inter fpga routing, but this can take a long time to finalise, given that the largest fpgas can include more than 1100 user I/Os and up to 200,000 logic cells.
Silicon hardware development
TTPCom, an independent supplier of software and silicon IP for digital wireless terminals, develops designs for the full range of technologies required to deliver a successful handset. Its silicon hardware group (SHG) has recently adopted a boundary scan development system that enables its engineers to identify faults in minutes, instead of hours or days.
The group has already demonstrated cumulative time savings of more than a week from the overall project duration, when producing dual mode (2G/3G) cellular development boards for internal use, as well as with 'pre silicon' customers seeking a rapid evaluation of dual mode or 3G handset designs.
Production quantities of development boards - which cost many thousands of dollars - typically range from tens of units to a maximum of around 100. A recent dual mode development board contained four 1152pin bga fpgas, as well as a 431pin dsp and a 256 pin mcu. The board's 16 layers meant bringing large numbers of signals to dedicated test points would be impractical.
TTPCom's development boards, assembled by a UK based manufacturing partner, undergo extensive testing, including X-ray inspection to identify defects beneath bgas. However, there is significant opportunity for defects to evade detection and boards to be delivered with a clean bill of health.
Boundary scan
TTPCom's SHG engineers require fast, deterministic and accurate techniques to identify, locate and rectify hardware faults. The solution to the combined challenges of poor test access and hidden faults is boundary scan.
Boundary scan testing requires only four external test access points per board, with additional tracks to interconnect the test ports of the on board boundary scan compatible components. An entire board can be scanned by shifting a serial test pattern through registers in each component in the boundary scan chain.
Boundary scan testing - proposed by the Joint Test Access Group (Jtag) in the mid 1980s and ratified as IEEE1149.1 in 1990 - is an inherently powerful concept. For example, comparing the received boundary scan sequence with that transmitted yields information about the nature and location of faults. It is also possible to devise test sequences that will exercise non boundary scan devices - such as memories and uarts - by forcing compliant components in the test chain to write to them.
Moreover, the board does not have to be running. Engineers can begin early debug of development boards before the software is ready and can test individual boards later in the project, even if existing faults prevent the software from booting.
However, there are potential drawbacks. Accessing these capabilities can be labour intensive. In addition, the original Jtag proposals implied a board centric approach to test sequence development, requiring a sequence to be rewritten after each design change. This is not suitable for fast moving modern technologies such as mobile communications.
Boundary scan test equipment vendors are now beginning to build in the analytical power required to extract in depth information about the board and to generate suitable test scripts quickly for new or revised boards into the test gear itself. For instance, some modern boundary scan test solutions are capable of rendering the received boundary scan sequence as a pin by pin image of each device in the chain, highlighting faults graphically in real time. However, it is tougher - but even more valuable - to take on more complex tasks, such as automating the development of test sequences.
SHG identified boundary scan as desirable with the advent of TTPCom's first multiple fpga development boards. After evaluating a number of approaches, XJTAG's solution was selected. XJTAG can calculate automatically which boundary scan device pins must be manipulated to access a desired net. This allows TTPCom's engineers to set up appropriate test scripts for non boundary scan devices easily - usually in just a few minutes.
A further advantage is that XJTAG compiles test scripts automatically by combining boundary scan description language files for compliant devices with the board netlist and test scripts written in a high level language. This device centric, script based approach enables tests to be configured rapidly by selecting from a library of functional blocks. It also allows easy test updates after board redesigns.
This reduces the effort required to use and reuse boundary scan tests on a routine basis significantly. This is beneficial for TTPCom, considering the evolutionary nature of mobile standards: it made sense to evolve dual mode (2G and 3G) development boards from existing 2G boards, for example.
Using XJTAG, it was easy to reuse existing tests, simply by calling them from the group's growing repository of XJTAG scripts for specific devices.
In addition to the ability to perform early debug of development boards, newly delivered boards are now tested routinely using XJTAG. Each board is tested against its netlist and can be returned the same day with a description of any problem found. This has shortened the time taken to identify board defects dramatically - a valuable contribution, given the increasing complexity of each successive generation of cellular standards and the inherent time to market pressures in the mobile industry.
Author profiles:
Jonathan Healy is a design engineer at TTPCom. Dominic Plunkett is chief technology officer for XJTAG (www.xjtag.com).
Author
Graham Pitcher
Supporting Information
Downloads
5723\finding-fault.pdf
Companies
TTP COM
XJTag
This material is protected by Findlay Media copyright
See Terms
and Conditions.
One-off usage is permitted but bulk copying is not.
For multiple copies contact the
sales team.