590 likes | 811 Views
Version 3.2. RTL Design Verification and Error Modeling. Speaker: Hung-Yi Chen Advisor: Chun-Yao Wang 04/16/2009. NTHU-CS. Outline. Introduction Design Modeling Tsing-Hua Logic Format (THLF) Design Verification Mutation Testing Conclusion Future Work. Introduction.
E N D
Version 3.2 RTL Design Verification and Error Modeling Speaker: Hung-Yi Chen Advisor: Chun-Yao Wang 04/16/2009 NTHU-CS
Outline • Introduction • Design Modeling • Tsing-Hua Logic Format (THLF) • Design Verification • Mutation Testing • Conclusion • Future Work
Introduction (1/3) Design Verification plays an important role in checking the functionality of Design Under Verification (DUV) in the design flow and consumes more than 70% of the development time. Verification engineer tries to optimize the verification time, finds the unexplored areas of DUV, analyzes the completeness of verification process. They employ code coverage metrics for these reasons.
Introduction (2/3) For increasing the confidence, verification engineer employs multiple code coverage metrics such as branch coverage, expression coverage and so on. But those coverage metrics still cannot guarantee this is an error-free design even all of them reached to 100%.
Introduction (3/3) In this work, we present a new functional verification method which hybrids a new representation of HDLs called “Tsing-Hua Logic Format” (THLF) and an error coverage metric “Single Stuck Line” (SSL). We can model the actual design errors to SSL faults in THLF. In this way, we can establish a robust error model and generate the effective stimuli set.
Design Modeling (1/6) Digital design can be classified into two basic parts, namely, the combinational and sequential part. We also can model the design into two different parts, “Data Path” and “Control Unit”. Din Data Path Dout Control Unit Command Feedback
Design Modeling (2/6) Control Unit sends commands to Data Path, and Data Path computes the results (Dout and Feedback) according to the commands and Din. Din Data Path Dout Control Unit Command Feedback
Design Modeling (3/6) A control unit consists of control statements and controlling FSMs. Acontrol statement corresponds to a branch in the HDLs. A controlling FSM is a part of a controller. Din Data Path Dout Control Unit Feedback Command Feedback Command Control Statements Controlling FSMs Next State Current State
Design Modeling (4/6) • Control Statement We can extract the control statements from HDLs directly. Data Path always @(posedgeclk) begin if ( (a||b) && c ) Dout = Din + 1; else Dout = 0; end Din + T Dout 1 0 F a b Control Unit c
Design Modeling (5/6) • Controlling FSM • HDL’s rich constructs provide many different ways to describe the controlling FSM. The controlling FSM extraction method can use a representation (THLF) that frees it from restrictions on code writing style. S1 1 S2 NextState 2 S3 3 = 0->1 S0 0->2 = S1 0->3
Design Modeling (6/6) • ConjunctionLogic if (c1) … if(c2) Dout = Din + 1; else … else … Conjunction Logic is a group of extra gates which “conjoin” several control signals to one without changing its functionality. Din + T T T 1 Dout F F F Din + Dout 1 c2 c1 c1 c2
Tsing-Hua Logic Format (1/6) The THLF representation consists of four parts : (1) Read/Write Nodes, (2) Operator Nodes, (3) Decision Nodes and (4) Housekeepers(TBD). Decision Node 0 1 E Read/Write Nodes in 2 D 4 C Housekeeper 1 reset Operator Nodes 2 load A >= 3 4 != B
Tsing-Hua Logic Format (2/6) We developed a simple algorithm to generate THLF. Step 1: Generate the statement tree A = Din; B = A; C <= B + 1; if (C1) Dout = B; else Dout = C; SR <= Dout; if (C2) SR <= 0; 1 Statement Tree 1 C1 C2 2 2 3 5 3 4 X 4 5
Tsing-Hua Logic Format (3/6) • Step 2: Build the Data Path A Din 1 A = Din; B = A; C <= B + 1; if (C1) Dout = B; else Dout = C; SR <= Dout; if (C2) SR <= 0; Dout 2 1 B 1 SR 4 2 3 C + 1 3 1 0 4 5 5
Tsing-Hua Logic Format (4/6) • Step 3: Build the Control Unit 1 Statement Tree 2 5 C1 C2 C1 C2 2 3 3 5 4 X
Tsing-Hua Logic Format (5/6) • An example 1 Statement Tree 2 2 4 C1 C1 C2 C2 3 3 4 X
Tsing-Hua Logic Format (6/6) • Step 4: Link the data path and control unit A Din 1 1 2 Dout 4 0 SR 3 5 B 1 C C 2 3 5 + C 1 1 C1 2 4 X 3 C2 5
Design Verification (1/26) Overview of our design verification flow Translation Injecting Errors Spec ? Coding Correct Design Incorrect Design RTL RTL THLF Simulator Correct ? Stimuli Set
Design Verification (2/26) Two important hypotheses 1. Coupling Effect : States that complex errors are coupled with simple errors. On the other hand, a stimuli set can detect all simple design errors, will also detect the complex design errors.
Design Verification (3/26) 2. Competent Programmer : Asserts that a competent programmer tends to write programs are “closely” to (in the sense of textual difference) the correct design. > >= < + Easy Hard Correct Design Incorrect Design
Design Verification (4/26) THLF Complex Design Errors Simple Design Errors Filter (Couple Effect) Error Models (Competent Programmer)
Design Verification (5/26) Grouping the operators < * ! > != ~ % - <= & !== ^ + | || == && >= / === ~^ ~| ~& Concatenate Operator Conditional Operator Logical Operators << Relational Operators Arithmetic Operators ? : {} Equality Operators >> Shift Operators
Design Verification (6/26) Simple Gate Replacement Suppose that the incorrect design differs from the correct design by a simple gate replacement. Any complete test set distinguishes between the correct design and incorrect design. G1 G2 A C B Asa1 => AB(0,1) => Csa1 Asa0 => AB(1,1) => Csa0 Bsa0 Bsa1 => AB(1,0) Correct Design Correct Design A C B Incorrect Design Incorrect Design
Design Verification (7/26) An Extra Wire Suppose that one extra wire exists in the incorrect design, any complete test set can detect this design error. G1 G2 AND G1 Sa1 G2 AND Correct Design Incorrect Design
Design Verification (8/26) Partial Extension to a missing wire The test pattern which to detect the sa0 fault on the output will also detect the missing wires those have logic value 0. 0 G1 G2 AND G1 sa0 G2 AND Correct Design Incorrect Design
Design Verification (9/26) The wire exchange design error These test patterns Asa0 (A=1,B=0), Asa1(A=0,B=1), Bsa0 (A=0,B=1), Bsa1 (A=1,B=0) can detect this design error. So, the design error may be detected over and over again. G1 G2 G1 G3 G4 G2 G3 A A B B G4 Correct Design Incorrect Design
Design Verification (10/26) How to map a new design error to SSL fault on THLF ? SAF Gx THLF Stimuli Set for the design error New Design Error Find the Gx and the SSL faults which can generate the stimuli set. Append the new gate with the SSL faults to THLF.
Design Verification (11/26) Relational Operators Replacement (ROR) Obviously, we also need the “complete test set” (namely, A>B, A<B and A=B) to detect this design error.
Design Verification (12/26) Mapping to SSL faults Csa0 => CD(1,1) => (A>=B) and (A!=B) => (A>B) => Dsa0 andFsa0 Csa1 => CD(0,1) => (A<B) and (A!=B) => (A<B) => Fsa1 Dsa1 => CD(1,0) => (A>=B) and (A=B) => (A=B) THLF A>B A >= C != F D B
Design Verification (13/26) Mapping to SSL faults Csa0 => CD(1,1) => (A<=B) and (A!=B) => (A<B) => Dsa0 andFsa0 Csa1 => CD(0,1) => (A>B) and (A!=B) => (A>B) => Fsa1 Dsa1 => CD(1,0) => (A<=B) and (A=B) => (A=B) THLF A<B A <= C != F D B
Design Verification (14/26) Mapping to SSL faults Csa0 => CD(1,0) => (A>B) and (A!=B) => (A>B) => Fsa0 Csa1 => CD(0,0) => (A<=B) and (A!=B) => (A<B) => Fsa1 andDsa1 Dsa0 => CD(0,1) => (A<=B) and (A=B) => (A=B) A>=B THLF A > C == F B D
Design Verification (15/26) Mapping to SSL faults Csa0 => CD(1,0) => (A<B) and (A!=B) => (A<B) => Fsa0 Csa1 => CD(0,0) => (A>=B) and (A!=B) => (A>B) => Fsa1 andDsa1 Dsa0 => CD(0,1) => (A>=B) and (A=B) => (A=B) A<=B THLF A < C == F B D
Design Verification (16/26) Mapping to SSL faults Csa0 => CD(1,1) => (A>=B) and (A<=B) => (A=B) => Dsa0 andFsa0 Csa1 => CD(0,1) => (A<B) and (A<=B) => (A<B) => Fsa1 Dsa1 => CD(1,0) => (A>=B) and (A>B) => (A>B) THLF A==B A >= C <= F D B
Design Verification (17/26) Mapping to SSL faults Csa0 => CD(1,0) => (A>B) and (A>=B) => (A>B) => Fsa0 Csa1 => CD(0,0) => (A<=B) and (A>=B) => (A=B) => Fsa1 andDsa1 Dsa0 => CD(0,1) => (A<=B) and (A<B) => (A<B) A!=B THLF A > C < F B D
Design Verification (18/26) ~Q Q Port Order Error (POE) SAF Module A Module A A A B B C C THLF Hook Logic Q Q Q A B a a b b c c Module B Module B H a b Incorrect Design Correct Design
Design Verification (19/26) Hook Logic The Hook Logic is a group of extra gates which “hook” to those signals may cause the POE. H0 SA0 ABC(1,0,0)=> POE on A. H1 SA0 ABC(0,1,0)=> POE on B. H2 SA0 ABC(0,0,1)=> POE on C. THLF 0 0 1 A B C 1 1 b a c sa0 H0 H2 H1
Design Verification (20/26) Branch Priority Error (BPE) if (SMI) SR <= SMI; else if (NMI) SR <= NMI; else if (IRQ) SR <= IRQ; if (NMI) SR <= NMI; else if (SMI) SR <= SMI; else if (IRQ) SR <= IRQ; Branch Coverage = 100% But, it cannot guarantee the detection of BPE. GOOD NSI(1,1,0) NSI(0,1,1) NSI(1,0,1) NSI(0,0,1) NSI(0,0,0) BAD NSI(1,0,0) NSI(0,1,0) NSI(0,0,1) NSI(0,0,0) Incorrect Design Correct Design
Design Verification (21/26) SSL Faults on Conjunction logic TYPE B C1 TYPE A TYPE C TYPE C if (C1) S1 if (C2) S2 if (C2) S2 if (C1) S1 TYPE B if (C1) S1 if (C2) S2 TYPE A C2 C1 S1 S1 S2 SX C2 C2 C1 S2 S1 S2 SY SX SX
Design Verification (22/26) C1 C2 S1 S2 S2 S1 C2 C1 Missing Gate Extra Gate TYPE B TYPE A TYPE C C1 S1 S2 C2 Missing Gate Missing Gate and Extra Gate Extra Gate
Design Verification (23/26) C1 S1 S2 C2 Missing Condition Error if (C1) begin S1 end if(C2) S2 SX if (C1) begin S1 if(C2) S2 SX end Incorrect Design Correct Design C1 S1 S2 C2 Incorrect Design Correct Design sa1 sa0
Design Verification (24/26) C1 S1 S2 C2 Extra Condition Error if (C1) begin S1 if(C2) S2 SX end if (C1) begin S1 end if(C2) S2 SX Correct Design Incorrect Design C1 S1 S2 C2 Correct Design Incorrect Design sa1
Design Verification (25/26) C1 C1 S1 S1 S2 S2 C2 C2 Wrong Condition Error if (C1) S1 if(C2) S2 else SX if (C1) S1 else if(C2) S2 SX D1 D2 D2 D1
Design Verification (26/26) Branch Priority Error (BPE) NSI(1,1,0) NSI(0,1,1) NSI(1,0,1) NSI(0,0,1) NSI(0,0,0) N S1 S2 if (NMI) SR <= NMI; else if (SMI) SR <= SMI; else if (IRQ) SR <= IRQ; S S1 S3 I S2 THLF S3
Mutation Testing (1/4) Mutation Testing is a fault-based approach for software testing. The basic idea is to show that particular faults cannot exist in the design by creating a specific test pattern. Faults to be considered are the most commonly occurring ones in software programming. A <= B + C; A <= B - C;
Mutation Testing (2/4) Mutation Operator Table