Travis Doom

1
Formal Design Recovery for Obsolete Digital
Systems

• Travis Doom
• Wright State University
• Computer Science and Engineering

2
Outline

• Overview
• Reengineering
• Digital Design
• Formal Verification
• Motivation
• Obsolete Component Problem
• State-of-the-art in Design Recovery
• Proposed Reengineering Approach
• Semantic Pattern Matching
• Structural Binary Decision Diagrams (SBDDs)
• Example simplecircuit
• Conclusion and Future Work

3
Overview Reengineering

• General model for reengineering (Byrne, 1992)

Alteration
Con- ceptual
Con- ceptual
re-think
Reverse Engineering Abstraction
Forward Engineering Refinement
re-specify
Requirements
Requirements
re-design
Design
Design
re-build
Implementation
Implementation
Existing System
Target System
4
Overview Reengineering

• Remanufacture / Cloning

Alteration
Con- ceptual
Con- ceptual
Reverse Engineering Abstraction
Forward Engineering Refinement
Requirements
Requirements
re-design
Design
Design
Design Recovery
Implementation
Implementation
Existing System
Target System
5
Overview Digital Design

• Design Process

Behavioral Level
high-level synthesis
Register Transfer Level
logic synthesis
Gate Level
geometrical synthesis
Physical Design
6
Overview Verification

• Design Process

Behavioral Level
V e r i f i c a t i o n
compilation
high-level synthesis
compilation simulation
Register Transfer Level
logic synthesis
compilation simulation
Gate Level
geometrical synthesis
Physical Design
simulation
7
Overview Formal Verification

• Traditional verification by compilation/simulation
  
• Unless exhaustive, simulation does not provide
  full coverage
• Formal verification
• The goal of Formal Verification (FV) is to
  mathematically prove or disprove the correctness
  of the design translation
• FV equivalence checking of designs is known to be
  intractable
• co-NP complete
• heuristic techniques to achieve efficient
  performance
• Popular FV approaches
• Theorem Proving
• Symbolic Model Checking / CTL
• Functional/Recursive Learning

8
Outline

• Overview
• Reengineering
• Digital Design
• Formal Verification
• Motivation
• Obsolete Component Problem
• State-of-the-art in Design Recovery
• Proposed Reengineering Approach
• Semantic Pattern Matching
• Structural Binary Decision Diagrams (SBDDs)
• Example simplecircuit
• Conclusion and Future Work

9
The Obsolete Component Problem

• Micro-electronic components enable smart
  systems
• Prevalent in critical systems (Aerospace, Power,
  et. al.)
• Components are subject to exhaustive and
  expensive testing
• Components in the field must be maintained and
  modernized
• Components are obsolete before deployment
• Advances in fabrication technology cause
  immediate obsolescence
• Diminished Manufacturing Sources (DMS)
• Significant resources are spent on cloning old
  technologies
• Using new process lines requires new
  development and testing

10
The Obsolete Component Problem

• Goal
• Formal design recovery to provide retroactive
  documentation of existing, fully tested,
  components
• Identify the functional (block-level) roles of
  system components
• Primary source of information should be physical
  hardware
• Use any/all available information (complete or
  incomplete)
• Detect conflicting information
• Partial sources of information are usually
  available
• physical hardware
• software source code
• test program sets
• manufacturing artwork
• data from obsolete CAD tools

11
State-of-the-art in Design Recovery

• REW98

Behavioral Level
Sample Preparation
REW98
Model Generation Domain Specific Info.
Etching
Register Transfer Level
Image Acquisition
Syntactic Pattern Matching Semantic Pattern
Matching
SEM Staging Image Processing BMP to GDL
Gate-level Netlist
Syntactic Pattern Matching
Geometric Description
Transistor Netlist
DRC
12
Outline

• Overview
• Reengineering
• Digital Design
• Formal Verification
• Motivation
• Obsolete Component Problem
• State-of-the-art in Design Recovery
• Proposed Reengineering Approach
• Semantic Pattern Matching
• Structural Binary Decision Diagrams (SBDDs)
• Example simplecircuit
• Conclusion and Future Work

