Transcript Formal Verification of Systems-on-Chip – Industrial Experiences and Scientific Perspectives Wolfgang Kunz Department of Electrical & Computer Engineering University of Kaiserslautern, Germany.

Formal Verification of Systems-on-Chip
– Industrial Experiences
and Scientific Perspectives
Wolfgang Kunz
Department of Electrical & Computer Engineering
University of Kaiserslautern, Germany
Acknowledgements
Minh Nguyen, Dominik Stoffel, Max Thalmaier, Markus Wedler
Industrial partners:
slide 2
Outline
 System-on-Chip verification tasks
 A methodology for RT-level module verification
 Challenges in module verification
 A methodology for RT-level verification of module interfaces
 Challenges in module interface verification
 Conclusion
slide 3
Example: SoC for automotive application
• processors
• hardware accelerators
• memories
• I/O controllers
• mixed signal blocks
• communication structures
slide 4
SoC Design Flow
Early phase
 set up and assess functional
prototypes
Architecture
spot
 Hot
model
andfor
explore architectural
choices Checking:
Property
 specify modules and communication
for target
Verify
that architecture
RTL implementation
fullfills specification
Design (RT)
 Register-Transfer (RT) description of
modules
 system integration, communication
structures
Implementation
 Synthesis and optimization
 test preparation
slide 5
RT-level module verification
A typical property for RT-level module verification:
AG(a  c)
a : assumptions
- module is in some control state V
- certain inputs X occur
c : commitments
- module goes into certain control state V’
- certain outputs Y occur
slide 6
RT-level module verification: operation by operation
Control 1
Property 1: AG(acontrol 1  ccontrol 2)
/ data_path_control_signals
data path
n cycles
Control 2
Property 2: AG(acontrol 2  ccontrol …)
slide 7
RT-level module verification
AG(acontrol 1  ccontrol 2)
j n
Control 1
acontrol 1 :
acontrol 1(V )   AX j (a j ( X ))
j 0
j n
ccontrol 2 :
 AX j (c j ( X ,Y ))  AX n (ccontrol 2 (V ))
j 0
V: state variables
/ data_path_control_signals
n cycles
data path
Control 2
slide 8
Property for RT-level module verification
Interval Temporal Logic™
AG(a  c)
j n
a  astart (V )   AX j (a j ( X ))
j 0
j n
c   AX j (c j ( X , Y ))  AX n (cend (V ))
j 0
property myExample is
assume:
at t: astart(V);
//starting state //
at t: a0(X);
at t+1: a1(X);
at …
at t+n: an(X);
prove:
at t: c0(X,Y);
at t+1: c1(X,Y);
at …
at t+n: cn(X,Y);
at t+n: cend(V);
//ending state //
end property;
V: state variables, X: inputs, Y: outputs
slide 9
BMC formulation
Properties are proved for finite time interval!
Y0 X1
Y1
X2
Y2
bound k
X0
, 
V0  S0
, 
, 
V2
V1
V3
Property of length n = 3
satisfiable?
generate SAT instance:
k n
I (V )   T (V , X ,V
0
i
i 0
initial states
i
i 1
k
)  [ p ] t
t 0
transition relation propositional formula for
unrolled k+n times internal formula of AGp,
k instances
slide 10
BMC formulation with invariants
Proving safety properties (AGp) by BMC with invariants
Yt Xt+1
Yt+1 Xt+2
Yt+2
Xt
, 
Vt
, 
, 
Vt+2
Vt+1
Vt+3
satisfiable?
Property of length n = 3
generate SAT instance:
t n
 (V )   T (V i , X i ,V i 1 )  [ p] t
t
i t
Invariant
(special case:  = 1)
transition relation
unrolled n times
one instance of propositional
formula for property
slide 11
BMC with invariants: “Interval Property Checking”
Proving AGp
t n
 (V )   T (V t i , X t i ,V t i 1 )  [ p] t
t
i t
Invariants: sets of states closed under reachability
Invariants in this formulation compared to invariants in most other
model checking techniques:
• can be weaker
• can be of simpler syntactic forms
• are more intuitive to the designer
slide 12
Interval Property Checking
The good cases…
System-on-Chip
RISC
=1
DSP
=1
Module Interfaces
I/O controller
=1
=1
HW accelerator
=1
holds in most cases when
verifying individual modules
slide 13
TriCore 2 Microprocessor System of Infineon
MMU
Program
Cache
Program
Scratch RAM
Program
Scratch RAM
Interrupts
Other IP
I
n
t
e
r
f
a
c
e
FPU
TriCore 2
Core
Bus Interface Unit
I
n
t
e
r
f
a
c
e
Data Cache
Data
Scratch RAM
Data
Scratch RAM
Interrupt &
Debug Unit
Crossbar (64 bit)
Other IP
Architectural characteristics
– unified 32-Bit-RISC/DSP/MC
architecture
– 853 instructions
– 6-stage superscalar pipeline
– multithreading extensions
– coprocessor support/floating point unit
Current Implementation
– 0.13 micron technology
– 3 mm2 core area/8 mm2 hardmacro
area
– typical frequency ~ 500 MHz
– typical compiled code 1.5 MIPS / MHz
– 2 MMACS/MHz, 0.5 mW/MHz @ 1.5 V
Bridge
Deployment
primarily in automotive high-end
System Bus
formally verified
slide 14
The Tricore II project – some results
Performance of property checking
 99.9 % of properties run in less than 2 minutes on solaris machine
 current property suite runs in 40 hours on 1 solaris machine
