JP4332680B2 - Testability design system - Google Patents

Description

The present invention relates to a design for testability system, specifically, when performing the test of a large scale integrated circuit by the built-in self-test mechanism logic, controllability at the stage of hardware functional description architecture independent -It relates to technology for confirming observability.

When an integrated circuit becomes large-scale and performs complex operations, the work time for creating a test pattern for testing the integrated circuit increases, and in some cases, the design time of the integrated circuit may be exceeded. .
Therefore, for large-scale integrated circuits, design for testability (DFT), in which means for facilitating test generation and execution in advance from the logic design stage, is indispensable.

  In recent years, this DFT technology uses built-in self-test (BIST), which incorporates a circuit that automatically tests in an integrated circuit, and checks on-site during production and subsequent operation. Therefore, an efficient test can be performed.

Since BIST is performed within each chip, the restriction on the test sequence length is relatively loose, but the increase in chip area must be suppressed as much as possible. Therefore, a 100% test and a random test that can generate a test sequence with simple hardware such as LFSR (Linear Feedback Shift Register) are representative methods. In addition, the output response is not compared with the normal value each time, but is compressed using a multi-input LFSR and then compared with the reference value (signature analysis) (see Patent Document 1 and Patent Document 2). ).
JP-A-5-241882 Japanese Patent No. 2711492 JP-A-6-103101 JP-A-8-15382

Conventionally, in the design flow of test design by Logic BIST (Logic Built-In Self Test) in an integrated circuit, first, a technology-dependent netlist is generated by logic synthesis from an architecture-independent hardware function description. In addition, after adding a scan path test mechanism and a LogicBIST controller to this, the failure detection rate is confirmed by a failure simulator.
If the failure detection rate is low, check the controllability and observability based on the failure simulator report and netlist, and add the test circuit and, in some cases, change the hardware function description that does not depend on the architecture.

According to such a conventional Logic BIST, the following problems occur.
(1) Controllability and observability can be confirmed after execution of the fault simulator, and the execution time of each CAD tool is required in each process of logic synthesis, scan path, insertion of LogicBIST controller, and execution of the fault simulator. is there.
(2) Controllability / observability is difficult to analyze because it has to be confirmed by a technology-dependent gate level netlist.
(3) It is difficult to reflect the controllability / observability analysis results in the hardware function description independent of the architecture.
(4) If a test circuit is inserted into the netlist after analyzing the controllability / observability, the hardware timing is degraded.

On the other hand, Patent Document 3 and Patent Document 4 show Logic BIST by LFSR.
The technique of Patent Document 3 performs testability analysis on a gate-level netlist for the purpose of improving the failure detection rate.
However, it does not analyze testability at the level of hardware function description that does not depend on the architecture.
The technique of Patent Document 4 relates to a countermeasure against X (signal state is undefined) propagation violation in LogicBIST and a countermeasure to be taken for a gate level netlist when reducing the number of random number generations, and depends on the architecture. The X propagation check is not performed at the hardware function description level.

The present invention has been made in order to solve the above-described problems , and is designed to facilitate testability by performing controllability / observability analysis at the stage of hardware function description independent of architecture. The purpose is to provide.

In order to solve the above-mentioned problem, the testability design system according to claim 1 of the present invention includes an input means for inputting function description data defining hardware functions in an architecture independent format, and the function description data. A register variable recognizing means for recognizing a register variable that can be guessed by a memory element therein, a constraint setting means for setting a constraint for executing LogicBIST, and a random number generation for applying a random number to the register variable recognized by the register variable recognizing means Means, a simulator for simulating an event caused by the application of the random number, and a cause of the failure detection rate decrease by LogicBIST from the toggle rate / event occurrence rate of variables, nets, buses, etc. in the function description data according to the result of the simulation And analyzing means for analyzing The constraint setting means, in the case where in combination with JTAG (Joint Test Action Group) boundary scan test, before a random number generator for JTAG RUNBIST instruction, the constraint setting means constrained setting sequence LogicBIST execution It is characterized in that constraint setting is performed by giving .

