Next: 4 Application Example Up: Appnotes Index Previous:2 Introduction
Next: 4 Application Example
Up: Appnotes Index
Previous:2 Introduction
During early project phases, DFT influences the functional analysis and alternative architecture alternative evaluation and functional analysis through the enabling technology of functional dependency modeling (DM) which examines testability of a system at the functional block diagram level. DM technology defines faults and tests for each system function and permits a parametric analysis of the consequences of limited measurement capability of each of the system functions. The designer uses "What if" analysis to rate the testability performance of alternative architectures and different proposed physical implementations of system functions.
A technology developed during the RASSP program is template based requirements analysis. Templates ensure uniform, unambiguous expression of requirements by an integrated product development team (IPDT) with expertise in the areas of design, manufacturing, and field support. Consolidated test requirements used throughout a project life cycle contain both customer and derived requirements added to ensure quality and producibility in the end product. The system designer is forced to examine each requirement from the viewpoint of eventual quantitative measurement to establish that each requirement is consistent, realizable and valid.
After requirements are defined, a singular test philosophy (STP) applicable to all life cycle phases is designed and expressed in a series of test strategy diagrams (TSDs). As can be seen in Figure 3-1, the TSDs which allocate detection, isolation, and correction requirements across RASSP methodology phases and packaging levels for specific fault classes such as shorts, opens, and single stuck-at faults. TSDs are linked across RASSP phases and upward and downward in the packaging level dimension to implement both requirements distribution and compliance monitoring. Designers at any level interact with the appropriate TSD to confirm or deny the ability of a specific system element (e.g., board) to satisfy its allocated requirements. Contents of a typical TSD are shown below. TSDs can contain prediction, verification, or measured values. One TSD is used for each fault class such as opens, shorts, and stuck-at faults. Quantitative detection, isolation, and correction values are allocated across a series of test means and the total coverage for the fault class being controlled are calculated and displayed. Measurement and verification TSDs for a specific fault class are compared to the related prediction TSD to monitor requirements compliance. As described in the Application Example below, the TSD is implemented as a multisheet Microsoft EXCEL workbook. This format supports reuse by simple modification of TSDs developed on earlier projects to current projects.
As shown in Figure 3-1 and discussed in the Executive Summary, definition of the test strategy is accompanied by the following items:
During design, DFT features such as JTAG strings and FPGA-based board level BIST are simulated on a VHDL testbench and their effectiveness is evaluated. Specialty tools designed to create and manage these features supply VHDL code used in the simulations and the test vectors required for testing during design and after when the design has been reduced to hardware. A technology driver in testability analysis and test feature installation for RASSP DFT was a technology driver in testability analysis and test feature installation and resulted in contributing refinements to commercial test tools (VICTORY, Parallel Port Tester) and development of several new BIST insertion tools (LogicVision). Simulation efforts result in verification of the proposed test approach and generatetest program sets (TPS) which will be used on the actual hardware. Satisfaction of prediction TSD-assigned hardware requirements to system components is verified and the path to actual performance measurement in hardware is established via reuse of the simulation TPS. In addition to Reuse enhancing the likelihood of first pass success for hardware test, and, in addition, reuse results in significant hardware-based test development time and cost economies.
Once simulation is completed, hardware prototypes are produced and physical testing begins. Using test procedures defined in the test architecture definition phase and now verified by the simulation exercises, physical testing is performed. Actual measurements during manufacturing and acceptance testing substantiate the satisfaction of all requirements, and the system is ready for field deployment where it is subject to the pre-established maintenance philosophy defined in the field phase measurement TSDs.
3.0 Technology Description
RASSP Design For Test technology has inserted testability into all phases of the RASSP methodology ( RASSP Methodology Version 2.0) - from system design to field support. This insertion has been accomplished using a combination of existing and modified commercial simulation, CAD, and specialty DFT tools, along with several of the DFT specialty tools were developed during the RASSP program.
The test strategy and architecture result in test plans from which a set of test procedures are developed. RASSP developed the framework to formalize the means needed to implement this test strategy.
Next: 4 Application Example
Up: Appnotes Index
Previous:2 Introduction