So CVerification

SoC Verification ( 晶片系統驗
證)
Pao-Ann Hsiung ( 熊博安 )

hpa@computer.org http://www.cs.ccu.e
du.tw/~pahsiung/
嵌入式系統實驗室
國立中正大學資訊工程學系
Contents
 Introduction 3 ~ 26
 Formal Verification 27 ~ 38
 Model Checking 39 ~ 73
 Equivalence Checking 74 ~ 83
 Verification Tools 84 ~ 86
 Verification Example:
Industrial Embedded SoC87 ~ 98
 Conclusion & Future Work 99 ~ 100
2
Pao-Ann Hsiung, CSIE, National Chung Cheng University
Introduction
1998 1999 2001
Process Technology 0.25 um 0.18 um 0.15 um
Silicon Complexity 1 M Gates 2~5 M Gates 5~10 M Gates
M O O R E’ S L A W
Deep Sub-Micron (DSM) Technology 3

Introduction
Challenges in DSM technology for SoC:
 Timing Closure
 Sensitive to interconnect delays
 Large Capacity
 Hierarchical design and design reuse
 Physical Properties
 Signal integrity (crosstalk, IR drop,
power/ground bounce)
 Design integrity (electron migration, hot
electron, wire self-heating) 4
Introduction
Gates / Chip
Design Gates / Hour

Productivity Gap
1990 1995 2000
5
Introduction
Time-to-Market (TTM) Trends

6
Introduction
Multiple Design
Disciplines:
 Digital HW
 Embedded SW
 Analog/Mixed
Signal (AMS) Blocks
 Bus Architectures
 Clock / Power
Distributions
 Test Structures
7
Introduction
SoC Verification v/s Design Gap

8
Verification Options
 Simulation Technologies
 Static Technologies
 Formal Technologies
 Physical Verification and Analysis
9
Simulation Technologies
 Event-based Simulators
 Cycle-based Simulators
 Transaction-based Simulators
 Code Coverage
 HW/SW Co-verification
 Emulation Systems
 Rapid Prototyping Systems
 Hardware Accelerators
 AMS Simulation
10
Static Technologies
 Lint Checking
 Syntactical correctness
 Identifies simple errors
 Static Timing Verification
 Setup, hold, delay timing requirements
 Challenging: multiple sources
11
Formal Techniques
 Theorem Proving Techniques
 Proof-based
 Not fully automatic
 Formal Model Checking
 Model-based
 Automatic
 Formal Equivalence Checking
 Reference design  modified design
 RTL-RTL, RTL-Gate, Gate-Gate implementations
 No timing verification
12
Physical Verification & Analysis
Issues for physical verification:
 Timing
 Signal Integrity
 Crosstalk
 IR drop
 Electro-migration
 Power analysis
 Process antenna effects
 Phase shift mask
 Optical proximity correction

13
Comparing Verification
Options
14
Comparing HW/SW Coverificat
ion Options
15
Which is the fastest option?
 Event-based simulation
 Best for asynchronous small designs
 Cycle-based simulation
 Best for medium-sized designs
 Formal verification
 Best for control-oriented designs
 Emulation
 Best for large capacity designs
 Rapid Prototype
 Best for software development
16
SoC Verification Methodology
 System-Level Verification
 SoC Hardware RTL Verification
 SoC Software Verification
 Netlist Verification
 Physical Verification
 Device Test
17
SoC Verification Methodology
18
Verification Approaches
 Top-Down Verification
 Bottom-Up Verification
 Platform-Based Verification
 System Interface-Driven Verification
19
Top-Down SoC Verification
verification
20
Bottom-Up SoC Verification
Components,
blocks, units
Memory map,
verification
internal interconnect
Basic functionality,
external interconnect
System level
21
Platform Based SoC Verification
Derivative
Design
Interconnect
Verification be
tween:
 SoC Platform
 Newly added I
Ps
22
System Interface-driven
SoC Verification
Besides Design-Under-Test,
all others are interface models
23
Device Test
 To check if devices are manufactured
defect-free
 Focus on structure of chip
 Wire connections
 Gate truth tables
 Not functionality
24
Device Test
Challenges in SoC device test:
 Test Vectors: Enormous!
 Core Forms: soft, firm, hard, diff tests
 Cores: logic, mem, AMS, …
 Accessibility: very difficult / expensive!
