observable point and REG1, REG4, REG5, REG6, and. REG7 as controllable points. That corresponds to a reduction of 22.97 % of the original register area cost ...
SYNTEST: An Environment for System-Level Design for Testy H. Harmanani, C. Papachristou, S. Chiuz, M. Nourani Department of Computer Engineering Case Western Reserve University Cleveland, Ohio 44106
Abstract
This paper describes the design and implementation of SYNTEST, a system for the design of self-testable VLSI circuits from behavioral description. SYNTEST consists of several algorithmic synthesis tools for scheduling, testable allocation, and optimum test points selection. A key feature in SYNTEST is the tight intercation between the system tools: the scheduler, the allocator, and the test tool. The system uses a technology library for optimizing the original structure. All tools interact with each other as well with the user through an X graphical interface. This provides a better design environment and allows for more designer intervention.
1 Introduction
Design and Test are commonly viewed as being two
sides of the same coin [2]; due to the complexity in current VLSI technology, both processes are partitioned into corresponding hierarchical levels. Three well de ned top-down levels of the design and test hierarchy are the system (RTL), the logic gate, and the layout levels. The design process is quite mature at the logic and layout levels due to many existing professional tools for design synthesis and simulation. Again, because of this complexity, the eld of high-level synthesis (HLS) has recently emerged to address the need for design methods and techniques at the RTL level. Currently there are several such tools that have appeared [9, 18, 6], but the HLS area is not mature yet [5]. Just as with the design, the test process, particularly test generation, has matured at the logic gate and circuit levels. For example, there are several tools for test generation, including some recent ones based on logic synthesis techniques [1]. However, the diculty in testing complex circuitry is due to limited controllability/observability of gate-level modules in complex chips. This problem can be alleviated by design for testability (DFT) techniques such as scan design and BIST (Built-In-Self-Test). Two points have become clear: a) DFT is particularly important at the RTL or system level of the hierarchy to achieve good test y This work is supported in part by the Semiconductor Research Corporation (SRC) under contract 91-DJ-147. z Author's current address: Hitachi Microsystems Inc., San Jose, CA 95134.
quality [21], b) DFT increases the chip cost due to test hardware insertion (scan or BIST registers). Thus, there are tradeo s between the design and the test processes which can be best addressed if both processes are integrated in a system level design environment. However, traditional design and test methodologies at the system level have always separated the two processes. Test design is usually done as a post-design process, i.e., after the the completion of the design process. Although this approach may work for small circuits; it may require costly design modi cations at the register-transfer level (RTL). The purpose of this paper is to report on SYNTEST, a system level synthesis and test environment. The motivation for SYNTEST has been the need to integrate design and test at the system level, a need well recognized by the design and test communities. Based on a structural testability model trading o design and test, SYNTEST generates testable RTL circuits from input behavioral speci cations subject to design and test constraints. The system includes a user interface which provides an e ective feedback and interaction tool. Thus, moving from an iterative design synthesis environment to an interactive one. Section 2 describes the SYNTEST methodology and testability model. In section 3 we describe brie y the main component tools comprising SYNTEST. The system graphical interface is described in section 4. A walk through design example is discussed in section 5 while results are discussed in section 6.
2 The SYNTEST System: Approach
High level synthesis is the design and implementation of digital circuits from a behavioral description that describes the function to be performed in an algorithmic form given a set of goals and constraints. From the input speci cation, the synthesis system produces a description of a data path. One of the main tasks of high-level synthesis is to nd the structure that best meets the constraints while minimizing other costs [5]. SYNTEST deals with a new approach to high-level synthesis with self-testability. What distinguishes our approach from other high-level synthesis systems is the consideration of testing cost (test time and overhead) in addition to the conventional constraints (area and performance) during the design process. The SYNTEST system, whose block diagram is shown in Figure 1, operates on a behavioral input descrip-
Figure 1: SYNTEST General Organization tion and generates structurally testable RTL designs including optimal selection of test points (test registers). Currently, we have implemented a design path for BIST methodology. However, other test methodologies are currently under development especially deterministic testing using symbolic test pattern generation [11, 19]. At present and in the following we assume a test register is a LFSR which may be con gured, in circuit test mode, as either a test pattern generator register (TPGR), a multiple input signature register (MISR), or possibly a BILBO register [10]. There are two important aspects underlying the SYNTEST system: A structural aspect based on a structural testability model at the register-transfer level. A functional aspect based on the module design and function as well as on its test characteristics.
The key element of the structural testability model is the Testable Functional Blocks (TFBs) which consist of a combinational block and a register at the output. The TFB structure is directly related to the DFG nodes. Thus, the operation will be mapped to the ALU of the TFB and the DFG variable to the register at the TFB output. The basic requirement of the structural testability model is that it does not allow I/O self loop that involve a TFB port and the same TFB's register. This is because we cannot use the same register both as a TPGR and an MISR simultaneously in a loop. By de nition, designs following this rule are labeled strictly structurally testable designs; the generic design a shown in Figure 2(a) is such a design. To improve area and performance we may relax this TFB connection rule as shown in Figure 2(b) for the generic design b. Designs following this relaxation of the I/O rule are called loosely structurally testable designs (in the sense that the MUX at the left input port of design b is not testable). Note designs in which the I/O rule is totally violated such as Figure 2(c) are called non-structurally testable designs and are not acceptable by SYNTEST. The rationale for considering loosely structurally testable designs is that they provide a good tradeo be-
Figure 2: Illustrating the structural testability notion with di erent designs tween design cost and testability cost. In other words, design a is better than design b and c in terms of testability, but c may well be superior to b and a in area cost. Design b is a compromise between a and c, and it may well be a good compromise in the following sense. Transforming designs from type a to type b is a relatively easy process within our testable allocation scheme, by simply relaxing the I/O constraint. However, we claim that moving designs from type c to type b is considerably more dicult because of the testability requirements that may involve costly modi cations. The second important aspect of SYNTEST concerns the exploitation of the logic module (ALUs) characteristics during allocation with the following objectives: (a) reduce BIST hardware overhead (test registers) while satisfying fault coverage requirements; (b) tradeo BIST cost with module (ALU) operator cost during high level synthesis; (c) provide testability estimation, such as fault coverage and number of test patterns, during the system level design process.
3 The SYNTEST System: Overview
SYNTEST takes a behavioral description which could be expressed in VHDL and performs various synthesis tasks such as scheduling and data path allocation. We discuss next the main components in SYNTEST including the scheduler, the allocator, and the test and design estimation tools.
3.1 Scheduling Tool in SYNTEST
Scheduling assigns operations to control steps so as to minimize a given objective function while meeting the constraints [5]. The scheduling phase determines the
hardware cost-speed trade-o s of the design, and has been proven to be NP-complete. Thus, heuristics are introduced to obtain a fast schedule with respect to time required to execute the original code sequence or a balanced schedule with respect to operations concurrency. To implement an appropriate scheduler in our system the following requirements were sought: 1. It should be fast so that to allow the designer to explore various design possibilities in relatively short turnaround time. 2. It should be able to incorporate our test constraints easily so that to yield a schedule suitable to our testable allocation scheme. 3. It should be able to optimize the schedule under time or hardware constraints and handle di erent synthesis applications. Based on the above requirements, we have developed the Move Frame Scheduling (MFS), which is the main scheduling tool in SYNTEST. In addition, SYNTEST currently supports As-Soon-As Possible, As-Late-AsPossible and Forced-Directed Scheduling [17] for comparison purposes, and in fact can support any scheduling method. The MFS scheduling method [13] uses a transformation technique between the scheduling space and the dynamic system space and designates moves in the scheduling space which correspond to moves towards the equilibrium point in the dynamic system space in order to generate a well balanced schedule. The main advantage of this scheduling method over known techniques is its speed in searching the design space and providing alternative solutions. The MFS tool schedules any given data ow graph under xed time or hardware constraints and supports various synthesis applications such as mutually exclusive operations, loop folding, multi-cycle operations, chained operations, structural and functional pipelining.
3.2 Testable Data Path Allocation
Once the behavior has been scheduled, SYNTEST allocates hardware by binding operations to ALU's, variables to registers, and establishing connections between them. Our allocation method merges the data ow variables simultaneously with the motivation to generate easily testable, regularly structured data paths [3, 16]. The allocation method interacts with the SYNTEST design and test cost estimation tools described next.
3.2.1 Data Path Allocator
The allocation phase in SYNTEST is a stepwise re nement process guided by the di erence in data path cost between two consecutive iterations. The allocator rst maps the generated schedule to an initial data path structure. Thus, every operation is mapped initially onto an ALU and its variables are mapped to a register; the connections are established consequently. The allocator chooses all initial register con gurations to be both TPGR and MISR (section 2). Clearly, the allocator's task is to optimize this initial data path structure by merging all compatible TFBs (section 2) into more complex ones while, at the same time, selecting a TPGR and an MISR for every TFB, and
removing all unnecessary TPGR and MISR. We note here that two TFBs are compatible if it is possible to merge them without causing a resource con icts or creating self-loops [8]. All intermediate information are stored in a multitree graph that we call module allocation graph (MAG). At every iteration, based on the test and design estimation tools, the allocator selects two TFBs from the MAG and merges them in the intermediate data path. The data path cost is estimated using the notions of gains and losses based on a synthesis algorithm described in [16].
3.2.2 Design Cost Estimation Tool
The design cost estimation tool predicts the cost of selected components to be shared among di erent modules. The process produces estimation in terms of gain and loss in the data path which we have introduced in [16]. The gain gives a measure of the reduction in the data path cost at every iteration while the loss measure is a lookahead indicator during the same process. The gain at every stage consists of the sum of the following three types of gains: 1. ALU Gain: The ALU gain depends on the function of the newly merged or created ALU. The gain in this case is equivalent to removing the two original ALU operation sets, A and B and adding a new ALU with operation set C such that: C = A [ B . For example, when the two operation sets f+,*g and f*g are merged, one multiplier is saved (or gained). 2. Multiplexer Gain: The multiplexer gain in SYNTEST is computed incrementally at every merging step by performing incremental register alignment. When two TFBs are merged, all the operands of the merged TFBs must be routed to the ports of the newly created one. The overall cost may increase or decrease depending on the nal MUX con guration since this may require the addition of a new MUX (or additional mux inputs) at the port of the new TFB. Thus, the gain in this case encourages the merging of TFBs with the same operands or with a cheaper interconnect cost. 3. Register Gain: The register gain results from merging two registers into one single register. Thus, it is equivalent to the cost of one single register. However, this cost varies and depends on the nal implementation of the register, i.e., whether it is a test point or not. This decision depends on the test cost estimation tool discussed next.
3.2.3 Test Cost Estimation Tool
SYNTEST currently supports the BIST methodology based on Linear Feedback Shift Registers for random pattern generation and signature analysis. Based on a system level testability model described next, this cost estimation tool: 1) predicts the controllability and the observability within the intermediate data path generated; 2) selects system registers to be converted into either test pattern generators or signature analyzers. The Test Cost Estimation Tool chooses a controllable and an observable point for each port in the design. The tool makes use of the functionality of the
individual modules and explores possible trade-o s between testing and hardware overhead. The basic tradeo model in SYNTEST is to assign a controllable or an observable point if: 1) the inputs to the module are not random enough; 2) the fault e ects of this module can not be sensitized through intermediate modules to an observable point. The above conditions are checked in SYNTEST by means of the following measures, presented in detail in [4]: Transparency Measure: This measure is an estimate of the fault propagation ability of the underlying module. A probabilistic approach was used here to decide whether a given register should be observable or not. Output Randomness Measure: An informationtheoretic approach was used in order to determine whether a given register in the circuit need be controllable or not. Two measures were developed here: 1) a randomness measure to check whether the module output patterns are random enough; 2) a uniformity measure to test whether the module can generate all possible patterns. The result of this estimation is to obtain the test cost of the desired design points.
4 The User's End View
SYNTEST supports a graphical interface that provides an ecient means for interaction between the designer and the system. This provides a better design environment for feedback and interaction with the system. Thus, moving the designer from an iterative synthesis environment to an interactive one. The general aspects of the system interface are discussed next.
4.1 Graphical Interface
The SYNTEST system is supported by an X Window graphical interface that solicits feedback and design decisions at various stages while keeping the designer informed on various decisions. The graphics interface supports one level pull-right windows to select among the various major components of the system, and to set up various options related to the speci c tools. The system also supports dialog boxes for all the operations that require text inputs and feedback. Zoom in and zoom out functions are also provided at various levels in the user interface. At any phase during the design stage, any window can be spooled to a PostScript le or to a PostScript printer in order to generate a hardcopy. The system graphics interface supports on-line help for the various design steps, and which is critical for those exploring the system or users using the system for the rst time. The system supports an e ective error recovery and report mechanism.
4.2 Design Representation
The initial behavior to be designed is represented using VHDL. This enables the user to verify the behavior functionality before proceeding in the design stage. Since VHDL will be translated into an intermediate data ow representation, the user can specify directly the behavior using the intermediate data ow graph description. The design constraints are speci ed at various stages of the design process using dialog boxes.
4.3 User Interaction with SYNTEST
The user interacts with SYNTEST through the graphics interface. Once the system is started, the system main window frame appears. The frame contains four options (buttons), notably the behavior, scheduler, allocator, and the register-transfer level optimizer. The user will have initially to choose the behavior description le that he or she intends to implement. The behavior option will generate an intermediate le to be fed to the scheduler. We will discuss the scheduler, allocator, and RTL optimizer graphics options next.
4.3.1 User Interaction with the Scheduler
Once the scheduler is selected, a pull-right option, menu appears and the user can select a new data ow graph le to schedule; otherwise, the le speci ed in the behavior step is selected. The user can specify some initial constraints such as the number of control steps, the type and number of cycles available for the design, and the scheduling type, normal or pipelined. Finally, a scheduling method can be selected from the methods available in the system. If none of the previous options are speci ed, the system selects the MFS scheduling method by default, and assumes that all operations take one control step. The user can then run the system and generate the schedule which can be shown graphically. At this stage, the manual rescheduling option allows the user to reposition the scheduled objects (nodes) anywhere between their successors and their predecessors using the mouse. The structure of the original schedule is maintained, and all relations (data dependencies) to the selected object follow the mouse movement as well. The modi cations can be saved in a le with the same or di erent name as the original schedule to be used by the allocator in the next step.
4.3.2 User Interaction with the Allocator
Once the initial behavior has been scheduled, the hardware resources for the operations. A schedule le is read for processing; otherwise, the system uses the current schedule. The user will have to select a technology library on which the allocator will base its decisions and optimization techniques. Furthermore, the user can also relax the structural testability design style, i.e., the self-loop constraint imposed during the merging process (section 3.2), and explore test trade o s in the system. The rst step in the allocation is to generate the module allocation graph. The module allocation graph can be shown graphically as well. In the next step, the RTL generator is invoked to execute the nal step, i.e, the optimization process. The system requests the optimization parameters, meaning whether to optimize the ALU cost, MUX cost, the register cost, or a combination of the previous parameters. In addition, the test point selection option can be selected as well. The system maps the schedule to an initial data path to be optimized next. At every step, SYNTEST, based on the estimation tools, chooses two TFBs from the MAG, and merges them in the data path. The optimization process can be traced graphically using the trace command and can thus follow the system design decisions step by step by looking at evallocator option can be invoked in order to allocate
Figure 3: The Hal Di erential Equation Scheduled using MFS
Figure 4: The HAL di erential equation after 5 iterations, using the trace option
ery intermediate data path structure. This provides a better feel for the design process as well as a better understanding of the system decisions. At this stage, SYNTEST generates a symbolic control table for the circuit under design, as well as a test plan for every TFB. Note that we use the term test plan here in the context of which registers will be used to test a given TFB, and the hardware con guration of all such registers. The user can obtain such information by clicking on the design entity.
5 A Walk Through Design Example
Previously, we discussed the various tools comprising SYNTEST; mainly the scheduling tool, the testable allocation tool and the system graphical interface. This section will attempt to describe how to put all together by going through the design process using a design example, the Di erential Equation Solver from HAL. The HAL benchmark solves a second order di erential equation and was presented initially by Pauline [17] and subsequently used by researchers for comparison purposes. The initial behavioral description is represented in a value-trace like notation. The rst step in the design process is to schedule the code sequence generated by the parser. The constraints are speci ed using dialog boxes. For this example, we decide to schedule it in four control steps, and assume all operations are executed in one cycle only. A scheduling method is chosen next, and for this speci c example we chose MFS. Once the DFG is scheduled, it can be displayed as shown in Figure 3. The schedule, as it is clear from the graph, is very well balanced; however, it should be noted that the number of concurrent operations does not give a good indication as to the number of ALUs required to compute these operations due to the additional test constraints imposed on the SYNTEST allocator. Once the schedule has been derived, and displayed on SYNTEST graphics interface, one of the useful options we can use is manual rescheduling to manually explore various alternative schedules.
Figure 5: The HAL Solution without test points selection
Figure 6: The HAL Solution with test points selection
References
Figure 7: Reduction in test register cost for the benchmark examples In the next step, we select the allocator option to allocate hardware resources to our example. The rst step is to generate the module allocation graph. For this speci c example, we optimize the area cost of registers, muxes, and ALUs, without test points selection. Note that the solution is still suitable for testing, i.e., has enough registers to be con gured as test registers. In this case, registers REG1, REG2 and REG3 are con gured as BILBO registers (both controllable and observable) while the remaining input registers are con gured as controllables only. The intermediate data path, after ve iterations, is shown in Figure 4. The nal data path is shown in Figure 5. The same example was run for the second time with the the test points selection option being selected. SYNTEST allocator selects test registers for every module while optimizing registers, ALUs, and MUXes area cost. The nal data path generated in this case resulted in a new binding along with the test points as shown in Figure 6. The system allocates REG2 as an observable point and REG1, REG4, REG5, REG6, and REG7 as controllable points. That corresponds to a reduction of 22.97 % of the original register area cost.
6 Results
We did run various benchmark design examples for illustration purposes. These are the Facet example [20], the bandpass lter [15] for control step 8, the temperature controller from MAHA for control step 7 [14], the AR lter [9] for control step 8, and the fth order elliptical wave lter [17] for control step 17. Note that no ROM coecients were used in these examples. The results are shown in gure 7. For every example we show the reduction percentage in area for the test registers. All examples show signi cance improvement ranging from 21 % in the case of the Facet circuit to a signi cant 31 % in the case of wave lter. All areas were computed in micron square and based on the NCR library [12].
[1] \Testing Strategies for the 1990s," Panel Discussion, Design Automation Conf., 1990. [2] V. Agrawal, Plenary Speech, Inter. Conf. on Computer Design (ICCD), October 1991. [3] M. Abadir, M. A. Breuer, \A Knowledge-Based System for Designing Testable VLSI Chips," IEEE Design & Test, pp. 56-68, August 1985. [4] S. Chiu, C. Papachristou, \A Design for Testability Scheme with Applications to Data Path Synthesis," Proc. 28th Design Automation Conf., June 1991, pp. 271-277. [5] M. McFarland, A. Parker, and R. Composano, \The High Level Synthesis of Digital Systems," Proc. IEEE, Vol. 78, No. 2, February 1990, pp. 301 - 318. [6] J. Lis, D. Gajski, \Synthesis from VHDL," Inter. Conf. on Computer Design, 1988, pp. 378-381. [7] C. Gebotys, M. Elmasri, \VLSI Design Synthesis with Testability," Proc. 25th Design Automation Conf., June 1988, pp. 16-21. [8] C.L. Hudson, G.D. Peterson, \Parallel Self-Test with Pseudo-Random Test Patterns," Proc. International Test Conf., pp. 954-971, Sept. 1987. [9] R. Jain, K. Kukukcakar, M. Mlinar, A. Parker, \Experience with the ADAM synthesis system," Proc. 26th Design Automation Conf., June 1989. [10] B. Koenemann, J. Mucha and G. Zwieho , \Built-In Logic Block Observation Techniques," Proc. International Test Conf., pp. 37-41, Oct. 1979. [11] J. Leenstra, L. Spaanenburg, \Hierarchical Test Assembly for Macro Based VLSI Design," Proc. Inter. Test Conf., pp. 520-529, 1990. [12] The NCR ASIC Data Book, 1989. [13] M. Nourani, C. Papachristou, \Move Frame Scheduling and Mixed Scheduling-Allocation for the Automated Synthesis of Digital Systems," Proc. 29th Design Automation Conf., June 1992. [14] A.C. Parker, J. Pizarro, M. Mlinar, \MAHA: A Program for Data Path Synthesis," Proc. 23rd Design Automation Conf., pp. 461 - 466, June 1986. [15] C. Papachristou, H. Konuk, \A Linear Program Driven Scheduling and Allocation Method Followed by an Interconnect Optimization Algorithm," Proc. 27th Design Automation Conf., June 1990, pp. 77-83. [16] C. Papachristou, S. Chiu, H. Harmanani, \A Data Path Synthesis Method for Self-Testable Designs," Proc. 28th Design Automation Conf., June 1991, pp. 378-384. [17] P. Paulin, J.P. Knight, \Forced-Directed Scheduling in Automatic Data Path Synthesis," Proc. 24th Design Automation Conf., pp. 195-202, June 1987. [18] J. Rabaey, H. DeMan, J. Vanhoof, F. Cathoor, \Cathedral II: A Synthesis System for Multiprocessor DSP," In Silicon Compilation, pp. 311-360, 1988. [19] J. Sas, F. Catthoor, P. Vandeput, F. Rossaert, H. DeMan, \Automated Test pattern Generation for the Cathedral-II/2nd Architectural Synthesis Environment," Proc. of The EDAC, pp. 208-213, 1991. [20] C. Tseng, D. P. Siewiorek, \Automated Synthesis of Data Paths in Digital Systems," IEEE Transactions on CAD, V. CAD-5, No. 3, pp. 379-395, July 1986. [21] T. Williams, K. Parker, \Design For Testability | A Survey", Proc. of The IEEE, Volume 71, Number 1, January 83, pp. 98-112.
