JTAG for Functional Test
14 October 2009
James Stanbridge, UK Sales Manager for JTAG Technologies, explains how combining boundary-scan with an open-source language is a perfect match.
From its inception, the JTAG interface (as devised by the Joint Test Action Group and ratified as an IEEE std. 1149.1 in 1990) was intended to relieve the board-level pin access problems that mainly faced structural test engineers. Of course, before the introduction of JTAG most In-Circuit Testers (ICTs), and their more rudimentary cousins (Manufacturing Defects Analysers - MDAs), relied on through-hole pin access to check for net-to-net shorts and some device functionality - or simply device presence and orientation.
By the mid-90s, JTAG-compliant devices had become more common, helped along by the proliferation of large programmable logic devices such as FPGAs and CPLDs; and the use of JTAG with its embedded ‘silicon nails’ approach became a ‘must have’ add-on to the structural test stage.
With some clever enhancements JTAG was then used to check for open- and short-circuits on device-to-device interconnects, device-to-I/O-connectors, and device-to-memory bank connections. PLD and FPGA configuration and in-system flash programming could also be achieved either directly or indirectly using JTAG.
However in nearly all cases the approach to JTAG testing has been ‘vector-based’ and not ‘language-based’. This is understandable as JTAG is primarily a digital testing technique; one that need only provide a PASS/FAIL indication and have a diagnostic capability that can parse results to give sensible fault descriptions.
It has become clear that the access that JTAG-compliant designs afford to mixed signal devices on a circuit could be harnessed to test devices in a functional manner. For example, consider an I2C or SPI bus device, such as a temperature sensor, that connects back to a JTAG-compliant part. Whilst it is possible to use a vector-based approach to simulate the bus cycles and transmit instructions and receive data, limit-testing is somewhat more difficult – or it has been until now.
JTAG Technologies recently introduced high-level JTAG access routines, which can be linked into the Python™ freeware open-source language. Called JTAG Functional Test (JFT) routines, they work at two levels (or perspectives), namely: boundary-scan pin-level and ‘cluster’ pin-level.
In the boundary-scan pin-level example (see figure 1), users can set-up tests with minimal knowledge of the interconnections and without reference to a design netlist. Individual pins can be driven using DriveHigh (for example on IC1.19), DriveLow (on IC1.16) and HighZ (on IC1.13); and individual pins can be read using TestHigh (say on IC1.11) and TestLow (on IC2.11).
Also, groups of pins can be defined by DeclareGroup. For example, the pins of a JTAG-compliant device which connect to a (non-JTAG-compliant) DAC might be grouped (say IC2.18, 17 and 14) and named ‘DAC-input’. The variable ‘DAC-input’ can then be controlled using a DriveVar command.
Similarly, the output of an ADC could be suitably-named and read by a TestVar routine.
Using JFT at this level allows design engineers to undertake debug sessions without recourse to writing embedded test firmware or FPGA test configurations. Equally, repair or service personnel can easily create test scripts to cover well-known fault signatures.
The cluster pin-level perspective (see figure 2), takes testing to the next level/stage by allowing the user to specify pin-level and variable-level drives - testing from the device under test’s (DUT’s) point of view.
Again, individual input pins can be controlled - but this time using different commands (for example InputHigh on IC3.1 and OutputLow on IC3.3). As before, pins can be declared as belonging to groups and assigned variables. For example, you could declare IC3.2, 7, 12 and 20 as grouped and assign the variable ‘Vout’ to correspond with an analogue output. ‘Vout’ could then be controlled using a single hex or decimal number.
This has considerable advantages when used in conjunction with a ‘netlist-aware’ development system, such as JTAG ProVision. Entire device-level test routines can be created and saved without reference back to the boundary-scan (JTAG) pins that provide the stimulus and response signals. This makes them portable and re-usable across designs and projects.
Indeed, ProVision has, for some time, supported re-usable models for component disabling, net-joining and testing of generic components (such as memories and logic families). However, the JFT Python routines add an extra dimension to the development capability of the tool and tests, such as programming a real time clock (RTC) device with a time-stamp captured from the controller PC, that had been difficult in the past are now a breeze with the JFT routines.
Contact Details and Archive...
Related Articles...
Most Viewed Articles...