25
Device Test Strategies
 Logic BIST (Built-In-Self-Test)
 Stimulus generators embedded
 Response verifiers embedded
 Memory BIST
 On-chip address generator
 Data generator
 Read/write controller (mem test algorithm)
 Mixed-Signal BIST
 For AMS cores: ADC, DAC, PLL
 Scan Chain
 Timing and Structural compliance
 ATPG tools generate manufacturing tests automatically 26
Formal Verification
What is Formal Verification?
 An analytic way of proving a system
correct
 no simulation triggers, stimuli, inputs
Formal
 no test-benches, test-vectors, test-cases
Verification
Methods
 Deductive Reasoning (theorem proving)
 Model Checking
 Equivalence Checking
28
Theorem Proving
 Uses axioms, rules to prove system corr
ectness
 No guarantee that it will terminate
 Difficult, time consuming: for critical ap
plications only
29
Model Checking
 Automatic technique to prove
correctness of concurrent systems:
 Digital circuits
 Communication protocols
 Real-time systems
 Embedded systems
 Control-oriented systems
 Explicit algorithms for verification
30
Equivalence Checking
 Checks if two circuits are equivalent
 Register-Transfer Level (RTL)
 Gate Level
 Reports differences between the two
 Used after:
 clock tree synthesis
 scan chain insertion
 manual modifications
31
Why Formal Verification?
 Simulation and test cannot handle all
possible cases (only some possible ones)
 Simulation and test can prove the presence
of bugs, rather than their absence
 Formal verification conducts exhaustive
exploration of all possible behaviors
 If verified correct, all behaviors are verified
 If verified incorrect, a counter-example (proof)
is presented
32
Why Formal Verification Now?
 SoC has a high system complexity
 Simulation and test are taking
unacceptable amounts of time
 More time and efforts devoted to
verification (40% ~ 70%) than design
 Need automated verification methods
for integration into design process
33
Increased Simulation Loads
34
Why Formal Verification Now?
Examples of undetected errors
 Ariane 5 rocket explosion, 1996
 Exception occurred when converting 64-bit
floating number to a 16-bit integer!
 Pentium FDIV bug
 Multiplier table not fully verified!
35
36
Verification Tasks for SoC
37
Property Checking v/s Equival
ence Checking
38
Model (Property) Checking
 Algorithmic method of verifying
correctness
 of (finite state) concurrent systems
 against temporal logic specifications
 A practical approach to formal
verification
39
Model Checking
What is necessary for Model Checking?
 A mathematically precise model of the
system
 A language to state system properties
 A method to check if the system
satisfies the given properties
40
Model Checking
 Formal model of the system
 Finite State Machine (FSM)
 Desired behavior expressed as a set of
properties (specifications)
 Computation Tree Logic (CTL)
 Method to check properties against
system
 Efficient FSM traversals
41
Formal Models of System
Any mathematically precise model that ca
n be represented as a state transition syst
em
 Finite State Machines
 Petri Nets
 (Timed) Automata
 Statecharts
42
State Transition System
M(S, R, L)
s1
a S = {s1, s2, s3}
R = transition
relation
L = {a, b, c}
b ac
s2 s3
Kripke Structure
43
Formal Model v/s Verification
 表達能力 v/s 驗證複雜度找平衡點 !
語言的表達能力表達能力豐富
表
達 Undecidable
能
力 nonelementary
簡 EXPSPACE
單 EXPTIME
PSPACE 驗證問題複雜度
NP
PTIME
44
Property Specification
Languages
 Linear Temporal Logic (LTL)
 Computation Tree Logic (CTL)

 Timed Computation Tree Logic (TCTL)
 7 ms
45
CTL – Computation Tree Logic
 Path quantifiers
 A (for all computation paths)
 E (for some computation path)
 Temporal operators
 X (next time, next state)
 F (eventually, finally)
 G (always, globally)
 U (until)
 R (release, dual of U)
46
CTL Formulas
 Temporal logic formulas are evaluated
with respect to a state in the model
 State Formulas
 Apply to a specific state
 Path Formulas
 Apply to all states along a specific path
47
Basic CTL Formulas
 M, s |= E X (f )
 Exists a next state of s, for which f holds
s
 M, s |= A X (f )
 For all next states of s, f is true
s
f f
48
Basic CTL Formulas
 M, s |= E G (f )
 Exists a path from s, along which f holds i
n every state s
f
f
 M, s |= A G (f )
 For all paths from s, f holds in every state,
i.e., globally s
f
f f
49
Basic CTL Formulas
s  M, s |= E F (f )
 Exists a path from s, which eventually cont
ains a state in which f holds
f
s
 M, s |= A F (f )
 For all paths from s, eventually there is a st
