1
Marrying Formal Methods With Simulation-Based Verification –
Function Verification Research at UCSB
Tim Cheng & Li-C. WangUC-Santa Barbara
2
Outline
• Current Issues in Functional Verification• Functional Verification Research at UCSB
– Potential Solutions– Initial Experimental Results– Future Directions
• Conclusion
3
Formal Methods or Simulation?
• Full-chip functional verification will continue to rely heavily on vector simulation– deterministic and random testing– Can be improved, but never complete
• Applications of formal property checking will continue to be restricted to individual block/unit level– Mostly on “critical/sensitive” areas
• Increasing demand for tools to seamlessly integrate the two approaches (semi-formal approaches)
4
Areas Demanding Better Formal Methods
• Complex arithmetic circuits– Multipliers, Floating point (vector) units, DSP units, etc.– High performance custom designs– Applying traditional (BDD-based) formal methods remains
impractical
• Embedded memory systems– Performance is critical– Complex control – they are the focal points of information
exchange among blocks/units– Custom designed and sensitive to errors
5
Verification Research at UCSB
• Hybrid constraint-solving engines
• Inductive method for verification of arithmetic circuits
• Automatic property extraction from testbench
• Optimized verification tools for embedded memories
6
Motivation• Insufficient capacity and error coverage in
functional verificationModel checking
Automatic vector generation
Symbolic simulation
Manual test w/ coverage
Random and biasedrandom simulation
coverage
Scale (gates)10K 50K 300K 3M
!! We need a powerful constraint-solving engine !!!! We need a powerful constraint-solving engine !!
7
Hybrid Constraint-Solving Techniques
• Goals– Combining the structural, word-level ATPG and
modular arithmetic techniques for constraint solving
– Applying for model checking, functional vector generation and equivalence checking
8
Key Strategies
• Using higher-level information
• Applying different engines for the different sub-circuits
– Word-level ATPG/implications
– ATPG (control) & Arithmetic Solver (datapath)
– Search process guided by the Extended Finite State Machine (EFSM) model
– Advanced learning techniques
9
Overview - The Framework
environmentalsetup HDL codes initialization
sequence
ATPG
assertionsetup
RTL netlist
no solutionno
solutionokarithmeticsolver
okbacktrack
no
•Guided by EFSM model
10
Overview --- Circuit Modeling
Datapath
> 01
Controller
data in
data reg
control in
control reg
data out
data reg
control out
control reg
11
Datapath
> 01
Controller
01>
Datapath
> 01
Controller
01>
ATPG Justification
00
12
Arithmetic Constraint Solver
Datapath
>01>
Datapath
> 01
01>
0 1 1 0
01
13
Datapath
>>
Datapath
>>
0 1 1 0
- ++
+ -
-
Arithmetic Constraint Solver
• Arithmetic constraints– Linear: adders, subtractors, multipliers with one
constant input. (Major part of the arithmetic circuit)– Nonlinear: multipliers, shifters, …etc. (Difficult
to solve)
14
Overview - The Framework
environmentalsetup HDL codes initialization
sequence
ATPG
assertionsetup
RTL netlist
no solutionno
solutionokarithmeticsolver
okbacktrack
no
•Guided by EFSM model
15
Verification Research at UCSB
• Hybrid constraint-solving engines
• Inductive method for verification of arithmetic circuits
• Automatic property extraction from testbench
• Optimized verification tools for embedded memories
16
Inductive Verification - Basic Ideas• Apply inductive definition in n-steps:
– (an-1 an-2 .. a0) × (bn-1 bn-2 .. b0)= (an-1 an-2 .. a0) × (0 bn-2 .. b0) +
(an-1 an-2 .. a0) × (bn-1 0 .. 0) • Apply logic verification (EQ-checking) in each step.
– Take advantages of the similarities in the first two multiplication terms
– Apply heuristics to partition the circuit– “Reduced verification” by focusing on the perturbed adder.
• Provide a true gate-level verification framework– No additional internal signal or hierarchy information is
required
17
***A buffered cut is required to ensure consistency with the inductive definition
Fanout coneanalysis
Difference circuits
1st Cut
Buffered cut
Illustration
18
Why This Can Work Efficiently?• Multipliers are commonly implemented as
multi-operand addition/reduction trees• Each addition/reduction tree could be
identified by fanout cone information from the inputs– Each tree can then be verified as a reduced EQ-
checking problem on a simpler arithmetic property
– The original problem can be solved efficiently due to greater structural similarities
19
Initial Experimental Results – Memory usage
02468
101214161820
16 32 48 64 80 96 112 128
Mul t i pl i er s i ze ( bi t )
Memo
ry u
sage
(MB
)
addstepcsatreeclabooth*
***Verification of C6288 takes only 4.67sec and 0.94MB!
20
Next Steps
• Extend partition heuristics to handle designs using Wallace tree
• Generalize to other arithmetic circuits– Industrial floating point units (f = A*B+C)– Arithmetic vector units
• Integrate with existing EQ-checking tools to enable automatic verification of RTL data-path with architectural changes.
21
Verification Research at UCSB
• Hybrid constraint-solving engines
• Inductive method for verification of arithmetic circuits
• Automatic property extraction from testbench
• Optimized verification tools for embedded memories
22
Golden Model
• The testbench (IO behavior) can be treated as the golden model
• Tremendous effort has been spent in generating the testbench - utilize it as much as we can!!
DUTinputs outputsThis is our golden model
23
Simulation-Based Property Extraction
• Extraction ⇒ from inputs to a set of signals– Extract properties imposed by the cones of logic
• Observation ⇒ from signals to outputs– Determine if properties are necessary in order to
achieve the output behavior– Those properties can be thought as constraints
inputs outputs
properties Necessary?
24
Facilitate Formal Verification
• In practice, identifying “input constraints” and “internal properties” for formal verification are both time consuming
• The proposed method can provide a way to ease that process
inputs outputsproperties co
nstra
ints
Formal verification
25
Improve Functional Verification
• From testbench I, properties are extracted• The properties are then put it back as
the“assertion monitors” to watch testbench II• From “properties” to “assertions”
– Someone should be the gatekeeper• Users, or• Other verification tools (at block level)
DUVinputs outputs
Testbench I properties
AssertionmonitorsTestbench II
26
Issues• Where to extract?
– Around embedded arrays• Where industrial people often insert “assertion
monitors” to watch their testbench simulation– On interface among blocks– Adopt other more general analysis? Ex. EFSM
• How to extract?– What to extract? Spatial vs. Temporal– Require different techniques
• How to determine property observability at the testbench outputs?– ∆-calculus, fault simulation
• How to avoid false negative/positive?– User has to be the final gatekeeper
27
Initial Experiments• Only consider spatial property
– Temporal property extraction is under development
• Extract properties at the block boundary• Focus on 1-hot (mutually exclusive)
properties– 0-hot, zero 1-hot, hierarchical 1-hot, etc.
• Experiment on a small pipelined µ-processor
28
Current Status and Immediate Next Steps
• Current Status– Use testbench provided with the processor– Use maximal clique algorithm(s) with heuristics– We can extract all 1-hot properties in the design
• Immediate Next steps (this summer)– Extend to other more complex designs
• Include embedded memories• Use other processor designs (ARM 7)
– Identify and extract critical temporal properties– Determine property observability– Link to model checking tools
29
Verification Research at UCSB
• Hybrid constraint-solving engines
• Inductive method for verification of arithmetic circuits
• Automatic property extraction from testbench
• Optimized verification tools for embedded memories
30
Perspectives• Embedded memories are critical areas in a design
– Complex control to simultaneously serve multiple units– Custom design to improve performance– Sensitive to errors/defects and other issues (coupling,
delay, etc.)• Many verification techniques that look impractical
now for attacking general designs may be feasible for embedded memories– Because of structural regularity in memories– (Analogy: ) This happened before in BIST
• BIST became matured with application to memory• Now people are talking about logic BIST
31
Objectives – Do More!
• Enable symbolic simulation at memory system level– For both logic and functional verification
of memory systems• Enable symbolic simulation with timing
for memory block– For validation of electrical properties
32
Example – Symbolic Simulation
• Types of operation for an array block are limited– The size of the list should be manageable – The “domain” of all the 2-tuples are mutually exclusive– By dividing the space into “domains,” the “values” can be
represented and handled more efficiently
• Potentially, timing information can be processed independently with each domain– Reduce complexity from data dependency
Array[A]=D
Write N to BResults: list of 2-tuples(D, A<>B || write_en=0) and(N, A=B & write_en=1)
33
Current Status• Currently, we are doing two things:
– Developing the symbolic simulator– Developing the design examples (in verilog RTL)
to be tested• L1 instruction cache/Tag/MMU subsystem
• Immediate Next Steps (2nd half of the year)– Collect experimental results on the L1 subsystem
• Compare them to Voss– Incorporate timing into our simulator
• Test it for array blocks (individual cache, tag, etc.)
34
Summary and Discussion• Marrying formal methods with simulation-based
approaches– Hybrid constraint solving for vector generation/assertion
checking– Utilizing testbench information for automatic
property/constraint extraction• Inductive verification of arithmetic circuits
– Reduce complexity by induction– For both logic and functional verification
• Optimized verification tools for embedded memories– Customized methods based on memory regularity– Extend verification scope; improve efficiency