Reusable Test Strategy for Digital Video Chip

Design reuse greatly improves the efficiency of chip design. In order to keep up with the pace of design, testing must also adopt similar reuse technology. This article takes Philips Semiconductor's PNX8525 Nexperia Digital Video Platform (DVP) as an example to introduce the test reuse and debugging strategy of system chips.

Philips Semiconductors combines the design reuse strategy with the so-called application platform. As long as the platform and its component modules are developed, a series of designs can be developed immediately and quickly. Therefore, the efficiency of testing and debugging must also be improved at the same time to keep pace with the design. Therefore, it becomes increasingly important to reuse existing testing, testability functions and debugging.

Philips' DVP consists of two programmable embedded processor cores: a 32-bit MIPS RISC CPU and a 32-bit very long instruction Trimedia processor (Figure 1). The two processors access external memory through a high-speed memory bus with other building blocks, including MPEG decoders and interface modules (such as UART and IEEE 1394 Firewire).

This digital video platform has two three-state peripheral interface buses (PI buses). One PI bus is connected to the Trimedia processor for video processing, and the other is connected to the MIPS processor for control functions. In addition, there is a PI bus bridge that enables communication between the two PI buses. Using two PI buses here can avoid bandwidth problems caused when both processors are working at full speed.

We defined several test and debugging goals for the Nexperia platform, one of which was to reuse tests whenever possible. Since we created several new applications based on this platform, developing a complete set of test procedures for each independent new application is a very time-consuming task, and its impact should not be underestimated. For several new applications generated in a very short period of time, only test reuse is a viable option to solve the limited time and resources. Another important test goal is to see if the internal behavior of the system can be observed for debugging and diagnosis. If the system does not work properly according to the specifications during the test phase, this performance can greatly reduce the waiting time before the market is released.

PNX8525 is a design example developed on the Nexperia DVP platform, and some of its features are listed in Table 1. Dealing with a large number of clock domains and local memory brings many difficulties to the design for testability (DFT) and design for tunability (DFD) of PNX8525.

The basic DFT architecture of PNX8525 is designed according to the set of rules defined by IEEE P1500 and Virtual Slot Interface Alliance (VSIA), and uses other rules and constraints provided by Philips Core Test Group (CTAG). The DFT of each core follows the CTAG rules and guidelines that define external behavior. There are two types of cores for PNX8525, namely hard cores and soft cores.

Both processor cores on the PNX8525 are hard cores. These embedded processors comply with CTAG rules, which include complete test isolation of the cores, with DFT implemented by the core vendor. All other cores are soft cores, synthesized from RTL, and DFT is part of the soft core integration process. Large cores and reused cores have a test shell that splits scan test pattern generation into "core" and "interconnect" tests, such as MPEG and conditional access decoders and other video/audio cores; small cores do not have a test shell, but are tested as part of "interconnect" testing, such as bus controllers and bridges, general I/O modules, and memory controllers.

Test rail

The CTAG method is superior to the old macro test method because macro testing does not guarantee that macro-level tests can be extended to the chip level, and chip-level test pattern generation is often very time-consuming. When using the CTAG standard, a dedicated test path called a test rail is created at the chip level and connected to the test shell so that test signals and responses can be effectively applied to the core.

All DFT is implemented on the core, and the surrounding scan chains are run through the bus interface module. Each memory is equipped with a scannable memory external structure, separating the test logic and memory scan chains to optimize test time at the highest integration density.

Table 2 lists the testability design results obtained for the PNX8525 core design example. The first six columns are the core characteristics, including the number of flip-flops, embedded memory, scan chains, functional clocks, and constant errors, the seventh column is the constant fault coverage obtained based on the number of test patterns in the eighth column, and the ninth column is the automatic test pattern generation (ATPG) tool run time for each independent core on an HP J-type server.

Thanks to the CTAG core-based test methodology, most cores can achieve 99% constant fault coverage, which can also be maintained after integration. The total constant fault coverage of the entire chip (including core, memory, boundary scan, CPU and functional test) is calculated to be very close to the 99% target. Iddg testing has not yet been finalized, but is expected to be in the milliamp range. Finally, we have developed a system tester for production testing.

Since the PNX8525 is not yet in high volume production, it remains to be determined whether all of these tests will perform to the required quality level. However, reusing existing tests has proven very successful on PNX8525 silicon, with both processor vendors getting it right the first time without any tweaks.

In addition, we have selected two additional debugging methods for PNX8525 design to improve internal observability to facilitate debugging of silicon samples. The first real-time observability allows real-time monitoring of a limited number of internal signals on the chip pins when the chip is in use; the second scan-based observability allows complete status information to be observed after the chip stops working.

These debug features have been implemented in silicon and are used to verify the internal clock generation blocks, diagnose problems related to the internal clocks, and analyze erroneous behavior of general purpose I/O interface blocks. Table 3 lists the silicon area required for testing and debugging on the PNX8525.

The core-based testing approach described above is very important. Although this method requires additional silicon area in the design compared to simply running ATPG, the processing power it provides is critical to the integration complexity of current and future digital chip designs. The benefits of testing far outweigh the cost of silicon area due to increased DFT.