Techniques%20for%20automated%20localization%20and%20correction%20of%20design%20errors

1
Techniques for automated localization and
correction of design errors

• Jaan Raik
• Tallinn University of Technology

2
Design error debug
There has never been an unexpectedly short
debugging period in the history of
computers. Steven Levy
2
3
Designs are getting bigger
4
Designs are getting costlier

• 25-30 annually decreasing cost per function
• 15 percent annual growth of the market for IC
• But
• The cost of chip design keeps on growing.
• In 1981, development of a leading-edge CPU cost
  1 M
• today it costs more than 300 M !!!
• Why do the costs increase ???

5
Design automation crisis

• productivity gap
• 58 versus 21 annually

6
Verification and debugging

• Debug Localization Correction
• 2/3 of development time for verification
• 2/3 of verification time for debug
• Thus nearly half of the development cycle

7
Bugs are getting smarter
8
Traditional debug flow
???
Spec
Design
Counter-examples (waveforms), failed assertions,
...
Verification
Error!

• Too much information
• Too little information

9
Automated debug flow
Spec
Design
Corrected design, Repair log, ...
Verification
Error!
Error localization
Error correction
10
Outline

• Verification basics
• Automated debug at the gate-level
• RTL debug methods
• Localization SAT correction resynthesis
• Localization path tracing correction mutation
• General discussion, future trends
• Prototype tools, on-going activities

11
Verification
To err is human - and to blame it on a computer
is even more so. Robert Orben
11
12
Verification versus test

• The goal of verification is to check if a system
  is designed correctly.
• Validation is similar to verification but we
  check on a prototype device, not a model.
• By (manufacturing) test we understand checking
  every instance of a produced chip against
  manufacruring defects.

13
Abstraction levels and verification
14
Difficulties in verification

• Errors may be in implementation, specification or
  verification environment (constraints)
• No way to detect bugs in the spec, because
  reference object is missing. Thus verification
  by redundancy.
• Problem How to assess verification quality i.e.
  coverage? (except in equivalence checking)

15
(No Transcript)
16
Verification flow
17
Dynamic verification
18
Dynamic verification

• Based on simulation
• Code coverage
• Assertions, functional coverage

19
Formal verification
20
Dynamic vs formal verification
21
Automated debug techniques
Logic is a poor model of cause and
effect. Gregory Bateson
21
22
Debugging design errors

• Concept of design error
• Mostly modeled in implementation, sometimes in
  specification
• Main applications
• Checking the synthesis tools
• Engineering change, incremental synthesis
• Debugging

22
23
Debugging design errors

• What leads to debugging?
• Design behavior doesnt match expected behavior
• When does this occur?
• During simulation of design
• Formal tools (property/equivalence check)
• Checkers identify the mismatch

23
24
Design error diagnosis

• Classification of methods
• Structure-based/specification-based
• Explicit/Implicit fault model (model-free)
• Single/multiple error assumption
• Simulation-based/symbolic

24
25
Debugging combinational logic

• Thoroughly studied in 1990s
• Many works by Aas, Abadir, Wahba Borrione,
  others
• Also studied, at TUT (Ubar Jutman)
• Used structural BDDs for error localization

26
Explicit error model (Abadir)

• functional errors of gate elements
• gate substitution
• extra gate
• missing gate
• extra inverter
• missing inverter
• connection errors of signal lines
• extra connection
• missing connection
• wrong connection

27
Missing gate error (Abadir)
28
Mapping stuck-at faults to design errors

• Abadir Complete s-a test detects all single gate
  replacements (AND,OR,NAND,NOR), extra gates
  (simple case), missing gates (simple case) and
  extra wires.

29
Combinational fault diagnosis
Fault localization by fault table
Test responses
0
1
1
0
T
0
0
1
0
0
1
1
6
Fault
F
located
5
Faults
F
and
F
are not distinguishable
1
4
No match, diagnosis not possible
30
Mapping stuck-at faults to design errors
31
Distribution of design errors
32
Explicit model disadvantages

• High number of errors to model
• Some errors still not modeled

33
Implicit design error models

• Do not rely on structure
• Circuit under verification as a black box
• I/O pin fault models

34
Design error correction

• Classification
• Error matching approach
• Resynthesis approach

35
Design error correction

• Happens in a loop
• An error is detected and localized
• Correction step is applied
• Corrected design must be reverified
• ...
• Until the design passes verification

36
Ambiguity of error location

• Since there is more than one way to synthesize a
  given function, it is possible that there is more
  than one way to model the error in an incorrect
  implementation
• correction can be made at different locations

37
Crash course on SAT
38
Satisfiability aka SAT

• SAT a Boolean function is satisfiable iff there
  exists a variable assignment to make it evaluate
  to TRUE
• The Boolean function must be represented as a
  CNF

39
Satisfiability aka SAT

• SAT is transformed to CNF
• (i.e. product of sums).
• Sums are called terms.
• If a term has max 2 literals, then 2-SAT
• ? 2-SAT is solved in polynomial time
• 3-SAT is an NP-complete problem
• N-SAT can be reduced to 3-SAT

40
SAT for circuits

• Characteristic function
• Build CNF for logic gates using implication
• a?b a b

a b a?b
0 0 1
0 1 1
1 0 0
1 1 1
41
SAT for circuits

• Implications for AND-gate
• a?c b ?c c ? a ? b
• Characteristic function for AND as a CNF
• (a c) (b c) (c a b)

42
SAT for circuits

• Implications for OR-gate
• a?c b ?c c ? a ? b
• Characteristic function for OR as a CNF (a
  c) (b c) (c a b)