13
Semantic Pattern Matching Approach

• Register-Transfer-Level components need to be
  identified to reengineer systems for new
  technologies
• Structural (Syntactic) matching has limited
  application since high-level components have many
  valid implementations
• Design optimizations for area and power may
  obfuscate implementations, causing syntactic
  techniques to fail
• Functional (Semantic) techniques are necessary

14
Semantic Equivalence Checking

• The function of an arbitrary combinational design
  is semantically equivalent to the function of a
  high-level component if input and output
  correspondences exist under which the functions
  are equivalent
• Existing semantic matching techniques required
  factorial exploration of the input and output
  correspondence search space

4-bit ALU
Unknown Circuit
sel0-3
F0-3
A0-3
AeqB
?
B0-3
X
I0-13
O0-7
m
Y
Cin
Cout
O(14!8!) correspondences
14 inputs
8 outputs
14 inputs
8 outputs
15
Semantic Equivalence Checking

• The lack of correspondence information
  differentiates formal design recovery from formal
  verification
• Semantic matching shares many characteristics
  with the Boolean matching performed during
  technology mapping
• Function signatures and filters
• A signature of a Boolean function is a unique
  characteristic representation of some property of
  the function
• Used as filters in Boolean matching
• Boolean matching techniques focus upon
  single-output functions with a small number of
  inputs and are not applicable in general
• We have extended these techniques to provide a
  mechanism for more efficiently determining
  semantic equivalence

16
Example Vector Input Signature

• We define the positive (negative) vector input
  signature for any input to be the 1-sum of the
  combinational circuits outputs when a logical 1
  (0) is applied to that input and a logical 0 (1)
  is applied to every other input

Combinational Circuit
01000000000000
00101000
I0-13
O0-7
10110101
10111111111111
vector signature suspect set for I1 lt2,5gt
17
Suspect Sets for the 4-bit ALU

• We use input signature functions to partition
  device inputs into arbitrarily complex
  equivalence classes (suspect sets)

Vector signature suspect sets
for the 4-bit ALU lt1,7gt sel1, Cin lt2,5gt
A0 lt3,5gt A1, A2, A3 lt2,2gt sel3 lt2,7gt
sel0, sel2, B0, B1, B2, B3 lt6,5gt m
Using the vector signature alone reduces the
number of input variable correspondences from
14! (8.7 x 1010) to
2!1!3!1!6!1! (8.3 x 103)
18
Example Vector Input Signature

• Input correspondences need only be considered
  between members of corresponding suspect sets
• In order for two functions to be equivalent, they
  must have the same number of inputs in
  corresponding suspect sets
• Suspect sets can be reduced in size by repeated
  application of input signatures
• Any input signature can be used

Consider some of the input vectors that can
created from existing suspect sets to further
differentiate correspondences in the 4-bit ALU
. . .
19
Representing available information

• Design Recovery is challenging as some
  information about the circuit may be unavailable
• It is necessary to be able to recognize the
  functionality of any set of circuit components
  from available information
• Deduction may be required
• Complete deduction of functionality may be
  impossible in an incompletely specified
  implementation
• Existing information may be contradictory
• Such conflicts must be detected so that they may
  be resolved

20
Representations of External Function

• BDDs

X1
F
F
X2
M2
M1
M4
M3
X3
Schematic of simplecircuit
F ? ?X1 ? ((?X2 ? X3) ? (X2 ? ?X3))
ARCHITECTURE behavioral OF simplecircuit
IS BEGIN F lt (not X1) and ((not X2) and X3) or
(X2 and (not X3))) after 10 ns END behavioral
21
BDD Representation of Simplecircuit

• BDDs

X1
BDD for F
0
X2
1
1
0
X3
X3
0
0
1
1
F ? ?X1 ? ((?X2 ? X3) ? (X2 ? ?X3))
1
0
ARCHITECTURE behavioral OF simplecircuit
IS BEGIN F lt (not X1) and ((not X2) and X3) or
(X2 and (not X3))) after 10 ns END behavioral
22
BDD Representation of Simplecircuit

