Testers must connect to device pins, but each additional pin that connects to a device increase test complexity, reduces the ability to test multiple devices in parallel, and contributes to probe-induced deterioration. Thus, there are significant advantages in reducing the number of pins used for test.
At one time, you could divide the scan-test application time by the number of serial-scan channels. That significantly changed when embedded compression was introduced because very efficient scan patterns could be applied with just one serial-scan channel pair connected to the tester. Embedded compression is often referred to as low pin count test (LPCT). This solves the issue of contacting the tester scan interface, but what about testing all the functional IO pins, which could number over 1000 in modern devices?
You can turn to IEEE standard 1149.1 boundary-scan cells for a solution to accessing functional IOs during scan tests, and to provide a few basic IO tests without contacting any of the functional IO pins. Boundary-scan cells are often used for board-level test. Because they're placed between functional logic and the IO pad, boundary-scan cells provide an ideal location for test access. Once placed at each functional IO pin, they can be configured to behave as normal scan chains and included during embedded compression scan tests. We call this virtual access to IOs a reduced pin count test (RPCT) strategy. A tester doesn’t connect to any of the functional IO pins and only needs to connect to the 1149.1 TAP (test access port) as shown in Figure 1. The result is a device that can be thoroughly scan tested with an interface of as few as four or five pins. The only basic test that is missing is a test between the boundary scan cell and the IO pad.
You can test the IO pads and perform leakage tests at the functional IOs using the boundary-scan cells and only contacting the TAP [target="new">Sunter, ITC 2002]. This involves placing a bidirectional boundary scan cell at each functional IO. It is easy to perform a basic IO wrap test to confirm that the enable, driver, and receiver are functional. You can also perform a contactless leakage test using the boundary scan cells where the tester contacts only the pins of the 1149.1 TAP controller. The test sequence is automated with boundary scan tools to set a value, tristate the driver, and measure the input to see if there was too much leakage. Here are the steps that an automated test performs and as shown in Figure 2:
- The boundary scan logic is used to assert a logic 1 from the data-out driver to the IO pad.
- A 0 is loaded into the driver enable boundary scan cell.
- The TAP state machine update_dr will apply the logic zero on the enable cell to tristate the driver. This causes the value on the pad to start to dissipate, eventually becoming a logic 0
- Within two and a half test clock cycles (or more) the TAP state machine will enter capture_dr and capture the pad value on the data in the boundary scan cell. Thus, 2.5 test clock cycles can be used to define a minimum acceptable leakage time and the captured value is shifted out for verification.
Figure 2. A contactless leakage test uses a bidirectional boundary scan cell. The “Data” cell is pre-charged with a 0 or 1 value (1 in this example) and a 1 is loaded to the EN cell. Then a 0 is loaded in the EN cell and applied. This causes the data value on the pad to dissipate. If there is too much leakage, then you see the red curve and the opposite value (0 in example) will be captured on the IN cell.
You can calculate or characterize the expected amount of leakage using a known-good device. Then, you can adjust the number of TCK clock cycles between update_dr and capture_dr by adding cycles in the TAP run-test/idle state to capture the data-in value while it is expected to still be at the initialized value under normal leakage conditions. If there's too much leakage then the opposite value will be captured.
So the contactless-leakage test enables a leakage test without adding any special hardware to the circuit. It only uses the boundary-scan logic, TAP interface, and automated pattern generation. You can verify the output enable in a related test. Using the boundary scan logic as in the leakage test, the enable test will drive a value on data out, tristate the enable, set the opposite value on the data out cell, and measure that the original value is still present on the pad. If the enable is functioning then the opposite value would be measured.
All the tests mentioned above can be applied and measured using only a device TAP interface. The functional IO does not need to be contacted. With the increasing need to perform more thorough wafer test, we can expect to see growing usage of these test methods. They are included in the TSMC 3D reference flow to both provide a more thorough pre-bond test as well as provide a test method for partially bonded 3D devices.