TAP interface role expands in device test
Many styles of test interfaces have been optimized for various constraints and goals over the years. There does, however appear to be a trend of test moving toward standard interfaces and increased applications of plug-and-play methods for wafer-level and packaged IC testing.The use of a simple TAP (test access port) interface as the only test port should increase in popularity. I mentioned in a previous article how boundary scan cells can be used for contactless IO wrap and leakage tests through just the five-pin TAP interface.
The TAP has been the common interface for BIST (built-in self test) control and verification. Often, scan testing would use separate scan channels, but why not use the TAP as the scan test interface? If you do, then all levels of test would need the five-pin TAP only. That opens up many opportunities. Because there are only a few pins necessary for test through the TAP interface, it's easier to support multi-site test (multiple die tested in parallel). In addition, retargeting wafer-level test patterns to packaged device, 3D packages, or even devices embedded in boards or systems is easier.
Using a TAP as the standard device test interface means that all test platforms or test methods for devices populated on boards would have a well-understood and common interface. Thus, test planning and support would be much more predictable. Even custom patterns for internal functions often use the TAP as the primary interface, and the trend is growing with the adoption of IJTAG for plug-and-play control and test of these internal functions.
A few features are necessary to have an efficient scan test through the TAP. One is the use of RPCT (reduced pin count test) so that the die logic is tested as close to the IO pads as possible. RPCT uses boundary scan cells because they are close to the pads and configures them to work as internal scan chains. The next important feature is embedded compression that works off of one scan channel. This is important for controlling the test application time, since the scan tests will use the TAP TDI (test-data in) and TDO (test-data out) as one scan channel. The figure below shows the TAP interface with RPCT and a one-channel embedded compression interface.
Figure 1. Example of a test structure with only the 1149.1 TAP as the test interface. RPCT structure reuses boundary scan cells during scan testing to test close to the IO without contacting them.
Finally, scan control signals such as scan_enable are needed to control the test modes and internal clock controllers for at-speed test. Our three-pin LPCT (low pin count test) embedded compression solution inserts logic to control these signals and has a state machine and counters to know when we are in chain test, scan test, and shifting. However, instead of inserting state machine logic, we can use the TAP as the state machine to reduce the amount of logic inserted for scan test to a very small amount. A special, and highly efficient, LPCT controller is inserted that reuses some functions of the TAP (we refer to as a type-2 LPCT controller).
The common method of at-speed scan test support is to include on-chip clock controllers (OCCs) within the design. The standard method of controlling them is through scan cell loading; ATPG tools automatically understand and decide how to control them. RPCT enables very high stuck-at coverage, so it is possible to achieve high coverage without contacting the functional IO. The boundary scan cells usually are timed much slower than the internal logic, so the interface from internal flop to boundary scan cell would not be tested at-speed. It is possible to perform an at-speed test of this logic, but the boundary scan logic would need to be optimized at the internal clock frequency.
Scan test through a TAP presents an appealing standard configuration, that enables efficient and portable test. Very large designs might still desire many parallel scan channels to keep the test time down.