VERIFICATION

ASIC Design Flow

Overview

Lecturer: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 5
 Hardware Verification
Functional verification
◼ Simulation HDL Design

Directed tests Spec RTL

Constrained random tests

Testbench

◼ Formal methods Synthesis

Model checking RTL Gates
Equivalence checking

Equivalence Checking

Lecturer: [email protected] 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
Net list Silicon

Verification Test
Lecturer: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 10
 Functional Verification Approaches
Overview

◼ Function verification is primarily done via simulation

Black-Box Approach
White-Box Approach
Gray-Box Approach

Lecturer: [email protected] 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 Outputs

design written in
VHDL

Lecturer: [email protected] 12
 Functional Verification Approaches
white-Box

◼ The verifier has access (and uses) internal signals during

verification
◼ This is common during block-level verification
wb_clear_val

ex_old_new_val
Input vector

Output vector
dc_stall
xreset

wb_clear_val
0
id_old_new_val 0
1 1

0 ex_instr_val
id_instr_val true_instr_val
(for EX)
ex_stall

Lecturer: [email protected] 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: [email protected] 14
 Verification Flow
Goals

◼ Ensure conformance with specification

 But avoid false positives

Lecturer: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 18
 Verification Flow
High level flow

Verification Testbench RTL

ASIC Spec
Plan development Handoff

Identify
Create Coverage
approach
enviroment Goals satisfied

Level of
Create
Verification Stop
Test cases

Level of
abstraction Run and
Debug tests
Strategy for
correctness

Lecturer: [email protected] 19
 Conclusion

◼ Verification is on critical path

◼ Want to minimize verification time
Using new tools
methodologies

Lecturer: [email protected] 20