1. Test Generation 2. Design Error Diagnosis       2.1. Example 3. Built-in Self-Test 4. Design for Testability

 

2. DESIGN ERROR DIAGNOSIS

Objectives
To introduce basics of diagnosis using the design error diagnosis problem as an example. To learn how to compose diagnostic tests and to realize the difference between a diagnostic and a verification tests.

Introduction
There is a difference between testing and diagnosis. During testing, the main goal is to find out if a device is working proprly. Such a device is called a unit under test (UUT). In other words, there can be only two results of testing: 1) a fault is present in the UUT, 2) the UUT is fault-free. The result of the diagnosis is either the exact location of the fault or the localization of a faulty area that cannot be resolved any more. The accuracy of the result depends on the diagnostic resolution which is achievable on given circuit with given test set. The result is formulated in terms of the target fault model. It can be for example a stuck-at fault model or a delay fault model or a physical fault model, etc.

Before the device is sent for manufacturing, it goes through many phases of design process. Each phase may be performed numerous times before an acceptable solution is obtained. It is an iterative incremental process and may require circuit modifications in order to perform trade-offs. These modifications can be inserted either by means of automated designing tools or manually. For example netlists generated by the synthesis tools very often have to be modified by designers to improve timing performance, to obtain more compact structures, or to carry out small specification changes.

The error emergence probability through various design stages is big enough. An error not detected at the earlier stages may cause a cost explosion of the project and significantly increase the time-to-market. This fact forces the research in the direction of development fast and efficient methods for design error detection, diagnosis, and rectification. An example of a design error could be a gate substitution error, for example, AND gate is replaced by OR gate in the implementation. It could be also a bad or missing connection between gates.

Work description
Suppose, you have designed a combinational circuit which has to meet certain functionality described in the specification. However, verification step has shown that the implementation and the specification are not functionally equal. Your task then is to find the erroneous area in the circuit and rectify it so that the new version of the design will be functionally equal to the specification. We prepared several designs to experiment with. They can be found here.

First, use the xtimport tool to replace an arbitrary gate in your design by a gate of another type and create the specification and implemetation. We will consider the generated specification to be functionally correct and the implementation to be the erroneous circuit to rectify. We will also consider the implementation to have exactly a single design error which is either a gate substitution error or a missing/extra inverter error.

In our work we will use an automatic diagnostic tool (prediag) to reduce the search space by deriving an intermediate suspected erroneous area within the design. This tool uses an ordinary test set (not a diagnostic one) generated by a conventional ATPG to make a prediagnostic analysis of the design and purposely produces a diagnosis of an unaceptable quality in order to give you the possibility to find the exact error location by yourself. The nature of the underlying test vectors can be considered as another reason for such a quality of the intermediate diagnosis.

To sum up, after the xtimport tool, the ATPG comes with the test set, and then the prediag tool generates the intermediate diagnosis. The further analysis is to be made by a human being (like you). Please, read the rules for design error diagnosis and use them to manually create additional (one or more) diagnostic test patterns which will help you to derive the unique error location and to make a suggestion concerning the replacement of the erroneous gate by a gate of a different type in order to rectify the implementation. Those test patterns must be formatted and inserted by the vecmanager tool. The verification tool verify will apply the diagnostic vectors and compare the responses of the implementation and specification. Use this information to find the error locaton or to create more diagnostic patterns.
 

Steps

1. During  the preparation stage, be sure to collect (use xtimport tool and an ATPG)
   
   • implementation as a macro-level SSBDD model (<design>.agm file)
     
   • design specification (<design>.spec file)
   • gate-level signal paths (<design>.pat file)
   • test patterns (<design>.tst file)

   Please choose your circuit from the list of designed circuits.

2. Use the automatic design error diagnosis tool (prediag) to obtain an intermediate set of suspected faulty gates.
3. Analyze the intermediate diagnostic information and compose manually an additional diagnostic pattern(s), which helps to further distinguish between erroneous and correct gates. Check the design error diagnosis rules.
4. Compare the behavior of the implementation and the specification by using the verification tool (verify). This tool applies your pattern(s) to both the implementation and specification and identifies the differences in output responses of the both.
5. Use this information to derive the erroneous gate. If it is not possible yet, go to step 3. If it is impossible to refine the diagnostic resolution anymore, explain why.

