Introduction

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
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
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.

Functional verification
◼ Simulation HDL Design
Directed tests Spec RTL
Constrained random tests
Testbench
◼ Formal methods Synthesis

Model checking RTL Gates
Equivalence checking
Equivalence Checking
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
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
Who does Verification?
◼ Designers may begin the process
◼ Verification engineers manage and complete the process
◼ Verification engineers may outnumber designers 2-1
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?
Functional Verification Approaches
Overview
◼ Function verification is primarily done via simulation

Black-Box Approach
White-Box Approach
Gray-Box Approach
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
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
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
Verification Flow
Goals
◼ Ensure conformance with specification

 But avoid false positives
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
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
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
Conclusion
◼ Verification is on critical path

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

Introduction

Uploaded by

Copyright:

Available Formats

You might also like

Introduction

Uploaded by

Document Information

Original Description:

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

Introduction

Uploaded by

Copyright:

Available Formats

VERIFICATION

ASIC Design Flow

◼ Verification is a process used to demonstrate the functional

◼ Also called logic verification or simulation.

Directed tests Spec RTL

Constrained random tests

◼ Formal methods Synthesis

◼ Two often confused

◼ Cost of bugs over time

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

◼ In design 60% - 80% time spent in verification

◼ Designers may begin the process

◼ Verification engineers manage and complete the process

◼ Verification engineers may outnumber designers 2-1

◼ How do you know when you are done?

◼ How do you know that your specification is complete?

◼ How do you verify the verifier?

◼ Function verification is primarily done via simulation

◼ The verifier has access to input, output and device function

Inputs Some piece of logic Outputs

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

◼ The verifier has access (and uses) a limited number of

◼ This is the reality for most verification

◼ Knowing the architecture of the DUT enables you to

◼ Ensure conformance with specification

◼ The verification engineer should not participate in the

◼ Designers may not think of all failing scenarios

◼ Verification engineer have a different perspective on the

◼ Verification engineers must understand the function, but

◼ Talk to the designer to understand the function of the

◼ Think of situations the designer neglected

◼ Focus on the corner case or exotic scenarios

◼ Focus on concurrent event

◼ Devise a potential bug

Verification Testbench RTL

◼ Verification is on critical path

You might also like