Structural Testing

Discussion on the justification for SJTAG in each of the identified Use Cases: Alternatives, cost benefits and penalties
Post Reply
User avatar
Heiko Ehrenberg
SJTAG Vice Chair
Posts: 45
Joined: Wed Nov 21, 2007 3:15 pm
Location: GOEPEL Electronics - Austin, TX
Contact:

Structural Testing

Post by Heiko Ehrenberg » Sun Jan 06, 2008 5:00 pm

Meeting Minutes references:
http://www.sjtag.org/minutes/minutes080107.html
http://www.sjtag.org/minutes/minutes080114.html
http://www.sjtag.org/minutes/minutes080123.html


Arguably the most common and most mature use of the JTAG interface and the Boundary Scan resources implemented in IEEE 1149.x compliant devices is what many refer to as "Structural Test".

"Structural Test" in this sense refers to the verification of interconnects between digital I/O pins (in the case of IEEE 1149.1) and/or analog or mixed-signal I/O pins (in the case of IEEE 1149.4) on a printed circuit board (PCB) or between PCB's/modules within a system. The purpose of most structural test applications is the detection and diagnosis of quasi-static faults, such as stuck-at-0/1, shorted signals, or open pins.
Automated Test Pattern Generation (ATPG) tools are widely available for the generation of test vectors that verify connections between Boundary Scan enabled device pins. Various tool sets available on the market also provide ATPG tools that include non-Boundary Scan circuits (such as memory devices, glue logic, and other digital components) in such connectivity tests.
The use of Boundary Scan for structural testing can be extended to include analog circuits, such as Digital-Analog-Converters (DAC) by providing stimulus on the digital side via Boundary Scan and by measuring the analog value of the DAC output directly or via an ADC interface that may be part of the circuitry. One could argue that this kind of cluster testing has less to do with structural test than with semi-functional test. Still, Boundary Scan access to the signals under test drastically simplifies the test development for this kind of cluster test applications (no complicated CPU access cycles or DSP control cycles are needed to set up the DAC or the ADC devices, for example).
For the dynamic test of high-speed signals one can utilize IEEE 1149.6 test resources if devices in the design provide respective capabilities. This would provide additional testability not achievable with IEEE 1149.1 alone (e.g. improved fault detection and diagnostics on differential signals, or detection of an Open fault along AC-coupled signals).

The major benefit of using IEEE 1149.x / Boundary Scan for structural test is the elimination of the need of external test access (beyond the JTAG test bus signals required to transmit the test pattern). This allows the application of structural tests for boards/modules plugged in to a system chassis and even the verification of connections between system modules (provided a respective test bus infrastructure is implemented). This also enables the execution of structural test during HALT/HASS testing.
Last edited by Ian McIntosh on Thu Jun 11, 2009 6:37 am, edited 1 time in total.
Reason: Added links to minutes
- Heiko

User avatar
Heiko Ehrenberg
SJTAG Vice Chair
Posts: 45
Joined: Wed Nov 21, 2007 3:15 pm
Location: GOEPEL Electronics - Austin, TX
Contact:

Structural Testing at System Level - issues and concerns

Post by Heiko Ehrenberg » Mon Jan 07, 2008 3:42 pm

1) Slots are dynamically populated with different types of boards and therefore change the topology of the system model (static system data models do not work);

2) Multi-drop architectures create problems for vector management unless the UUT manages its own vectors;

3) Board-to-board testing is dependent on the current population of the system; not all telecom systems are configured the same.

4) How to identify the attributes of a board, for example board ID, JTAG chain numbers, length, order, chip location, and so on?

5) How to find the test vector files related to boards? (Maybe stored in a flash chip on board or on a external storage medium. Access path might have to be specified.)


Some of the requirements SJTAG should address:

a) Unify methods how to identify board attributes. For example access JTAG chips ID, access a special signature of a board or specifying signal lines to be pulled up or pull down. -> opportunity to define a BSDL like file for a board.

b) Unify the vector format of a board and accessing methods. for instance, adopting uniform STAPL or SVF; and specifying how to name vector file and uniform stored location.

c) System MTC software can reconfigure test topology structure after original hardware configuration is changed.


(Thanks to Brad and Guoqing for bringing up these issues.)
- Heiko

User avatar
Ian McIntosh
SJTAG Chair
Posts: 414
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Post by Ian McIntosh » Sat Jan 12, 2008 10:30 pm

Guoqing raised a good point: We have to be clear whether we're discussing an ATCA specific case or the generic case. In some ways, ATCA is a bad example because we're trying to shoe-horn SJTAG in after the bulk of the ATCA standard has been agreed: What's right for ATCA may not actually be the best decision for all (or most) other cases.
Heiko Ehrenberg wrote:3) Board-to-board testing is dependent on the current population of the system; not all telecom systems are configured the same.
But what is the predominant position across the rest of the industry? In SELEX, although we have, for example, some scaleable systems that could be populated differently from unit to unit, in practice this won't be done at random: We'll know what's in each box, given it's part number, so for any given part number we should know what board to board interconnect tests are valid. I can see many system builders being in the same position. The problem arises when an end user constructs a system from OEM parts.

User avatar
Ian McIntosh
SJTAG Chair
Posts: 414
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Re: Structural Testing

Post by Ian McIntosh » Fri Apr 04, 2008 1:56 am

Heiko Ehrenberg wrote:For the dynamic test of high-speed signals one can utilize IEEE 1149.6 test resources if devices in the design provide respective capabilities. This would provide additional testability not achievable with IEEE 1149.1 alone (e.g. improved fault detection and diagnostics on differential signals, or detection of an Open fault along AC-coupled signals).
I see the IEEE 1149.6 being most useful in testing board-to-board interconnects (e.g. the fabric interconnects in ATCA), but as Tony Sparks highlighted elsewhere, you need to be able to synchronise the scan chains on the boards. This imposes a constraint on the system scan chain topology and gateway devices that needs to be accounted for: At a board test level with an external test controller it's not uncommon to have two or more TAPs that can be run synchronously, but in a system we seem to generally expect (I think correctly) that only a single chain is presented to the controller (ignoring any dual-redundant architectures).

I suspect this means that the topologies for the specific case of ATCA and the generic case of any future, ideal SJTAG implementation may be rather different. Well know better once we thrash out more of the Use Cases, I guess.

Post Reply