• BDDs

X1
BDD for F
0
X2
1
1
0
X3
X3
0
0
1
1
F ? ?X1 ? ((?X2 ? X3) ? (X2 ? ?X3))
1
0
ARCHITECTURE behavioral OF simplecircuit
IS BEGIN F lt (not X1) and ((not X2) and X3) or
(X2 and (not X3))) after 10 ns END behavioral
23
BDD Representation of Simplecircuit

• BDDs

X1
BDD for F
0
X2
1
1
0
X3
X3
0
0
1
1
F ? ?X1 ? ((?X2 ? X3) ? (X2 ? ?X3))
1
0
ARCHITECTURE behavioral OF simplecircuit
IS BEGIN F lt (not X1) and ((not X2) and X3) or
(X2 and (not X3))) after 10 ns END behavioral
24
Representations of Internal Function

• BDDs

X1
F
F
X2
M2
M1
M4
M3
X3
Schematic of simplecircuit
ARCHITECTURE structural OF simplecircuit IS
SIGNAL M1, M2, M3, M4 bit BEGIN gate0 nor2
PORT MAP ( O gt M1, agt X2, b gt X3 ) gate1
nor2 PORT MAP ( O gt M2, agt X2, b gt M1 )
gate2 nor2 PORT MAP ( O gt M3, agt M1, b gt X3
) gate3 nor2 PORT MAP ( O gt M4, agt M1, b gt
M3 ) gate4 nor2 PORT MAP ( O gt F, agt X1,
b gt M4 ) output probe PORTMAP ( F ) END
structural
25
Representations of Internal Function

• BDDs

X1
F
F
X2
M2
M1
M4
M3
X3
Schematic of simplecircuit
X1
0
BDD representing the characteristic function of
NOR gate M1 (M1 ? ?(X2 ? X3) )
1
X2
0
1
M1
M1
1
1
0
0
1
0
26
Representations of Internal Function

• BDDs

X1
X2
X3
M1
M2
(M1 ? ?(X2 ? X3) ) ? (M2 ? ?(X2 ? M1) ) ? (M3 ?
?(X3 ? M1) ) ? (M4 ? ?(M2 ? M3) ) ? (F ? ?(X1
? M4) )
M3
M4
F
BDD representing structural relationships All
edges not shown lead to the 0-terminal
1
27
Representations of Internal Function

• BDDs

X1
X2
X3
M1
M2
(M1 ? ?(X2 ? X3) ) ? (M2 ? ?(X2 ? M1) ) ? (M3 ?
?(X3 ? M1) ) ? (M4 ? ?(M2 ? M3) ) ? (F ? ?(X1
? M4) )
M3
M4
F
BDD representing structural relationships All
edges not shown lead to the 0-terminal
1
28
Representations of Partial Function

• BDDs

X1
F
F
X2
M2
M1
M4
M3
X3
Schematic of simplecircuit
29
Representations of Partial Function

• BDDs

X1
F
F
X2
BB
M1
X3
Partial schematic of simplecircuit
30
Structural BDDs (SBDDs)

• We define a more relaxed characteristic
  function
• Any variable assignment which leads to the
  0-terminal (a 0-path) contradicts known
  relationships (is illegal)
• Any variable assignment which leads to the
  1-terminal (a 1-path) is not known to cause a
  contradiction (may be legal)
• SBDDs are an interpretation of BDDs
• SBDDs represent the structure function of a
  combinational device
• SBDDs allow for the representation of partial
  Boolean functions involving represented variables

31
Representations of Partial Function

• BDDs

X1
X2
X3
M1
BB
F
1
SBDD representing structural relationships All
edges not shown lead to the 0-terminal
32
Representations of Partial Function

• BDDs

X1
X2
X3
M1
BB
F
1
SBDD representing structural relationships All
edges not shown lead to the 0-terminal
33
Representations of Partial Function

• Available information from any design level must
  be represented formally
