Many legacy In-Circuit Testers (ICT) support some kind of boundary scan for structural testing, to address limited access issues. But are these as good as advertised?
Benchtop boundary scan (JTAG) test systems are optimized for structural testing, and many such solutions have had a decade or more of tuning to maximize test coverage and diagnostic granularity. The boundary scan test solutions on ICT, on the other hand, are often a generation or two behind and don’t offer the power or flexibility of the benchtop systems. ICT-based boundary scan test systems often suffer from limitations in the following areas:
Slow TCK, and poor Memory Testing
Most ICT have a maximum TCK (test clock) of 1-2MHz. This makes them far too slow for applications like flash programming. Also, for higher-speed memories such as DDR3, this TCK rate is generally insufficient for the timing and signals necessary to read and write to these memories.
Most test engineers are aware of the limitations of ICT when it comes to memory testing on current designs, and often seek supplemental functional test coverage on these nets and devices. However, benchtop boundary scan can generally offer close to 100% shorts and opens coverage here, with diagnostic granularity to the device, net and pin.
1149.6 Support
IEEE 1149.6 support is necessary for testing AC-coupled nets such as PCIe, XAUI, and SATA, which are common on many current designs. Most ICT implementations are woefully behind when it comes to generating the vectors necessary for comprehensive test coverage and diagnostics on these nets. A good 1149.6 tester will support 1149.6 to 1149.6, 1149.6 to 1149.1, 1149.1 to 1149.6, and 1149.1 to 1149.1 cell testing to ensure shorts and opens test coverage on both sides of the capacitors and between nets common to and separate from a given lane.
Ask your ICT vendor if you’re getting the 1149.6 test coverage you expect.
Powered Opens
Powered Opens technology (known variously as CoverExtend, ToggleScan, and Digital Framescan) uses a boundary scan stimulus coupled to a capacitive sensing plate placed over a lead frame or connector to provide test coverage to non-boundary scan parts. In principle at least, it provides a test solution to connectors, which makes it easy to implement at ICT. However, its limitations render it at best only a partial solution. The slow ICT TCK spread across hundreds or even thousands of boundary scan cells yields a toggle frequency insufficient to read analog stimulus deterministically. Two opens on a differential pair will escape detection. Shorts on the connector side of the capacitors can escape detection. And no coverage at all is available when the associated boundary scan cells are input-only, which is quite common on high-speed I/O receiver pins.
It is worth noting that there is an initiative within the IEEE, P1149.8.1, which is intended to address some of these limitations. But this standard is several years away from being adopted within commercial silicon, if ever. I do know of one silicon vendor which has a pre-standard implementation within some of its chips, but it’s very limited and only addresses some of the issues, while introducing other ones.
So let the buyer beware when your ICT vendor touts Powered Opens as a test solution – you’re probably getting less than you bargained for.
Chain concatenation
ICT systems in general only support one active scan chain. This means no synchronization and concatenation of boundary scan vectors between separate chains on a board – which reduces the overall test coverage. This is overcome by concatenating chains in hardware external to the board through some sort of breakout board or fixture electronics – a more expensive and complex solution, assuming it is considered. Some test strategies just do one scan chain for the sake of simplicity, but in sacrifice of test coverage.
Benchtop boundary scan solutions, on the other hand, handle multiple scan chains “out of the box”. This also makes them ideal for parallel boundary scan testing.
Handling of non-boundary-scan components
Some ICT have limited capability of “functionally” exercising non-boundary-scan components, such as running patterns through DACs/ADCs, reading clock times, reading sensor output, testing/programming I2C/SPI devices and memories such as dual-ported RAM (DPRAM), etc. etc. But these tests are typically very labor-intensive to create (if they are supported at all) and manual in nature.
Modern benchtop boundary scan tools support using JTAG in conjunction with new object-oriented programming languages, such as Tcl, to provide levels of test coverage which can only be dreamed of on ICT.
Need for dual-stage fixtures
Boundary scan on ICT often needs to run with the main fixture probes isolated, to reduce noise and make the test repeatable and deterministic. This mandates a “dual-stage” fixture which adds additional cost and complexity within the testing solution. Alternatively, the TCK can be run at a much lower frequency.
Of course, benchtop JTAG systems require only access to the TAP and are limited primarily by the maximum TCK of the slowest device in the chain. This means that often test and programming speeds of 50MHz and beyond can be achieved.
Run SVF, but not STAPL and other advanced programming languages
Some ICT systems can only run SVF (serial vector format) files, and not STAPL (Standard Test and Programming Language). The latter allows for conditional logic, branching and looping, allowing for much smaller files and faster programming times. This makes for much more effective in-system configuration and programming of CPLDs, FPGAs, serial PROMs and other devices. And STAPL is a more flexible language, with support for scan bridges, command-line arguments, logging of test action execution details, etc.
This is generally not a problem unless the above requirements are part of the structural test flow. However, it is worthwhile noting that ICT typically don’t directly support the most advanced programming languages, such as Tcl, which is the foundation for the emerging IEEE P1687 standard.
Some devices require active clocks as compliance-enables
Some boundary scan devices require an active clock as a compliance-enable signal. This can be an issue with ICT because of the noise issue and the need to keep the board “quiet and cool”. Again, this can be addressed with the use of dual-stage fixtures, and with more advanced cooling capabilities within the fixture.
Before planning on using native boundary scan at ICT, it is worthwhile knowing the compliance requirements of the silicon on the board, and planning fixture requirements accordingly.
Lifecycle support
Native ICT boundary scan tests can, of course, only be used on the machine they were created on. They aren’t portable to other environments. “Benchtop” boundary scan tools, on the other hand, can be used across the lifecycle of the product: at prototype testing, volume production, and debug & repair.
From the above, it should be clear that ICT-based boundary scan tests have limitations based upon (1) the environment in which they must run, and (2) the lagging implementation of the JTAG tools from the ICT vendors.
Couple all of the above with the limitations of ICT as described in some of my previous blogs: https://blog.asset-intertech.com/test_data_out/2011/04/the-limitations-of-ict.html, and https://blog.asset-intertech.com/test_data_out/2011/04/more-problems-with-in-circuit-test.html. Maybe it’s time to take a look at complementing the older ICT technologies with more advanced tools.
The limitations of traditional test technologies is a topic which I’ll blog more about in the coming weeks.