Productivity
 2k LoC per person month exhaustively verified
Quality
 formal techniques identified bugs that are hard or impossible to
find by conventional technique
 drastic reduction of errata sheets seems realistic
slide 15
Infineon Tricore 2 project – scientific challenges
Advanced DSP features of embedded processors
impose new challenges for formal verification
MAC Unit: multiply, multiply/add,
multiply/subtract
saturation, rounding,
shift-bits
 300 different instruction variants
e.g.
 MUL.H
- packed multiply
- 2 parallel multiplications
- 8 variants +12 special cases
- 16 bit operands
- 64 bit result
 MADD(S).Q
- multiply/add in Q-format
- 40 variants + 24 special cases
- 32/16 bit operands
- 64/32 bit results
- some variants with saturation
slide 16
Verification of Integer Pipelines
Goal: Prove that instructions are performed correctly
Example:
theorem mul;
// packed half word multiplication
assume:
at t: command_dec(MUL,op1,op2);
during[t,t+3]: no_reset;
during[t,t+3]: no_cancel;
…
prove:
at t+3: ip_res[31:0]
== op1[15:0]*op2[15:0];
at t+3: ip_res[63:32]
== op1[31:16]*op2[31:16];
end
slide 17
Pipelined data path with multiplication


data path implements large number of operations
complex interaction between control and data path
 bit width reduction may miss corner cases


optimizations for performance and resource sharing
designer specifies arithmetic blocks at the bit-level
 word level abstraction impossible
instr.
pipeline control
control flags
+/-/
data
+/-/
+/-/
overflow
+/-/
+/-/
+/-/
arithmetic result
overflow detection / saturation
slide 18
Research activities
Design Code

- modulo 2 addition (XOR, HA, FA))
- partial products
- comparators
ABL

Normalized
ABL
CNF (SAT-prover)
Arithmetic Bit-Level Description (ABL)
network of elementary arithmetic
operations
ABL Normalization using arithmetic
reasoning
Arithmetic correctness formally proved for
all Tricore2 instructions with multiplication
and all their variants ( 300) at full bit width
[M. Wedler, D. Stoffel, R. Brinkmann, W. Kunz: “A Normalization
Method for Arithmetic Data Path Verification”, IEEE Trans. on
CAD, November 2007]
slide 19
Interval Property Checking
The difficult cases…
1
System-on-Chip
RISC
1
DSP
Module Interfaces
I/O controller
1
HW accelerator
1
1
for implementations of SoC protocols !
slide 20
Interval Property Checking
The difficult cases…
  1 for implementations of SoC protocols !
