VERIFICATION
ASIC Design Flow
Overview
Lecturer: hungpt@uit.edu.vn
2
ASIC Design Flow
Descriptions
◼ Specification:
Goals and constraints of the design
Functionality (what will chip do)
Performance like speed and power
Technology constraints like size and space
Fabrication technology and design techniques
◼ RTL:
This is called Logic Design, it is implemented using logic
representation
◼ Finite state machines
◼ Combinational logic
◼ Sequential login
Lecturer: hungpt@uit.edu.vn
3
ASIC Design Flow
Descriptions
RTL is expressed usually in Verilog or VHDL
◼ Gate Level Netlist
This step is called Logic/RTL synthesis. This is done by
Synthesis Tools
◼ Design Compiler (Synopsys)
◼ RTL Compiler (Cadence)
A synthesis tool takes an RTL and a standard cell library as
input and produces a gate-level netlist as output
Lecturer: hungpt@uit.edu.vn
4
Hardware Verification
What is verification?
◼ Verification is a process used to demonstrate the functional
correctness of a design. It is the act of ensuring that the logic
design conforms to the specifications.
Transformation
Verification
◼ Also called logic verification or simulation.
Lecturer: hungpt@uit.edu.vn
5
Hardware Verification
Functional verification
◼ Simulation
HDL Design
Directed tests
Constrained random tests
Spec
RTL
Testbench
◼ Formal methods
Model checking
Equivalence checking
Synthesis
Gates
RTL
Equivalence Checking
Lecturer: hungpt@uit.edu.vn
6
Hardware Verification
Verification VS. Test
◼ Two often confused
◼ Purpose of test is to verify that the design was
manufactured properly
◼ Verification is to ensure that the design meets the
functionality intent
HW Design
Fabrication
Specification
Silicon
Net list
Verification
Lecturer: hungpt@uit.edu.vn
Test
7
Hardware Verification
Why do Verification?
◼ Cost of bugs over time
Bugs found at the block level have little cost
Bugs found at the system level may effect the time-to-market
Bugs found after fabrication require an expensive re-spin
Bugs found by customers can cost hundreds of millions and
worst of all – Reputation
◼ In design 60% - 80% time spent in verification
Lecturer: hungpt@uit.edu.vn
8
Hardware Verification
Who does Verification?
◼ Designers may begin the process
◼ Verification engineers manage and complete the process
◼ Verification engineers may outnumber designers 2-1
Lecturer: hungpt@uit.edu.vn
9
Hardware Verification
Why is Verification hard?
◼ How do you know when you are done?
◼ How do you know that your specification is complete?
◼ How do you verify the verifier?
Lecturer: hungpt@uit.edu.vn
10
Functional Verification Approaches
Overview
◼ Function verification is primarily done via simulation
Black-Box Approach
White-Box Approach
Gray-Box Approach
Lecturer: hungpt@uit.edu.vn
11
Functional Verification Approaches
Black-Box
◼ The verifier has access to input, output and device function
◼ Given a set of inputs the verifier checks for correct outputs
◼ To fully verify a black-box you must show that function is correct
for all combinations of inputs
◼ Full verification via black-box testing is impractical for any real
design
Inputs
Some piece of logic
design written in
VHDL
Lecturer: hungpt@uit.edu.vn
Outputs
12
Functional Verification Approaches
white-Box
◼ The verifier has access (and uses) internal signals during
verification
◼ This is common during block-level verification
dc_stall
xreset
wb_clear_val
0
id_old_new_val
id_instr_val
0
1
1
0
ex_instr_val
true_instr_val
(for EX)
ex_stall
Lecturer: hungpt@uit.edu.vn
Output vector
Input vector
wb_clear_val
ex_old_new_val
13
Functional Verification Approaches
Gray-Box
◼ The verifier has access (and uses) a limited number of
internal signals during verification
◼ This is the reality for most verification
◼ Knowing the architecture of the DUT enables you to
write better test
Lecturer: hungpt@uit.edu.vn
14
Verification Flow
Goals
◼ Ensure conformance with specification
 But avoid false positives
Lecturer: hungpt@uit.edu.vn
15
Verification Flow
Key
◼ The verification engineer should not participate in the
logic design of the DUT
◼ Designers may not think of all failing scenarios
◼ Verification engineer have a different perspective on the
design
◼ Verification engineers must understand the function, but
not the implementation
Lecturer: hungpt@uit.edu.vn
16
Verification Flow
Do
◼ Talk to the designer to understand the function of the
design
◼ Think of situations the designer neglected
◼ Focus on the corner case or exotic scenarios
◼ Focus on concurrent event
◼ Think about the all the pieces of the design you need to
verify
Lecturer: hungpt@uit.edu.vn
17
Verification Flow
A typical flow
◼ Devise a potential bug
◼ Write a test-case to expose the bug
◼ Run the simulator with the test-case
◼ Check the simulation result
◼ If the test has uncovered a bug
Verify the bug
Work with designer to fix the bug
Lecturer: hungpt@uit.edu.vn
18
Verification Flow
High level flow
ASIC Spec
Verification
Plan
Identify
approach
Level of
Verification
Level of
abstraction
Testbench
development
Create
enviroment
Create
Test cases
RTL
Handoff
Coverage
Goals satisfied
Stop
Run and
Debug tests
Strategy for
correctness
Lecturer: hungpt@uit.edu.vn
19
Conclusion
◼ Verification is on critical path
◼ Want to minimize verification time
Using new tools
methodologies
Lecturer: hungpt@uit.edu.vn
20