Design Techniques Ensure Testable SOCs
IC designers can now choose from an array of simulation and synthesis packages for incorporating testability features into their designs.
Rick Nelson, Senior Technical Editor -- Test & Measurement World, 9/1/1999
| This article includes a large product survey table of DFT and BIST tools and figures which are available by downloading the pdf version. Below is the text of the article. A version of this article ran in the February-March 2000 edition of Test & Measurement Europe. Download the article as a PDF. |
| Systems on chips (SOCs) defy traditional test approaches and make it impossible to establish the demarcation between design and test. For complex digital and mixed-signal devices, you must use design tools that let you incorporate testability early in the design process. Your options include design-for-test (DFT) techniques, which ensure all circuit elements within an SOC can be stimulated and observed, and built-in-self-test (BIST) techniques, which allow a chip to generate its own test stimuli and measure the corresponding responses. Spurred on by the knowledge of test’s importance in SOC designs, design-automation vendors such as Analogy, Cadence, Intusoft, Mentor Graphics, and Synopsys are integrating DFT tools into their simulation and synthesis packages. Other firms, including DS Diagonal Systems, Fluence Technology, Genesys Testware, InterHDL, LogicVision, and Syntest, are offering testability tools for designs that exist in a standard design-description format such as Verilog, VHDL, EDIF, or Spice. These tools evaluate a device’s testability; produce enhanced Verilog, VHDL, or Spice descriptions that incorporate BIST functions; automatically generate test vectors; or simulate faults (see product survey chart in pdf format). Most design-automation suppliers provide tools that are tightly integrated with their simulation environments and that you can invoke early in the design process. Analogy’s SaberScope, for instance, lets you view simulated waveforms of your simulated circuits within the company’s SaberDesigner design-capture and design-simulation environment. SaberScope is sufficiently ecumenical to work within other design environments as well, including Mentor Graphics’ Falcon framework. In contrast, a similar product, Intusoft’s IntuScope, works only within Intusoft’s ICAP/4 schematic-capture and simulation package. Design-automation products can be invaluable early in the design process, but the heavy lifting of DFT comes later on, in the form of BIST circuitry incorporation, scan insertion, test-vector generation, fault simulation, fault-coverage grading, and ATE program generation. For such tasks, you can rely on a traditional CAE vendor, or you can mix and match tools from a variety of vendors. In the former category, Mentor Graphics provides BIST tools such as LBISTArchitect, which generates RTL BIST structures for digital chips having multifrequency clocks (Fig. 1). Similarly, Synopsys offers a set of tools ranging from synthesis with one-step scan insertion to ATPG, fault simulation, and test-vector compaction (Fig. 2). Instead of the one-stop shopping offered by firms like Synopsys and Mentor Graphics, you can choose from among stand-alone ATPG tools, fault simulators and graders, and testability-analysis packages. When evaluating such third-party DFT tools, ask to see relevant benchmark data for designs similar to yours, including specs such as silicon overhead for BIST and scan circuitry, typical fault coverage, and ATPG and fault-simulation times. Fault simulation can be particularly time consuming, and for complex designs you could consider a hardware accelerator such as Provis’s PXP. You can also ask your EDA vendor for recommendations for third-party tools. The Role of ATE The resulting test program for a new device often requires debugging—a time-consuming task that can monopolize expensive ATE, making it unavailable for production test. To help offload test development from ATE, firms including Analogy and IMS are cooperating with ATE vendors to allow program development for virtual devices to take place on virtual ATE. Analogy’s Saber-IC Pro simulator, for instance, supports Teradyne’s Image virtual-test environment, and IMS offers hardware-description-language (HDL) models of ATE from Advantest, Hewlett-Packard, Schlumberger, and Teradyne. You can test your virtual devices—in Verilog or VHDL format—on IMS’s virtual-tester HDL models, debugging your test programs in the process without using real ATE and before you receive first silicon. Beyond IEEE 1149.1 SOC DFT tools evaluate components or blocks of components within SOCs. To complicate matters, many DFT component cores represent vendors’ secret intellectual property (IP), whose details the vendors are loathe to share. Consequently, DFT tools work blindfolded, unable to see the components they are supposed to test. To help overcome the inherent obstacles in such an approach, an IEEE P1500 committee has developed a core test language (CTL). The goal is to allow exchange of test information between providers of core IP and those who integrate various cores within an SOC. A CTL essentially provides a standard set of questions that DFT tools can ask to evaluate the functionality of proprietary cores. The committee plans to issue a report on its CTL in December. Also working to smooth the integration of various IP cores within an SOC is the Virtual Socket Interface Alliance (VSI Alliance), which defines standards to which an IP vendor must adhere in order to claim VSIA 1.0 compliance for a product. The VSI Alliance is currently collaborating with the P1500 group to specify how to handle virtual components employing different test methodologies within one SOC.2. T&MW FOOTNOTES |