f ate in which f holds
f
50
Basic CTL Formulas
s
f  M, s |= f U g
f
 Exists a path from s, which contains a state
in which g holds and in all previous states
g f holds
 E F (f ) = E (true U f )
 A F (f ) = A (true U f )
51
Basic CTL Formulas
 Full set of operators
 Boolean: , , , 
 Temporal: E, A, X, F, G, U, R
 Minimal set of operators
(to express any CTL formula)
 Boolean: , 
 Temporal: E, X, U
52
Typical CTL Formulas
 E F ( start   ready )
 Eventually a state is reached where start ho
lds and ready does not hold
 A G ( req  A F ack )
 Any time request occurs, it will be eventuall
y acknowledged
 A G ( E F restart )
 From any state it is possible to get to the re
start state
53
TCTL (Timed CTL)
 A G ( req  A F 7 ack )
 Time Constraint:
 Subscript “~ c ” is added to CTL formulas
 ~  {<, , =, , >}
 c is an integer
54
TCTL Example
x:=0; z:=0
監控 x 、 z 是實數值系統時鐘
x 、 z 在系統開 x<500ms 。
始時，被設為 z50ms
零。命中
z 在每次監控週期，
z=50ms 被設為零。
z:=0; 修正
M, 監控 |= E F<300 ( 命
中) Pao-Ann Hsiung, CSIE, National Chung Cheng University
55
Model Checking – Problem
Given:
 a structure M (S, R, L) and
 a temporal logic formula f,
find a set of states that satisfy f .
{s  S : M, s |= f }
56
Model Checking –
Explicit Algorithm
 Label each state s with the set label(s )
= { sub-formulas of f, which hold in s }
 i = 0; label(s ) = L (s )
 i = i + 1; process formulas with (i -1) n
ested CTL operators. Add processed for
mulas to label(s ).
 Continue until closure.
 Result: M, s |= f iff f  label(s )
57
Explicit Model Checking
E F  (g  h)
T1 = states in which g & h are
true
T2 = complement of T1
T3 = predecessor states of T2
58
Traffic Light Controller
C’ + T’
S T G1 R2
Farm Road C T
T S
R1 Y2 Y1 R2
City Road
C’ + T
S = Sensor
R1 G2
T = Timer Kripke Struc
C T’ ture
59
G1 R2
G1 R2 Y1 R2
State Graph
G1 R2 Y1 R2 R1 G2
Y1 R2 R1 G2 R1 Y2 R1 G2
R1 Y2 R1 G2 G1 R2
60
Model Checking Tasks
 Safety Condition
 No green lights on both roads at the same

time
A G  (G1  G2)
 Fairness Condition
 Eventually one road has green light
E F (G1  G2)
61
Traffic Light Controller –
Checking Safety Condition
 A G  (G1  G2)  C’ + T’
1
 E F ( G1  G2) G1 R2
 S(G1  G2) C T
