Background
The configurable nature of FPGAs and CPLDs means that they contain a very high proportion of general purpose IO signals. However; when configured to provide the functionality required for the operation of board to which it is being fitted some signals will not need full IO functionality. In order to reduce the power consumption of the device the functionality that is not needed is ‘switched off’.
Such changes to the functionality of signals have consequences for XJTAG testing. BSDL files, used to describe the device to XJTAG, assume devices will be in their pre-configuration state, and XJTAG will implement tests based on the level of access described.
Example
An IO signal is configured to be uni-directional; due to the information extracted from the BSDL file XJTAG will attempt to drive and read this signal during the connection test in order to identify any manufacturing faults; however in this situation non-existent errors will be reported and real errors may go un-detected.
The nature of the false error will depend on whether the modified signal is the only JTAG signal on the net.
In the situation where the modified signal, originally with inout functionality, is the only JTAG enabled signal on the net there would be a stuck at fault reported. XJTAG would tell the device to drive a pattern of zeros and ones from the device and then attempt to read that pattern back. If the signal has been configured as an input then it would never drive the pattern onto the board and so the value read back would always be at its default/undriven value. If the signal has been configured as an output then the value captured would not reflect the value of the net. In either case XJTAG would report a stuck at fault.
In the situation where there is more than one JTAG signal on a net XJTAG would report an error but not be able to provide any guidance as to the type of fault; the error report would say the net was either shorted to another net (that is not accessible through JTAG) or a non-JTAG pin is also driving the net. If the modified signal is configured as an input the expected pattern would not be read back by either signal when driven by the modified signal but it would be read successfully when driven by the other signal. If the modified signal is configured as an output the expected value would never be read back correctly on the modified signal but always read correctly on the unmodified signal. In neither case the resulting error would be the same; an open circuit diagnosis would not be made as the board can communicate between the two signals, just not fully.
Solutions
When faced with the problem of testing a board that contains configured devices there are a number of solutions:
- The very best results are obtained by clearing the image from the configured device; this makes the device behave as described in the BSDL file and maximizes the amount of test coverage attainable through JTAG.
- If it is not possible to clear the configuration from a device both Xilinx and Altera provide utilities that take a BSDL file and a configuration image and create a modified BSDL file that reflects the configured state of the device. The Xilinx utility is called BSDLAnno and is installed as part of the Impact tool suit; the Altera utility is called BSDLCustomizer and can be downloaded from the Intel website: BSDLCustomizer.zip.
- Altera do offer another option which is to set the ‘Always Enable Input Buffers’ configuration option in their Quartus tools. Selecting this option means that the boundary scan operation of the device remains the same irrespective of the functional operation of a signal.
- The final option is just to not test the pins that have had their functionality reduced. In XJTAG you will need to setup some constant pins with a value of INPUT to instruct the tool not to test these pins.
Further considerations
Creating a modified BSDL file is not the best solution to work around these problems because in situations where there is only one JTAG signal on a net then short circuit faults and stuck at faults may go un-diagnosed. The test system will not be able to diagnose any stuck at faults or any short circuit faults between signals with reduced functionality.
Consider a situation where you have an address bus going to an external connector; all of the signals that are part of that address bus are likely to have been configured as output only. Any short circuits between the pins of the connector, a common point for such fault, would not be identified due to the configuration of the device.
How to clear a configured device
Given the problems that can result from using a configured device the best solution is to test boards in their pre-configured state. If it is possible to schedule the order of operations such that the testing of boards occurs before programming then there should be no problem; however if the images have already been programmed, leaving devices are in their configured states, then a mechanism for removing the image must be found.
XJTAG provides an interface for playing SVF and STAPL files which both the Impact and Quartus tools can produce. Having produced a ‘blank’ programming file in one of these formats a test system can be created that will return a board to its pre-configuration state and then test the board. Another SVF or STAPL file can then be used at the end of the testing process to re-configure the board it necessary.
There may, however be problems clearing the configuration from a device, particularly an FPGA. The nature of an FPGA means that it has to be configured each time that power is applied to the board and, as such the image must be stored in some PROM or FLASH device on the board. When the programming operation of a Xilinx FPGA completes it will toggle its DONE signal; if this occurs when it is not expected then the PROM or processor that configures the FPGA can automatically re-start the process of programming the FPGA with its functional image (undoing the clearing that has just been done through XJTAG). To get around this problem it may be necessary to first clear the device that is being used to configure the FPGA so that it cannot be reprogrammed. If the device is being configured from a non-JTAG FLASH device then XJEase can be used to clear that device and to re-program the device once testing is complete.
BSDLAnno Overview (From the Xilinx web-site)
The Boundary Scan Description Language (BSDLAnno) utility automatically modifies a BSDL file for post-configuration interconnect testing. BSDLAnno obtains the necessary design information from the routed .ncd file (FPGAs) or the design.pnx file (CPLDs), and generates a BSDL file that reflects the post-configuration boundary scan architecture of the device. The boundary scan architecture is changed when the device is configured because certain connections between the boundary scan registers and pad may change. These changes must be communicated to the boundary scan tester through a post-configuration BSDL file. If the changes to the boundary scan architecture are not reflected in the BSDL file, boundary scan tests may fail.
The Boundary Scan Description Language is defined by IEEE specification 1149.1 as “a common way of defining device boundary scan architecture.” Xilinx provides both 1149.1 and 1532 BSDL files that describe pre-configuration boundary scan architecture.
For most Xilinx device families, the boundary scan architecture changes after the device is configured because the boundary scan registers sit behind the output buffer and the input sense amplifier:
BSCAN Register -> output buffer/input sense amp -> PAD
The hardware is arranged in this way so that the boundary scan logic operates at the I/O standard specified by the design. This allows boundary scan testing across the entire range of available I/O standards.
Example devices that BSDLAnno can be used with:
- Virtex™/-E
- Virtex-II™
- Virtex-II Pro™/X
- Virtex-4™/FX/LX/SX
- Spartan™, Spartan-II™/E
- Spartan-3™, Spartan-3E™, Spartan-3L™
- CoolRunner™ XPLA3, CoolRunner-II™
- XC9500™, XC9500XL™, XC9500XV™
What is BSDLCustomizer? (From the Altera web-site)
BSDLCustomizer is a TCL script to modify the BSDL file’s port definitions and BSC groups’ attributes according to the design and pin assignment from Quartus II PIN file.