Embedding JTAG into a system’s service processor allows for powerful out-of-band (independent of the operating system) built-in self test (BIST) functions. Using JTAG-based boundary scan, for example, can isolate system failure root cause to an extent unachievable through any other means.
The use of boundary-scan test (BST – as described in IEEE specifications IEEE 1149.x and also known by its moniker as JTAG) is a time-proven means to detect and diagnose existing and latent structural defects at prototype development, manufacturing, and at depot and repair. BST is a static vector-based test technology that uses the on-chip JTAG embedded instrument within commercial silicon to perform structural testing. As such, it performs shorts/ opens/ stuck-at fault testing and detection very quickly. Diagnostics are to the device and net/pin level.
BST is normally deployed on the benchtop. As such, it makes use of external hardware (controller/pod, cables, fixturing) to provide physical access between the workstation running the boundary scan application and the system PCB target, via for example the Teradyne HSSub PXIe controller, or ASSET’s own Ethernet-based RIC-1000 controller:
But, since BST is purely software that leverages on-chip embedded logic, it is possible to port that application directly onto the PCB itself, provided it has the requisite on-board processor/memory resources available, typically via a service processor:
BST is particularly effective in diagnosing failures in high-speed I/O and memory nets, as means of calibration and error-correction that are incorporated into such high-speed protocols tend to hide structural faults that may later result in system failure. Put another way, such nets tend to be “self-healing”, and latent failure symptoms due to marginal board structural integrity may be masked from functional tests, but be visible to BST. This is especially important, for example, in defense applications, where poor system reliability combined with frequent failures of Built-In Test (BIT) may cause crew to undertake missions with undetected faults. For example, as quoted in Forbes regarding the F-35 program:
Efforts to improve the reliability of Lockheed Martin Corp.’s F-35 are “stagnant,” undercut by problems such as aircraft sitting idle over the last year awaiting spare parts from the contractor, according to the Pentagon’s testing office.
The availability of the fighter jet for missions when needed — a key metric — remains “around 50 percent, a condition that has existed with no significant improvement since October 2014, despite the increasing number of aircraft,” Robert Behler, the Defense Department’s new director of operational testing, said in an annual report delivered Tuesday to senior Pentagon leaders and congressional committees.
Regardless of the veracity of the above, there is always room for improvement. By embedding BST, it can be applied at-scale, at a system-level and in a parallel fashion in such environments as manufacturing production lines, environmental stress & screening (ESS), repair/return depots, and in the field. BST also complements in-situ functional test applications by detecting static faults and isolating them to device nets and pins, as opposed to solely board function. Most importantly, BST is an excellent solution for built-in self tests, whereby a static test is initiated either autonomously by the system (i.e. during such processes as power-on self test, periodic system audits, or in response to a system failure) or interactively via an external console (i.e. via the craftsperson in attempting to triage an event).
ASSET’s implementation of embedded boundary-scan provides symmetry between benchtop and in-situ use of its flagship ScanWorks product. As with ScanWorks benchtop, the embedded version also uses the concept of projects, which are comprised of one or more designs, each of which can have a number of actions. Each action may have some precondition code that is used to establish some desired state before execution of the action itself. The project is developed using ScanWorks on a Windows PC. The action data is either embedded on each unit under test (UUT) by storing the associated data in on-board flash memory, or downloaded to the UUT via an off-board link, preferably Ethernet. An action player in the embedded environment then uses files created during this development process to run the actions.
There is a single SED action player (Kernel Loadable Module, or KLM) that handles all supported actions:
- Scan Path Verify (SPV)
- IEEE 1149.1 Interconnect testing
- IEEE 1149.6 Interconnect testing
- Memory Access Verification
- CPLD/FPGA Programming/Configuration
- Flash Programming
When a ScanWorks action is run, the results are stored in files (<action name>.log and <action name>.xml). As an example, the .log file for a failing SPV test is as follows:
Precondition completed successfully
*** Starting DeviceID & Bypass DR scan only test… ***
IDCODE for Device U1 in tap 1 PASSED
Expected data: 00110000000000011100000000101111
Expected data: 00110111100000011100000000101111
Measured data: 00110000000000011100000000101111
IDCODE for Device U8 in tap 1 FAILED
Expected data: 00110000000000011100000000101111
Expected data: 00110111100000011100000000101111
Measured data: 11111111111111111111111111111111
IDCODE for Device U7 in tap 1 FAILED
Expected data: 00000010000010100001000011011101
Measured data: 11111111111111111111111111111111
Also output is an ASCII file that contains information about which TDO bits measured did not match the expected value (i.e. miscompares). This file can be used in the ScanWorks environment to create a diagnosis of the failure, operating as though it is testing the failing hardware directly. The file also contains signature information to ensure that the action it runs is the same as the action that was run by the embedded action player.
Architecturally, in one implementation, the system acts as a single Embedded Boundary Scan Module, that instantiates the JTAG Controller, a PLL that supplies the JTAG Controller with its TCLK, and an AHB-Lite Interface that translates the Wishbone signaling in the JTAG Controller to AHB-Lite signaling:
And the JTAG Controller module itself has the following components:
For more information on the embedded boundary scan application itself, please register for our eBook, Embedded JTAG for Boundary-Scan Test.
Imagine how powerful a built-in embedded boundary scan test engine would be for testing memories. Memory test is one of the largest challenges facing board bring-up, and memories often constitute a large percentage of the nodes on a given design. The efficacy of boundary scan for memory testing is covered in our eBook, Testing DDR4 Memory with Boundary Scan/JTAG (note: requires registration).