According to the present invention, it is possible to confirm the simulation status when applying random numbers in LogicBIST at the stage of hardware function description independent of architecture, so it becomes possible to analyze controllability and observability from the toggle rate and event occurrence rate. Further, the testability can be improved before the logic synthesis, the scan insertion, the Logic BIST controller insertion, and the fault simulation necessary for the conventional controllability / observability analysis.
In addition, design efficiency can be improved because analysis is performed with hardware function descriptions that do not depend on the architecture even during analysis and improvement, and the work is easy.

  In addition, it is possible to add a detour path and a test circuit to a net with extremely low toggle rate and event occurrence rate by checking logic BIST testability at the time of logic synthesis. The destruction of the timing that occurs by adding can be avoided.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a computer configuration diagram for executing an embodiment of a testability analysis system and a testability design system according to the present invention. That is, the computer of FIG. 1 connects an input device 1, a display device 2, a CPU (Central Processing Unit) 3, a memory 4, and a storage device 5 via a system bus 6.

The input device 1 includes a keyboard, a mouse, a touch panel, and the like, and is used to interactively input input / editing and execution of hardware function descriptions independent of architecture.
The display device 2 is configured by a display device, a liquid crystal display device, or the like, and is used for displaying hardware function descriptions independent of architecture, displaying information input from the input device 1, execution progress, execution results, and the like. .
The CPU 3 operates various programs.
The memory 4 holds the program itself, and holds information that is temporarily created when the program is executed by the CPU 3.
The storage device 5 has a hardware function description, data independent of the architecture, a program that realizes the function of the present embodiment, temporary information at the time of executing the program, and a processing result when an instruction to output the processing result to a file is given. Etc.

FIG. 2 is a block diagram showing a functional configuration of the testability analysis system of the present invention.
In FIG. 2, the function of the testability analysis system includes an input means 10, a register variable recognition means 20, a random number generation means 30, a simulator 40, and an analysis means 50.
The input means 10 reads the hardware function description independent of the architecture from the input device 1 and temporarily stores the read hardware function description in the storage device 5 for later processing. Here, the architecture-independent hardware function description uses a description language standardized by IEEE such as VHDL (VHSIC (very high speed IC) HDL) or Verilog-HDL.
The input unit 10 may extract a hardware function description stored in the storage device 5 in advance.

The register variable recognizing unit 20 recognizes a register variable in which the storage element can be guessed in the hardware function description read by the input unit 10.
In the description language of VHDL or Verilog-HDL, the description format for guessing the storage element is determined by the logic synthesis system. For example, in the case of Verilog-HDL, as shown in FIG. Thus, it is only necessary to describe the sensitivity based on the posted description of the always statement by the clock to be synchronized.
The register variable recognizing means 20 detects the description format shown above from the read hardware function description, and recognizes the variable on the left side of the assignment formula as being estimated by the logic synthesis system by the flip-flop circuit. These register variables are logically synthesized by the logic synthesis system and are replaced with scan cells as a result of full-scan scan path insertion, and serve as control points for test data using a LogicBIST pseudo-random number.
For example, a flip-flop circuit inferred from the hardware function description described in FIG. 3 has a circuit configuration as shown in FIG.

The random number generation means 30 generates a pseudo random number, and the generated random number is given to the register variable recognized by the register variable recognition means 20, and a simulation is performed.
The random number generating means 30 may be constituted by a test bench that is input to the simulator 40. In the case of using this test bench, for example, in the case of a Verilog simulator, it is possible to directly apply a random number to a register variable recognized by the register variable recognizing means 20 by using a force statement and a system task of $ random.
The force statement of the Verilog simulator can be applied directly even when the application destination data is not an external port.
For example, a test bench for applying random numbers to the function description data as shown in FIG. 5 is as shown in FIG.

The simulator 40 is a functional simulator that performs a simulation of the hardware function description stored in the storage device 5, and may be configured using a commercially available simulator.
Using this simulator 40, the test input status in Logic BIST can be confirmed by applying the random number generated by the random number generation means 30 to the register variable recognized by the register variable recognition means 20. The simulation by applying the random number is performed, for example, as many times as a sufficient toggle rate can be generated from the bit width of the bus variable in the hardware function description.

The analysis means 50 analyzes the controllability and observability by summing up the event occurrence rate and toggle rate of internal variables such as nets and buses in the hardware function description from the coverage data after the simulation is performed, and displays the result as the display device 2. To display.
When a simulation is performed using a commercially available simulator, the event occurrence status is output as a dump file, so that the event occurrence rate and toggle rate of the internal variables can be easily calculated.