2.1 EXAMPLE

This example is based on the same ISCAS'85 c17 curcuit. It will serve us as the erroneous implementation that needs to be diagnosed and rectified.

Steps

1. Having the EDIF file (<design>.edi), the implementation is obtained with the xtimport tool. For c17 use the following format: xtimport -paths c17.edi bench.lib. If you have designed your circuit using, for example, Cadence and AMS library (this applies also to our standard circuits), then write: xtimport -paths -tool cadence <design>.edi ams.lib. See the reference manual for more details.

   During the generation of the implementation, the information about gate-level signal paths is also saved in the <design>.pat file. This information is essential for the prediagnostic tool prediag.

   The specification is derived also from the same EDIF file using the xtimport tool. Usage: xtimport -spec c17.edi bench.lib or xtimport -spec -tool cadence <design>.edi ams.lib. The encrypted info about the replaced gate is saved into the <design>.rep file during the specification generation.

   The test patterns needed for the prediag tool can be obtained using an ATPG or by any other test generation method. For example, for the deterministic ATPG write: generate c17 and you will get the patterns in c17.tst file.

2. Run the prediag tool with the following format: prediag c17. Instead of c17 put the name of the circuit you have to pactice with. The prediagnostic information for c17 is given in red in the picture below. Suspected stuck-at zeros are shown by "0", stuck-at ones are shown by "1", and if both fault types are suspected it is denoted as "D". The characters in boxes point out the suspected faults at the outputs of suspected gates. So, in our case the suspected erroneous gates are g₂ and g₄. Note, that we are not interested in suspected stack-at 0 at the input x₃ and stuck-at 1 at one of inputs of g₃ because they are not at inputs of any suspected gate. In the following we use ideas stated in "The rules of design error diagnosis" as well as in the theory chapters about test generation and fault diagnosis.

   

3. Since we have two suspected gates we have to prove that one of them is correct and we have to rectify another one. We can say that, for instance, gate g₂ is correct if we succeed to compose such a test that tests g₂ but does not test g₄ at least at one of the circuit outputs and this output will not be erroneous. However, note, that the gate g₂ affects both outputs y₁ and y₂ but gate g₄ affects only y₂. Therefore, g₄ can be eliminated as soon as we detect an error at y₁. Probably the latter would be simpler to do and we will try it first. To do so, we will compose the test that activates both stuck-at faults at both inputs of g₂ and propagates them to y₁ output (see the test generation section to refresh the knowledge). Such a test is given in the table below (Table 1). Insert your test into <design>.tst file using the vecmanager tool.
    

   TABLE 1

   	x1	x2	x3	x4	x5
   Pattern 1	0	1	1	0	0
   Pattern 2	0	1	0	1	0
   Pattern 3	0	1	1	1	0

   
   

4. If, applying this test, an error at y₁ is observed, we are assured that g₄ is correct. Using the verification tool (verify c17) we obtain the information concerning errors observed at the circuit outputs (Table 2):
    

   TABLE 2

   	y1	y2
   Pattern 1	Error	Error
   Pattern 2	Error	Error
   Pattern 3	Error	Error

   
   

5. So, we can see that our hypothesis was right (the error is reflected at the both outputs) and we conclude that g₂ is the erroneous gate in the implementation and the both stuck-at faults are "present" (actually they are not but they are "observed" there as an effect of the wrong gate type in the design) at the gate inputs. Finally, we should look at the Table 1 here for the hint concerning the new gate g₂ type that we must use instead of current NAND type. The case of NAND gate and the both stuck-at fault types suspected at the both gate inputs implies that AND gate instead of NAND should be used here to rectify the circuit.

You can compose your report notes about the results of this laboratory work based on the automatically generated <design.rep> file.

Last update: 27 July, 2004