Figure 3.1: Principal SBST Automation Scheme
lw $1, $2($3)
Figure 3.2: A Sample Macro
3.1 Preliminaries and Working Principle
Table 3.1: Behavioral Fault Models [5]
Fault model Failure Type Input stuck-at fault Primary input signal Output stuck-at fault Primary output signal If stuck then fault Else portion of
an if construct If stuck else fault If then portion of
an if construct
Elsif stuck then fault Subsequent else portion of an if construct
Elsif stuck else fault Elsif portion of an if construct Assignment statement fault Assignment of
new values to signals Dead clause fault A Selected WHEN
clause in case statement Micro-operation fault Micro-operations Local stuck data fault A signal object
in a local expression
Input = alu_a, alu_b, alu_op;
Output = alu_out;
if(alu_op = "100100") then alu_out:=alu_a and alu_b;
Input = alu_a, alu_b, alu_op;
Output = alu_out;
if(alu_op = "100100") then alu_out:=”000...000” and alu_b;
Figure 3.3: Input Stuck-at-0 Fault in VHDL
An example of a behavioral input stuck-at fault in the logicalandoperation statement of an ALU module is shown in Fig. 3.3. In these descriptions, an and operation is performed between two input 32-bit operands, which are alu a and alu b, to achieve the output alu out. A stuck-at-0 fault in the 32-bit alu a input signal transforms the and operation to: “alu out := “0000. . .0000”and alu b”. As a result, an all-zero value is assigned to the output alu out, regardless of the value of alu b. This fault could be detected by the test program in Fig. 3.4 because in a non-faulty design, the operands R1 and R2 hold non-zero values which lead to an expected non-zero output value for the alu out signal. If the stuck-at-0 fault in thealu a signal exists, the output value for the alu out signal becomes zero. In a normal case, the expected output is non-zero and thus, the fault is detected. Likewise, a stuck-at-1 fault in alu a also could be detected
li R1,1 li R2,1 and R3,R1,R2
sw R3,offset3(R4)
Figure 3.4: Test Program That Detects the Input Stuck-at-0 shown in Fig. 3.3
Figure 3.5: A Simple RISC Processor Architecture [1]
with the selected instructions and operand values.
Now we discuss the severity of the diagnosis of these behavioral faults. For this, the faults are classified into easy-to-detect and hard-to-detect faults. In Fig. 3.5, a MIPS processor model with a program counter, registers, control unit, and functional components/modules such as ALU are shown. Generally, the faults in the functional components which are directly associated with the instructions in the ISA are easily de- tectable by the majority of the instruction sequences. For example, the input stuck-at-0 fault shown in Fig. 3.3 is an easy-to-detect fault because this fault could be detected by many combinations of instruction sequences with and operation, such as the sequence shown in Fig. 3.4. TheµGP [2] technique could uncover these easy-to-detect faults com- prehensively whereas the hard-to-detect faults or the corner case faults were completely unidentified.
It is relatively challenging to identify the faults in the control unit and other non- functional components that belong to the control path of the processor. The failures in generating certain control signals could not be identified effectively because these signals are not regularly observable. If the collected test response, comprising the contents of response locations such as general purpose registers and memory, infrequently recognizes
3.1 Preliminaries and Working Principle
Figure 3.6: MIPS Branch Instruction Execution [1]
any deviations due to the existence of signal faults, dedicated test programs would have to be developed to take care of those faults.
Some of the controller faults are hard-to-detect, such as an assignment statement fault, where a signal is stuck to zero or one in a single VHDL statement in the control sig- nal “branch”. The propagation ofbranchsignal towards any of the destination registers depends on the activation of the status signalalu zeroas shown in Fig. 3.6. The control unit activates the branch signal when a branch instruction, e.g., “beq R1, R2, T arget”, executes. The operands R1 and R2 are subjected to comparison by ALU, and if the result of the comparison is true, alu zero also gets activated. If both the branch and alu zero signals are triggered, the control goes to the instruction in the target address.
Otherwise, the PC is incremented (P Cinc) to select the next instruction in the instruc- tion memory. Here, any assignment statement fault in the branch signal is propagated ahead only if the value of thealu zero signal is 1, which is carried out whenR1 andR2 have equal values. In this case, the fault detection turns out to be difficult because of the dependence of branch signal on thealu zero signal.
It may be noted that these operands (R1 and R2), most likely, would hold different values due to the randomness in the selection of operand values in optimization algo- rithms. To load these operands with equal values, appropriate load instructions must be executed before the branch instruction as shown in Fig. 3.7. Here, the operands R1 and R2 hold equal values imm1. So, the comparison result of the beq instruction becomes true, and the faults on the branch signal would propagate towards the observ- able locations. But the evolutionary core of the traditional µGP approach [2] may not generate test programs with such desired sequences of instructions frequently. So, these sequential dependencies of instructions and the operand constraints make the statement
lui R1,imm1 lui R2,imm1 beq R1,R2,Target addi R1,R1,1
Target : sw R1,offset(R4)
Figure 3.7: Instruction Sequence to Detect Branch Signal Corner Case
assignment faults on branch signals undetectable.
Only a few sequences or combinations of opcode and operands could identify those faults which are less likely to get propagated to any of the response locations. During the test optimization process, such sequences hardly occur in the final test solutions achieved. Even if these sequences occur in any of the intermediate test programs, they may not survive to the future generations as the evolutionary process tends to preserve those with the sequences of instructions that can identify a large number of functional faults.
To summarize, the problem being addressed in this work is “during the automatic test program generation, the intermediate test programs comprising instructions which detect the hard faults must be sustained to constitute a final test solution of improved coverage”. In the next section, we discuss how our proposed greedy approach would synthesize the test program solutions that detect the hard-to-test faults.