The controllability / observability analysis focuses on the extremely low toggle rate and event occurrence rate in order to find the location that causes the failure detection rate of LogicBIST to decrease.
For example, in an architecture having an AND logic operation on a 16-bit register value, the output does not change to 1 unless all the bits of the 16-bit register are 1. However, since the input value of the test data in Logic BIST is a pseudo-random number, the possibility that the 16-bit register values are all 1 is low in terms of probability, and the same applies to the gate-level netlist that depends on the technology after logic synthesis. It is. Therefore, it becomes a cause of hindering the improvement of the failure detection rate by LogicBIST.

  If the output signal of this AND operation is a data bus selector signal, the failure detection rate of the entire hardware is lowered. In this case, referring to the hardware function description, it is immediately determined whether it is a selector signal of the data bus. Therefore, the location that causes the failure detection rate to decrease can be found, and the toggle rate and event occurrence rate can be set. Debugging is also facilitated by back-annotating to a CAD tool such as a hardware function description viewer.

  In the above description, the random number generation means 30 is implemented via the test bench, and the toggle rate and event occurrence rate are implemented via the dump file. However, the access function and the like in the PLI (Programming Language Interface) of the Verilog simulator, etc. From the register variable recognition to the toggle rate / event occurrence rate analysis result output may be performed without using an intermediate file.

FIG. 7 is a flowchart showing the processing procedure of the testability analysis system.
A hardware function description independent of the architecture is read from the input device 1 and temporarily stored in the storage device 5 (step S11).
In the hardware function description that does not depend on the read architecture, a register variable for which a storage element can be guessed is recognized and extracted (step S12).
A random number is applied to the extracted register variable and a simulation is performed (step S13). The simulation execution by applying the random number is performed a plurality of times. The number of times of the simulation execution is specified by the designer according to the bit width of the bus variable in the hardware function description.
The events generated by the simulation are totaled, the toggle rate and the event occurrence rate are totaled, the controllability / observability is analyzed, and the result is displayed on the display device 2 (step S14).

The testability design system of the present invention is designed to give a restriction for executing LogicBIST before applying random numbers in the testability analysis system described above. For example, the asynchronous reset signal or the like needs to be turned off so that the scan operation is not broken when the test is performed by the scan path.
If such a restriction is appropriately set before random number application, simulation for hardware function description independent of architecture by random number application can be reproduced in the same situation as when performing LogicBIST in a gate level netlist. .

  In LogicBIST, it may be used in conjunction with the boundary scan test mechanism for testability design proposed by JTAG (Joint Test Action Group) organized by European and American semiconductor manufacturers. What is necessary is just to give the sequence set to the runlist command of JTAG before.

FIG. 8 is a block diagram showing a functional configuration of the testability design system of the present invention.
In FIG. 8, the design design system for testability comprises the functions of an input means 10, a register variable recognition means 20, a random number generation means 30, a simulator 40, a constraint setting means 60, and a confirmation means 70. In the figure, components having the same functions as those in the testability analysis system described above are denoted by the same reference numerals, description thereof is omitted, and only different components will be described.

The constraint setting means 60 sets a constraint to be given before random number application.
For example, if a constraint is applied to apply X (signal state is indefinite) to an external input signal or a register variable recognized by the register variable recognition means 20, it is called a Tie failure or a Block failure in the simulation in the simulator 40. The VCC and GND fixed nodes do not generate an event regardless of the application of X, and a result of 0 event occurrences is obtained.
When the X event occurrence is confirmed in the simulation result, the confirmation unit 70 displays the X propagation rule violation on the display device 2. Thereby, Tie failure and Block failure can be confirmed at the stage of hardware function description.

FIG. 9 is a flowchart showing the processing procedure of the testability design system.
The hardware function description independent of the architecture is read from the input device 1 and temporarily stored in the storage device 5 (step S21).
In the hardware function description that does not depend on the read architecture, a register variable for which a storage element can be guessed is recognized and extracted (step S22).
Restrictions to be given before applying random numbers are set (step S23). For example, a restriction is imposed so that X (signal state is indefinite) is applied to an external input signal or a recognized register variable.
A random number is applied to the extracted register variable, and a simulation is performed (step S24). The simulation execution by applying the random number is performed a plurality of times. The number of times of the simulation execution is specified by the designer according to the bit width of the bus variable in the hardware function description.
When the occurrence of an X event is confirmed in the simulation result, it is displayed on the display device 2 as an X propagation rule violation (step S25).

