Design Article
Digital Video IC Set For Debugging Ride
Bart Vermeulen, Steven Oostdijk and Frank Bouwman
2/1/2002 12:34 PM EST
With the decreasing feature sizes of state-of-the-art process technologies, design teams are faced with the challenge of quickly and efficiently mapping high-level functions onto a growing number of available transistors. Design teams adopt design reuse methodologies to keep up with new processes.
Within Philips, a strategy of design reuse is combined with so-called application platforms, which enable quick development of derivative designs once the platform and its building blocks have been developed. Similar productivity improvements must be implemented in the test and debug environment in order to keep up with the design environment. Consequently, reuse of existing tests, design-for-testability features and debug is becoming increasingly important and necessary [1] [2].
In this article, we describe the test and debugging strategy for the PNX8525 Nexperia Digital Video Platform system chip. Philips Semiconductors' DVP is made up of two programmable embedded processor cores: currently, a 32-bit MIPS RISC CPU and a 32-bit Philips very long instruction word Trimedia processor. Both processors and many of the other building blocks have access to external memory via a high-speed memory bus. Examples of other building blocks are MPEG decoders and interface modules (e.g., UARTs and IEEE 1394 Firewire).
The Digital Video Platform has two tristate peripheral interface buses (PI buses). One PI bus is connected to the Trimedia processor and is dedicated to video processing. The other PI bus is connected to the MIPS processor and is dedicated to control functions. A PI bus bridge enables communication between the two PI bus domains. Having two PI buses avoids bus bandwidth problems when both processors work at full speed.
Several test and debug goals were defined for the Nexperia platform. One very important goal is the ability to reuse tests wherever possible. Several derivatives will be created based on the platform. The generation of a full test program for each individual derivative is normally a very time-consuming task that should not be underestimated. When several derivatives are generated in a short time period, reuse of tests is the only viable option that can deal with the limited availability of time and resources. Another important goal is the ability to observe the internal behavior of the system for debug and diagnostic purposes. That ability can result in significant time-to-market reductions if the prototype system does not behave according to its specifications.
One of the derivatives based on the Nexperia DVP platform is the PNX8525 [3]. The characteristics of the PNX8525 are shown in Table 1.
Dealing with the large number of clock domains and local memories poses a challenge for design-for-testability (DFT) and design-for-debug (DFD).
The basic DFT architecture for PNX8525 is derived from the set of rules defined by both IEEE P1500 and Virtual Socket Interface Alliance (VSIA). Additional rules and constraints from Philips' Core Test Action Group (CTAG) are also used. The DFT for each core follows the CTAG rules and guidelines that define the wrapper behavior. For PNX8525, two types of cores are identified: hard and soft cores.
Both processor cores on PNX8525 are hard cores. These embedded processors comply with the CTAG rules, which include full test isolation of the core. DFT is implemented by the core provider.
The other cores are all soft cores, synthesized from RTL. DFT is part of the soft core's integration process. Big cores and cores that are reused get a test shell that allows partitioning of the scan test pattern generation into a "core" and "interconnect" test [4]. Examples are the MPEG and conditional-access decoders and the other video/audio cores. Small cores do not have a test shell but are tested as part of the "interconnect test." Examples are the bus controllers and bridges, the general-purpose IO module and the memory controller.
Test rail
The advantage of the CTAG approach over the older Macro Test [5] [6] is that Macro Test did not guarantee that a macro-level test could be expanded to the chip level. In addition, the generation of chip-level test patterns was often a time-consuming task. Using CTAG standards, a dedicated test path, called test rail, is created at the chip level and connects to the test shells, allowing test stimuli and responses to be efficiently applied to the cores [7] [8].
With all DFT implemented on a core, the surround scan chain runs through the bus interface modules. Each memory is fitted with a scannable memory wrapper. Scan chains for testing logic and memory are left separated, to enable test time optimization at the top integration level.
Table 2 lists the design-for-testability results obtained for a representative set of PNX8525 cores. The first six columns list the characteristics of the individual cores: the number of flip-flops, embedded memories, scan chains, functional clocks and stuck-at faults. Column 7 lists the stuck-at fault coverage achieved with the number of patterns given in Column 8. Column 9 lists the run-time for the automatic test pattern generation (ATPG) tool for each of the individual cores on an HP J-class server.
Most cores reach more than 99 percent stuck-at fault coverage, which is retained after integration, because of the CTAG core-based test methodology used. The overall fault coverage for the complete chip, including core, memory, boundary scan, CPU and functional tests, is calculated to be very close to the 99 percent goal. Iddq measurements have not been finalized but are expected to be in the milliamp range. Finally, a system tester has been developed that will be used for production test.
The precise influence of all these tests in meeting the required ppm levels is still to be determined, since the PNX8525 is not yet in high-volume production.
But reusing existing tests has already proven very successful on PNX8525 silicon. The tests delivered by both processor providers worked correctly the first time, without modification.
Two complementary debug approaches to increase the internal observability were chosen for the PNX8525 design to facilitate debugging of prototype silicon.
The first, real-time observability, allows a limited set of internal signals to be monitored in real-time on chip pins while the chip is in the application. The second, scan-based observability, allows the complete state information to be observed after the chip has been stopped.
Those debug features have been demonstrated on silicon and thus far have been used to verify the internal clock generator module, diagnose problems with the internal clock and analyze the faulty behavior of the general-purpose I/O interface module. Table 3 provides an overview of the silicon area required for the test and debug functionality on the PNX8525.
To keep up with the increased productivity in the design environment as a result of design reuse, the test environment has to adopt similar reuse techniques. The CTAG methodology includes an efficient reuse technique for existing core-level tests.
A core-based test methodology, such as the one described, is an important step forward. Although the scheme required additional silicon area compared with a flat ATPG run on the entire design, the ability it provides to handle the design-integration complexity of current and future digital chip designs is essential. The benefits for test thus outweigh the silicon-area costs of added DFT.
---
References
[1] Y. Zorian, E-J. Marinissen and S. Dey, "Testing Embedded-Core Based System Chips," Proceedings, International Test Conference, pp. 130-143, October 1998 (IEEE Computer Society Press, Washington).
[2] B. Vermeulen, S. Oostdijk and F. Bouwman, "Test and Debug Strategy of the PNX8525 Nexperia Digital Video Platform System Chip," Proceedings, International Test Conference, pp. 121-130, 2001.
[3] S. Dutta, R. Jensen and A. Rieckmann, "Viper: A Multiprocessor SoC for Advanced Set-Top Box and Digital TV Systems," IEEE Design & Test of Computers, Vol. 18, No. 5, pp. 21-31, September-October 2001.
[4] E.J. Marinissen and M. Lousberg, "The Role of Test Protocols in Testing Embedded-Core-Based System ICs," Proceedings of the IEEE European Test Workshop, May 25-28, 1999 (IEEE Computer Society Press, Konstanz, Germany).
[5] F. Beenker, B. Bennetts and L. Thijssen, "Testability Concepts for Digital ICs-The Macro Test Approach," Frontiers in Electronics Testing, Vol. 3 (Kluwer Academic Publishers, Boston, 1995).
[6] F. Bouwman, S. Oostdijk, R. Stans, B. Bennetts and F. Beenker, "Macro Testability; The Results of Production Device Applications," Proceedings, International Test Conference, pp. 232-241, 1992.
[7] R. Arendsen and M. Lousberg, "Core Based Test for a System on Chip Architecture Framework," Digest of Papers of the IEEE International Workshop on Testing Embedded Core-Based Systems, paper 5.1, pp 1-8, Washington, October 1998.
[8] J. van Beers and H. van Herten, "Test features of a Core-Based Co-Processor Array for Video Applications," Proceedings, International Test Conference, pp. 638-647, 1999.
Researcher Bart Vermeulen, in Eindhoven, and DFT team leader Steven Oostdijk, at Philips Semiconductors in Silicon Valley, work with Frank Bouwman, who manages the Valley's Design Technology Group (DTG). All three authors hold MScEE degrees from universities in the Netherlands.
Copyright 2002 CMP Media LLC
2/1/02, Issue # 14152, page 32.



