This week, I looked at some of the main test actions that apply to the ScanLite board: in particular, the Scan Path Verify action.
Last time, I loaded up the ScanLite Example Project, a pre-built project that contains all the ASSET-made test actions that apply to this design. The ScanLite board was designed back in 2001, when the boundary scan test market had just started to gain some steam. When I re-launched ScanWorks this week, the Example Project reloaded, along with a display of the applicable actions:
The SPV1 action (Scan Path Verify) is of particular interest, because it sets the foundation of all of the other actions. Scan path verify actions check the scan path integrity, verify the scan path length, and verify the correct order of the devices in the scan path. When I click on the SPV1 link I see the things that I can do with the SPV action:
Clicking on “Edit” shows me some interesting options at the top right that I can use to fine-tune any scan path malfunctions; that is, if the scan path verification fails:
To understand SPV and these options better, a little background on the ScanLite scan path is helpful. Using the built-in PTC Creo View Lite application within ScanWorks, and opening the schematic for the ScanLite within the “doc” folder, you can see the main board design on pages 2 and 3:
If you look carefully (just looking at the TDI and TDO path), you can see that the scan chain goes from the 14-pin JTAG header at the bottom of page 2 (CON14A), through 74ACT244, through XC9527, through BCT8244A, through SW11, through ABT18245A, and then back through 74ACT244 and back out the 14-pin header.
Fortunately, in this example project, you don’t need eagle eyes like I do, to see the scan chain. ScanWorks lets you look at the scan chain boundary scan devices directly by clicking on the “Designs” tab:
Pretty cool, huh?
For the sake of reference, the devices are as follows:
74ACT244 (U6): an ON Semiconductor octal buffer and line driver designed to be employed as a memory address driver, clock driver and bus-oriented transmitter/receiver. Note that this device does not support boundary scan; it just acts as a buffer. It’s on the scan chain, but must be modeled separately, as it does not have a BSDL file describing its IEEE 1149.1 behavior.
XC9527 (U3): a Xilinx CPLD (note: not much information is available on this part; it must have been discontinued some time ago).
74BCT8244A (U7): a TI scan test device with octal buffers. This one supports boundary scan!
74ABT18245A (U8): In the normal mode, these devices are 18-bit noninverting bus transceivers. They can be used either as two 9-bit transceivers or one 18-bit transceiver. The test circuitry can be activated by the TAP to take snapshot samples of the data appearing at the device pins or to perform a self-test on the boundary-test cells.
There are numerous other devices on the ScanLite board that are used to show off some of the features of boundary scan. These include LEDs, buffers/inverters, flash, some SRAM, a flip-flop, and a bunch of switches. The switches are intended to induce structural faults on the board, demonstrating the efficacy of boundary scan. We saw above that SW11 is part of the scan chain, and if set, presents a TDI/TDO open circuit failure. We’ll see what the other switches are for in later articles.
One of the extremely powerful aspects of boundary scan is that JTAG, the underlying technology, is present in most chips of any complexity, and the software to drive it (part of ScanWorks) is highly portable and flexible. These attributes allow it to be embedded within system firmware, to be used for bit-in test (BIT) applications. A press release on this topic is here: High-End Defense System uses ScanWorks Embedded Diagnostics for In-Situ Boundary-Scan Test. A white paper (note: requires registration) is here: Embedded JTAG for Boundary-Scan Test.