• We introduce new relationships between any of the
  represented decision variables by constraining
  all 1-paths which contradict the relationship

X1
X2
X3
F
1
0
constraint function
BDD representing the functional constraint f
(X1,X2,X3) ? F f (0,1,0) (1) i.e. ( ?X1 ?
X2 ? ? X3 ) ? F
ATPG Test Vectors
34
Representations of Partial Function

• BDDs

X1
X1
X2
X2
X3
X3
M1
M1
BB
BB
F
F
1
1
Original SBDD
SBDD after applying test vector (0,1,0) 1
ATPG Test Vectors
35
Representations of Partial Function

• BDDs

X1
X2
X3
M1
Specification of BB
BB
F
1
SBDD after applying all test vectors
ATPG Test Vectors
36
SBDD Results

• Completely specified circuits
• If no unknown nodes remain in a SBDD, then we
  know the behavior of all blackbox structures
  under all assignments in which the structures
  value is not dont care
• Incompletely specified circuits
• If unknown nodes remain, then the overall
  function is not fully specified additional
  information is necessary
• Conflicting circuits
• If input assignments exist in which no legal
  1-path exists, then no behavior will satisfy the
  constraints given

37
Proposed Reengineering Approach

• Partitioning
• Determine combinational test cluster
• Represent available information
• Create SBDD representing available partial
  information
• Complete specification
• Determine functionality which remains unspecified
• Provide a minimal set of information (such as a
  set of vectors) sufficient to specify behavior
• Determine this information through deduction,
  testing, et al.
• Match functional behavior
• Determine block-level functionality with Semantic
  Matching
• Use signature analysis to reduce complexity

38
Outline

• Overview
• Reengineering
• Digital Design
• Formal Verification
• Motivation
• Obsolete Component Problem
• State-of-the-art in Design Recovery
• Proposed Reengineering Approach
• Semantic Pattern Matching
• Structural Binary Decision Diagrams (SBDDs)
• Example simplecircuit
• Conclusion and Future Work

39
Conclusion

• Contributions
• Structural Binary Decision Diagrams (SBDDs)
• Graphical representation of the structure
  function
• Represents Boolean relationships (partial
  information)
• May allow deduction of complete functional
  specification
• Identifies conflicting design information
• Semantic Equivalence Checking
• Efficiently determines equivalence for many
  combinational modules
• Allows the identification of larger block-level
  modules
• Proposed Approach
• Formal recovery of a RTL description from a
  gate-level description

40
Future Work

• Matching in highly-optimized/obfuscated circuits
• Dont care optimizations
• Identification of obfuscated intellectual
  property, et al.
• Partitioning/candidate subcircuit enumeration
• Scalability
• Size depends upon the nature of the relationships
  / structure / et al.
• Increasingly efficient BDD algorithms
• How applicable can these techniques be made
  towards solving problems under current and future
  technologies?
• RTL to behavioral-level specification
• The RTL description identifies data lines,
  control lines, and provides other additional
  knowledge that may allow deduction of the
  behavioral-level specification

41
Questions?

• Thank you

42
Semantic Matching Algorithm

• Create representation of function
• Create a BDD for each output of each function
• Determine signature classes
• Determine input signature classes for each input
  of each function
• Determine suspect sets
• Partition function inputs into equivalence
  classes
• Apply additional signature functions as necessary
• Iterate though input correspondences
• Consider only correspondences between similar
  suspect sets
• Similarity prunes the search space
• Determine valid output correspondences
• For each legal input correspondence, reorder BDD
  variables and compare each pair to determine
  legal output correspondence

43
Semantic Equivalence Results
44
SBDD Algorithm

• Initialization
• Apply constraints
• Iterative process
• Reduce SBDD size where possible
• Identify conflict
• Input assignments under which no 1-paths exist
  have conflict
• Determine completeness of specification
• Iterative process
• Acquire required knowledge if possible
• Deduce secondary constraints
• Acquire necessary I/O relationships from physical
  hardware
• Specify blackbox structures
• Specify overall function

45
Preliminary SBDD Results