The conventional logic synthesis system has a function of expanding an input hardware functional description in a memory and adding / deleting arbitrary nets, ports and cells.
This testability design system uses this function to add a test mode signal that is turned on when LogicBIST is executed, and from the testability analysis result of the testability analysis system, toggle rate and event occurrence rate For an extremely low net, an additional detour path with the test mode as a selector is added to the hardware function description data developed in the memory of the logic synthesis system.

For example, FIG. 11 shows an image diagram when a test mode signal and a bypass path are added to the test target circuit of FIG. 10 and then developed on the memory of the logic synthesis system.
In this case, an LBISTEN signal is added to the test mode signal, and an XOR type function is added in consideration of observability related to a 16-bit input, so that a conventional function and an additional function can be selected by the test mode signal LBISTEN. .

  As a result, this testability design system can confirm the testability of LogicBIST during logic synthesis and can add detour paths and test circuits to nets with extremely low toggle rates and event occurrence rates. The destruction of the timing that occurs by adding a test circuit to the gate level netlist can be avoided.

Furthermore, the present invention is not limited only to the above-described embodiment. Each of the functions constituting the above-described embodiment is programmed and written in advance on a recording medium such as a CD-ROM, and this CD-ROM is mounted with a medium driving device such as a CD-ROM drive at each site. It goes without saying that the object of the present invention can also be achieved by mounting the apparatus in a device, storing the program in a memory or a storage device, and reading and executing the program stored in the recording medium by the CPU of the computer device.
Further, when the above-described program is stored in a ROM (Read Only Memory), the medium driving device may not be provided.

  In this case, the program itself read from the recording medium realizes the functions of the above-described embodiment, and the program and the recording medium recording the program also constitute the present invention.

  In addition, as a recording medium, a semiconductor medium (for example, ROM, a non-volatile memory card, etc.), an optical medium (for example, DVD, MO, MD, CD-R, etc.), a magnetic medium (for example, magnetic tape, a flexible disk, etc.) Either may be sufficient.

  In addition to executing the functions of the above-described embodiment by executing the loaded program, the operating system or the like performs part or all of the actual processing based on the instructions of the program, The case where the functions of the above-described embodiment are realized is also included.

  In addition, when the above-mentioned program is stored in a storage device such as a magnetic disk of a server computer and distributed in the form of download from a user's computer connected via a communication network such as the Internet, the storage device of this server computer also It is included in the recording medium of the present invention.

It is a hardware block diagram for implementing this invention. It is a block diagram which shows the function structure of a testability analysis system. This is an example in which a hardware function description is created in VHDL. FIG. 4 is a circuit diagram of a flip-flop inferred from FIG. 3. It is an example of the function description for demonstrating the test bench of random number application. It is an example of the test bench which applied the random number with respect to the function description of FIG. It is a flowchart which shows the process sequence of a testability analysis system. It is a block diagram which shows the function structure of a testability improvement design system. It is a flowchart which shows the process sequence of a testability design system. It is an example of a test object circuit. FIG. 11 is an image diagram when a test mode signal and a bypass path are added to the test target circuit of FIG. 10 and then developed on the memory of the logic synthesis system.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Input device, 2 ... Display apparatus, 3 ... CPU, 4 ... Memory, 5 ... Storage device, 6 ... System bus, 10 ... Input means, 20 ... Register variable recognition means, 30 ... Random number generation means, 40 ... Simulator, 50 ... analyzing means, 60 ... constraint setting means, 70 ... confirming means.

Claims (1)

Input means for inputting function description data that defines hardware functions in a format independent of architecture, register variable recognition means for recognizing a register variable in which a storage element in the function description data can be guessed, and LogicBIST execution Constraint setting means for setting constraints, random number generating means for applying a random number to the register variable recognized by the register variable recognition means, a simulator for simulating an event caused by the application of the random number, and the simulation result And analysis means for analyzing the cause of failure detection failure caused by LogicBIST from the variable rate in the function description data, the toggle rate / event occurrence rate of the net or bus, etc., and the constraint setting means is a JTAG (Joint Test Action Group) boundary. Scan test If you are combined before the random number generator for runbist instruction JTAG, the constraint setting means DFT, characterized in that to implement the constraints set by giving a constraint setting sequence LogicBIST execution system.