property myExample is
assume:
at t: astart(V); //starting state + reachability inf. //
at t: a0(X);
at t+1: a1(X);
at …
at t+n: an(X);
prove:
at t: c0(X,Y);
at t+1: c1(X,Y);
at …
at t+n: cn(X,Y);
at t+n: cend(V);
//ending state //
end property;
slide 21
Example
Property
IDLE
input = REQ
assume:
at t: (state = IDLE && input = REQ)
prove:
at t+n: (state = READY && output = ACK)
cnt ≠ n
cnt = n
/ output := ACK
IDLE and READY are specified by asserting
certain state bits in the global state vector
READY
m-1
q
p
…1 0
global state vector with m bits
slide 22
Example
Property
IDLE
input = REQ
cnt ≠ n
assume:
at t: (state = IDLE && input = REQ)
prove:
at t+n: (state = READY && output = ACK)
False negative !
(counter-example: only READY after n-1 cycles)
cnt = n
/ output := ACK
Missing reachability constraint:
state = IDLE  cnt = 0
READY
m-1
q
p
…1 0
slide 23
Interval Property Checking
Typical invariants:
All states of the code space that fulfill certain “reachability
constraints”.
Reachability constraints are often expressed in terms of
simple relations (implications, equivalences…) on state bits.
state = IDLE  cnt = 0
m-1
q
p
…1 0
global state vector with m bits
slide 24
Example
Property
IDLE
input = REQ
assume:
at t: (state = IDLE && input = REQ
&& cnt = 0)
prove:
at t+n: (state = READY && output = ACK)
cnt ≠ n
Property proven !
cnt = n
/ output := ACK
READY
slide 25
Methodology
The difficult cases…
informal
specification
RTL
description
writes
properties
finds reachability
constraints updates
properties
properties
(ITL)
property checking
(interval-based)
false
negative?
property
holds
property fails
counterexample
true
negative?
slide 26
Interval Property Checking
IDLE
input = REQ
cnt ≠ n
Observation: common design styles for
implementing protocols employ a hierachical
design style. There is a central FSM that controls
the overall behavior of the design. Its states can
directly be associated with the states of the
protocol specification
Key idea: identification of a “main-FSM”
cnt = n
/ output := ACK
READY
Main state bits
m-1
q
p
…1 0
slide 27
Design Style for Communication Module
Many designs that implement on-chip communication structures (protocols)
have a hierarchy consisting of a main FSM and several layers of sub-FSMs.
sub FSM
sub FSM
sub FSM
main FSM
sub FSM
sub FSM
sub FSM
Commercial tools exist to extract and visualize the main-FSM.
slide 28
Protocol Compliance Verification
Main FSM
State variables of the main FSM:
0  p  q  m-1
State transition graph ( Sˆ , Tˆ ) represents main FSM
Each main state sˆ  Sˆ belongs to a set of states S sˆ
10110 xx10110xxx
ŝ1
S ŝ1
ŝ2
S ŝ2
Sˆ  {sˆ0 , sˆ1, sˆ3 }
ŝ3
S ŝ3
slide 29
Unbounded Protocol Compliance Verification using BMC
Specify properties in terms of main states
ŝ1
S ŝ1
ŝ2
Main state bits
S ŝ2
property myExample is
assume:
at t: Vˆ  sˆ1 ;
//starting main-state //
at t: a0(X);
at t+1: a1(X);
at …
at t+n: an(X);
prove:
at t: c0(X,Y);
at t+1: c1(X,Y);
at …
at t+n: cn(X,Y);
at t+n: Vˆ  sˆ2 ;
//ending main-state //
end property;
slide 30
Unbounded Protocol Compliance Verification using BMC
Specifying properties based on the main-FSM
•
is intuitive,
•
global understanding of design is sufficient
•
code inspection restricted to main-FSM
But:
•
it does not solve the false negative problem
slide 31
Traversal: transition by transition
Idea: “Transition-by-Transition (TBT)” traversal
compute the sets Ssˆ step by step according to the transitions of the main FSM
ŝ1
S ŝ 4
ŝ4
S ŝ1
ŝ2
ŝ3
S ŝ2
S sˆ1  sˆ3 S ŝ3
S sˆ2  sˆ3
S sˆ3  img sˆ1 sˆ3 ( S sˆ1 )  img sˆ2 sˆ3 ( Ssˆ2 )
[M. D. Nguyen, D. Stoffel, M. Wedler, W. Kunz: "Transition-by-Transition FSM
Traversal for Reachability Analysis in Bounded Model Checking", ICCAD-05]
slide 32
Methodology
RTL
description
automatic
extraction
informal
specification
main FSM
TBTtraversal
reachability
constraints
finds reachability
constraints updates
properties
writes
properties
properties
(ITL)
property checking
(interval-based)
false
negative
property
holds
property fails
counterexample
true negative
slide 33
Industrial case study
Industrial design (flash-memory controller using AMBA-flavor protocol):
493 state variables, 23 properties to prove
– compliance with protocol specification
– correct execution of functional operations
main FSM: 38 states, 103 transitions (extracted automatically by Debussy®)
Verification effort without proposed approach:
approximately 1 person month
70% of the time needed for code inspection to refine reachability constraints
Results with proposed approach:
38 reachability constraints identified: used as assumption in properties
total CPU time: 0:07:10h
all properties proved, no manual refinements needed!
slide 34
Some comparisons
Interval property checking
Abstraction refinement (based
on localization reduction)
Approximating state space by iterative
automaton model + invariants
Approximating state space by
partitioning state vector in concrete
and abstract state variables
Refinement by strengthening of
invariants (automatic and manual)
Refinement by concretization of state
variables (automatic)
Invariants often intuitive and of simple
syntactic form
Abstractions not intuitive (?)
Tailored towards Property Checking of
SoC modules and interfaces
Generic
slide 35
Some comparisons
Interval property checking
Predicate Abstraction
Select main-FSM based on intuition
(or automatically)
Select predicates based on intuition
(or automatically)
Use main-FSM to decompose state
space and to compute invariants
Build abstract machine
Run property checking on original
design with invariants
Run model checking on abstract
machine
Different strategy of exploiting abstract machine
slide 36
Conclusion
FV for modules getting established, what's next?
Correctness by integration…
 Better leverage of low level
guarantees in high level verification
 Better synergy between automatic and
manual abstractions
System level
verification
Low level
guarantees
 FV of interfaces (communication)
 FV of modules (computation)
50% algorithms plus 50% methodology!
slide 37