43
SAT for circuits

• Characteristic function for the circuit
• (ad)(bd)(dab)(ce)(ce)(df)(ef)(fd
  e)

44
SAT-based RTL debug

• Mux-enrichment
• Muxes added to RTL code blocks
• Mux select values select free inputs for the
  symptom blocks
• Synthesis is applied to find logic expressions
  generating the signatures for these free inputs
• Cardinality constraints
• Test vector constraints

Smith, Veneris, et al., TCAD, 2005
44
45
SAT-based RTL debug
a) Mux enrichment, b) cardinality constraints
45
46
SAT-based RTL debug

• SAT provides locations of signals where errors
  can be corrected
• Multiple errors considered!
• They also provide the partial truth table of the
  fix
• Correction by resynthesis
• This is also a disadvantage
• Why should we want to replace a bug with a more
  difficult one?

46
47
Path tracing for localization

• One of the first debug methods
• Backtracing mismatched outputs (sometimes also
  matched outputs)
• Dynamic slicing ? critical path tracing (RTL)

47
48
Mutation-based correction

• Locate error suspects by backtracing
• Correct by mutating the faulty block (replace by
  a different function from a preset library)
• An error-matching approach

48
49
Testbench-based approach
Original system description
1. Identify injection location
2. Apply mutation operators accordingly
Injected system description
50
Arithmetic Operator Replacement (AOR)

• Set of arithmetic operators addition,
  subtraction, multiplication, division, modulo
• Replace each occurrence of arithmetic operator
  with all the other operators in the set

a b c
a b c
a b c
a b / c
a b c
51
Logical Connector Replacement (LCR)

• Set of logical connectors and, nand, nor, or,
  xor
• Replace each occurrence of logical connector with
  all the other connectors in the set

if !(a b)
if !(a b)
if (a b)
if (a c)
if (a c)
52
Relational Operator Replacement (ROR)

• Set of relational operators equal, not_equal,
  greater_than, less_than, greater_than_or_equal,
  less_or_equal_then
• Replace each occurrence of relational operator
  with all the other operators in the set

if (a ! b)
if (a gt b)
if (a lt b)
if (a b)
if (a gt c)
if (a lt c)
53
Unary Operator Injection (OUI)

• Set of unary operators negative, inversion
• Replace each occurrence of unary operator with
  the other operator in the set

a !b
a b
54
More mutation examples

• Constant value mutation
• Replacing signals with other signals
• Mutating control constructs
• .....

55
Approaches for SW HW

• Vidroha Debroy and W. Eric Wong, Using Mutation
  to Automatically Suggest Fixes for Faulty
  Programs, Software Testing, Verification and
  Validation Conf., June 2010.
• Raik, J. Repinski, U. et al. High-level design
  error diagnosis using backtrace on decision
  diagrams. 28th Norchip Conference 15-16 November
  2010.

56
Motivational example
ba-b
a-b
56
57
Motivational example
Passed sequence
Failed sequence
57
58
Motivational example
Backtrace cone Passed sequence
Backtrace cone Failed sequence
58
59
Statistical analysis

• Ranking according to suspiciousness

Suspiciousness score
Circuit blocks
59
60
Fault localization experiments

• Step1 Critical path tracing of mismatched
  outputs (max Failed)
• Step2 Max ratio (Failed/PassedFailed) of
  backtrace cones

60
61
Advantages open questions

• Mutation-based repair is readable
• Helps keeping user in the loop
• Provides a global repair, for all stimuli
• How does this backtracing based method perform in
  the case of multiple errors?
• What would be a good fault model for high-level
  design errors?

62
Future trends

• The quality of localization and correction is
  dependent on input stimuli
• Thus, diagnostic test generation needed
• Readable, small correction prefered
• Correction holds normally only wrt given input
  vectors (e.g. Resynthesis)
• Why should we replace an easily detectable bug
  with a more difficult one?!

63
Idea HLDD-based correction

• A canonical form of high-level decision diagrams
  (HLDD) using characteristic polynomials
• It allows fast probabilistic proof of equivalence
  of two different designs.
• Idea Extend it towards correction

64
Prototype tools, activities
65
FP7 Project DIAMOND

• Start January 2010, duration 3 years
• Total budget 3.8M
• EU contribution 2.9M
• Effort 462.5 PM

66
The DIAMOND concept
67
FORENSIC

• FoREnSiC Formal Repair Engine for Simple C
• For debugging system-level HW
• Idea by TUG, UNIB and TUT at DATE10
• Front-end converting simple C descriptions to
  flowchart model completed
• 1st release expected by the end of 2011

68
Forensic Flow
69
APRICOT Design Verification
Extensions of BDD ? HLDD ? THLDD
70
APriCoT Verification System

• Assertion/Property checkIng, Code coverage Test
  generation
• The tools run on a uniform design model based on
  high-level decision diagrams.
• The functionality includes currently
• test generation,
• code coverage analysis,
• assertion-checking,
• mutation analysis and
• design error localization

71
ZamiaCAD IDE for HW Design

• ZamiaCAD is an Eclipse-based development
  environment for hardware designs
• Design entry
• Analysis
• Navigation
• Simulation
• Scalable!
• Co-operation with IBM Germany, R. Dorsch

72
To probe further...

• Functional Design Errors in Digital Circuits
  Diagnosis, Correction and Repair
• K. H. Chang, I. L. Markov, V. Bertacco
• ...............................................
  
• Publisher Springer
• Pub Date 2009