= S(G1)  S(G2) 4
= {1}  {3} =  R1 Y2 Y1 R2
2
 S(EF(G1  G2) =  C’ + T
 S(EF(G1  G2) =  R1 G2
3
= {1, 2, 3, 4} Kripke Str
C T’
ucture
 Safety condition is true! 62
Traffic Light Controller –
Checking Fairness Condition
 E F (G1  G2) 
E(true U (G1  G2))
1 3
 S(G1  G2) = S(G1)  S(G2)
= {1}  {3} = {1, 3} 4 2
 S(EF(G1  G2)) = {1, 2, 3, 4}
(going backward from {1, 3}, find 3 1
predecessors)
 Fairness condition satisfied!
63
Symbolic Model Checking
 Symbolic
 Operates on “sets of states” rather than in
dividual states
 Use BDD for efficient representation
 Represent Kripke structures
 Manipulate Boolean formulas
64
Binary Decision Diagram
(BDD)
 BDD: A canonical form of
representation for Boolean formulas.
 Motivation:
 Too much space redundancy in traditional
representations
 BDD is more compact than truth tables,
conjunctive normal form, disjunctive
normal form, binary decision trees, etc.
 Ordered BDD has a canonical form
 BDD operations are efficient
65
BDD v/s Binary Decision Trees
2-bit Comparator
BDD
Binary Decision Tree Order: a1 < b1 < a2 < b2 66
Ordered BDD (OBDD)
 Since OBDDs are canonical, it is easy to:
 check equivalence = check BDD isomorphism
 check satisfiability = check BDD isomorphism
with OBDD(0)
 Size of OBDD depends critically on VARIABLE
ORDERING !!!
 2-bit comparator example:
Change variable order to: a1 < a2 < b1 < b2
11 vertices instead of 8 for a1 < b1 < a2 < b2
67
OBDD (Variable Ordering)
 a 1 < a2 < b 1 < b 2
 In general, for n-bit
comparator:
a1 < b1 < …< an < bn

gives 3n + 2 vertices
a1 < …< an < b1<…< bn

gives 3  2n  1 vertices
68
BDD: Application to Verification
 Equivalence of combinational circuits
 Canonicity property of BDDs:
 If F and G are equivalent, their BDDs are id
entical (for the same variable ordering)
a
a F=a’bc + abc + ab’c
?
b
b
c
c
G=ac + bc
0 1 69
0 1 Pao-Ann Hsiung, CSIE, National Chung Cheng University
BDD: Application to Verification
 Functional Test Generation a
 SAT, Boolean satisfiability anal

ysis ab’c b ab
 Test for H=1 (0):
find a path in BDD to terminal c
1 (0)
 The path, expressed in functio 0 1
n variables, gives a satisfying s
olution (test vector)
70
Model Checking Issues
Completeness
 Model checking is effective for a given
property
 Impossible to guarantee that the
specification covers all properties the

system should satisfy
 Writing the specification – responsibility
of the user
71
Negative Results
 Incorrect model
 Incorrect specification (false negative)
 Failure to complete the check (too
large)
72
Capacity
 State-space explosion occurs for
complex systems
 So, what is the use of Model Checking
for SoC?
 Use model checking as a
complementary technique, in addition

to simulation, testing, emulation, etc.
73
 Compares an implementation to an existing
RTL or gate-level description for functional
equivalence
 RTL vs. synthesized gate-level implementation
 Gate-level design vs. revised gate-level design
 Uses BDDs, a canonical representation of logic

functions
 BDDs can grow exponentially with number of inputs
 Depends on variable ordering
74
 Features:
 No vectors or testbench required
 Capacity to handle large design
 Eliminates gate-level simulation
 Reduce time-to-market
75
 Equivalence Checkers were used in:
 RTL-to-RTL
 RTL-to-Netlist
 Netlist-Netlist: some optimizations in Netlist
like:
 CTS-inserted netlist
 Scan-chain-inserted netlist
 Post-layout netlist
 …….
76
 Two circuits are functionally equivalent
if they exhibit the same behavior
 Combinational Circuits
CL
 For all possible input values
Pi Po
 Sequential Circuits
CL
 For all possible input
Ps Ns
sequences R
77
Combinational
 Functional Approach
 Transform output functions into BDD
 2 circuits are equivalent if their BDDs are id
entical
 Structural Approach
 Identify structurally similar internal points
 Prove internal points (cut-points) equivalen
t
78
Functional Equivalence
 BDDs of output functions must be identi
cal (using the same variable ordering) f
or functional equivalence
 If BDDs are too large
 Cannot construct BDD, memory problem
 Use partitioned BDD method
 Decompose circuit into smaller pieces
 Represent each piece as a BDD
 Check equivalence of internal points
79
Functional Decomposition
 Decompose each function into
functional blocks F G
 Represent each block as a BDD
 Define cut-points (z) f2 g2
 Verify equivalence of blocks at z z
cut-points starting at primary f1 g1
inputs
x y x y
80
Cut-Points Resolution
 All pairs of cut-points are equivalent 
FG
 If intermediate functions f2, g2 are not
equivalent, functions F and G may still
be equivalent (FALSE NEGATIVE)
 How to check False Negative?
 XOR (F, G)
 BDD for F  G
81
Structural Equivalence
 Given 2 circuits, each with its own struc
ture
 Identify “similar” internal points, cut sets
 Exploit internal equivalences
 False negative problem may arise
 F  G, but differ structurally
 Verification algorithm declares F, G differ’nt
 Implication Techniques
 Learning Techniques
82
Sequential
 Represent each sequential circuit as an
FSM
 Verify if two FSMs are equivalent
 Approaches:
 Reduction to combinational circuit
 Isomorphism of state graphs
 Symbolic FSM traversal of product machine
83
Formal Verification Tools
 Model Checkers
 Equivalence Checkers
 Academic Research Tools
 Commercial Verification Tools
 Formal Tools
 Semi-Formal Tools
84
Academic Tools
Tools Institutes
SMV CMU
MOCHA, VIS, HyTech UC Berkeley
STeP Stanford
SGM CCU & Sinica
RED Academia Sinica
UPPAAL Uppsala & Aalborg Univs
KRONOS Verimag
85
Commercial Tools
Tools Companies
Formal Check Cadence
Formal Model Checker Avant!
Formality Synopsys
Formal Pro Mentor Graphics
Black Tie, Conformal LEC Verplex Systems
86
Example:
Formal Verification of SoC
 Industrial Embedded SoC Product
 Korea Samsung Electronics S3C2400X
 ARM920T processor
 16 function modules (IPs)
 Reused IPs: UART, I2S, …
 Newly Designed IPs: bus controllers, DMA,...
 Newly Bought IPs: USB host controller
87
S3C2400X SoC
88
Formal Verification
Methodology for SoC
89
Model Checker
Cadence SMV (Symbolic Model Verifier)
 Many success stories!!!
 Supports SMVL and Verilog (with vl2smv)
 Problem size reduction:
 scalarset data type for symmetric reduction

 ordset data type for induction
 subclass structure for case-splitting
 layer structure for compositional assume-gu
arantee verification 90
Modeling Problems
 SMV supports only 1 implicit clock
 Issues in modeling in SMVL:
 Multiple clocks
 Gated clocks
 Unsynchronized clocks
 Synchronization logic
91
General Strategy for
Module Verification
1) Define what to verify for a module.
2) Construct the environment required
for verifying each property.
3) Transform each property to CTL.
4) Check coverage of CTL properties over
RTL code
92
Vacuous Property Checking
 A G ( p  A X (q) )
 If p does not occur, we cannot check A
X(q) at all.
 Model Checker says it is verified as true.
 We should check if p occurs at least onc
e, i.e., A G (~p) is false!
93
Fairness Constraint
 The correctness of a module depends
not only on environment, but also some
specific behavior of the environment
 This specific behavior is modeled as
fairness constraints (input restrictions)
 Also called assumptions in assume-
guarantee reasoning
94
Reduction of Address Bus and
Data Bus
 Traditional approach:
 Abstraction:
32-bit wide bus  1-bit or 2-bits wide
 Not used in SoC, because full data bus

and partial address bus are used to acc
ess CRs (configuration registers)
95
Reduction of Address Bus and
Data Bus
 Different approach:
 Divide verification task into 2 parts:
 CR accessing logic
 Normal operation logic
 2 different environments
 2 different property groups
96
Modules Verified
Modules CTL State Time
properties variables (min)
AHB arbiter 27, 38 90, 80 50
Bridge 61 50 5
DMA 67 100 440
USB (m 102+4+5 N/A 9h, 43h
w) 36+4+2 2h, 6h
Host (mr)
97
Discussions on Example
 Incremental design and verification
 Early stage of design: helps find real
design errors
 Later stage of design: helps find model
and property errors
 Design and verification time reduced
98
Conclusions
 Formal verification of SoC is definitely
required!
 But, it should be used in conjunction
with other verification techniques.
 Capacity of formal verification must be
enlarged for its wide-spread adoption
 Techniques required:
 Design abstraction
 Verification partitioning
99
Future Work
 Automatic abstraction & partitioning
 Assume-Guarantee Reasoning (AGR)
 Incorporation of assertion languages:
 Verplex’s OVL
Language
 Intel’s ForSpec Wars!!!
 etc.
 IP = Verilog + OVL + AGR
 Hierarchical verification of SoC based on
OVL + AGR 100

So CVerification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

So CVerification

Uploaded by

Copyright:

Available Formats

SoC Verification ( 晶片系統驗

Pao-Ann Hsiung ( 熊博安 )

Process Technology 0.25 um 0.18 um 0.15 um

Silicon Complexity 1 M Gates 2~5 M Gates 5~10 M Gates

Deep Sub-Micron (DSM) Technology 3

Design Gates / Hour

1990 1995 2000

Time-to-Market (TTM) Trends

SoC Verification v/s Design Gap

 Process antenna effects

 Phase shift mask

 Optical proximity correction

 Computation Tree Logic (CTL)

 a temporal logic formula f,

find a set of states that satisfy f .

 No green lights on both roads at the same

a1 < b1 < …< an < bn

a1 < …< an < b1<…< bn

 SAT, Boolean satisfiability anal

specification covers all properties the

complementary technique, in addition

 Uses BDDs, a canonical representation of logic

 Capacity to handle large design

 Eliminates gate-level simulation

 Supports SMVL and Verilog (with vl2smv)

 Problem size reduction:

 scalarset data type for symmetric reduction

 Not used in SoC, because full data bus

You might also like