ENCS5337: Chip Design Verification

Spring 2023/2024

Introduction and Motivation

Dr. Ayman Hroub

Many thanks to Dr. Kerstin Eder for most of the slides
 The IC Design Process
Architectural
Specification Gate-Level Design
Model Library
Behavioral synthesis
Concept
Model

Micro RTL
Architectural Model Transistor- Mask
Design custom Level Layout Data
design Model

Functional Verification Equivalence Analysis of

Checking Timing/Power
Performance Verification

Functional verification aims to demonstrate

that the functional intent of a design is
preserved in its implementation.
2
 What is Design Verification?

“Design Verification is the process used to

gain confidence in the correctness of a
design w.r.t. the requirements and
specification.”

 Confirms that a system has a given input /

output behaviour, sometimes called the
transfer function of a system.

3
 Why is Verification important?
 Verification is the single biggest lever to
effect the triple constraints:
– Quality
 A high quality track record preserves revenue and reputation.
 Ideally a team can establish a “right-first-time” track record.
– Cost
 Fewer revs through the development/fabrication process
means lower costs.
 Respinning a chip costs hundreds of thousands of £/$/€
+ the associated lost opportunity costs.
– Timing/Schedule
 Fewer revs through the development/fabrication process
means faster time-to-market.
 Respinning a chip costs 6-8 weeks at least
+ the associated “lost opportunity” costs.

4
All about Bugs
Types of bugs
How are bugs introduced?
How can bugs be found?
Why do Designs have Bugs?

6
Why do Designs have Bugs?
Problem Solution

Develop a
computational
Manufacture
solution
the HW

Design the
HW

7
 Why do Designs have Bugs?
Problem Solution

Develop a
Ambigious specification
computational
Manufacture
solution
the HW

Design the
HW

8
 Why do Designs have Bugs?
Problem Solution

Develop a
The
Ambigious specification
computational
solution human Manufacture
the HW

dimension
Design the
HW

9
 Loss of
Cost of Bugs over Time Reputation
Lost
Number of
opportunity Cost of
bugs found Mask
cost bugs
costs
Huge
Late to costs are
market associated
cost Debug
with
Bug found cost
finding a
Bug found on system
at chip level test floor bug in your
customer’s Recall
Bug found has requires
moderate respin of environ- cost
early has
little cost. cost. the chip. ment.
Time
Initial Design Chip System Customer

The longer a bug goes undetected,

the more expensive it is!
Remember the Intel Pentium FDIV bug!
http://en.wikipedia.org/wiki/Pentium_FDIV_bug
10
 Increasing Design Complexity vs tight TTM Constraints
ITRS Edition 2009, Design Chapter (http://www.itrs.net/ and http://www.itrs2.net/)
– Hardware and Software Design Gaps versus Time

Getting it right (first time) is more and more difficult:

– rapidly increasing design complexity
– tight “time-to-market” constraints
11
Increasing Design Complexity
5-10K Lines 250-500K
of Control Lines of F/W
50-100K
Code Lines of
Protocol F/W
Video
TV
Display mC
MPEG Decode
Processing
Core Over 2M Lines
>100K Lines of Application
of Appl S/W S/W

20-50K Lines 250-300K

of Protocol Lines of DSP
F/W F/W

Wireless OFDM
xDSL
Modem
Baseband Signal Processor
5-10K Up to 2M
Lines of
Processor Lines of
Microcode Network S/W

Multiple Power Domains, Security, Virtualisation

Nearly five million lines of code to enable Media gateway
12
Increasing Verification Productivity
Need to minimise verification time e.g. by using:
 Parallelism: Add more resources
 Abstraction:
– Higher level of abstraction (i.e. C vs Assembly)
– This often means a reduction of control!
 Automation:
– Tools to automate standard processes
– Requires standard processes/methodology.
– Usually a variety of functions, interfaces, protocols, and
transformations must be verified.
– Not all (verification) processes can be automated.
Productivity improvements drive early problem
discovery!

13
 Increasing Verification Productivity
Productivity improvements drive
early problem discovery
Total
Number
of Bugs
found
Test

Verification

Time

14
Verification in the IC
Design Process
 Recall: The IC Design Process
Architectural
Specification Gate-Level Design
Model Library
Behavioral synthesis
Concept
Model

Micro RTL
Architectural Model Transistor- Mask
Design custom Level Layout Data
design Model

Functional Verification Equivalence Analysis of

Checking Timing/Power
Performance Verification

Functional verification aims to demonstrate

that the functional intent of a design is
preserved in its implementation.
16
 Chip Design Process
General
Customer
Specification and
Requirements
Architecture

High Level High Level

Chip Design Verification

HDL Implementation
Functional
(Logic Design) Fixes To HDL Verification
at RTL Level
Physical Circuit
Design via Synthesis
Or Custom Layout

Fabricated
Chip

17
Role of Verification in IC Design
IC design process is complex:
 Engineers need to balance conflict of interest:
– Tight time-to-market constraints vs. increasing design complexity
 Aim: “Right-first-time” design, “correct-by-construction”
 More and more time-consuming to obtain acceptable
level of confidence in correctness of design!
 design time << verification time
– Remember: Verification does not create value!
 But it preserves revenue and reputation!
– Up to 70% of design effort can go into verification.
– 80% of all written code is often in the verification environment.
– Properly staffed design teams have dedicated verification
engineers.
– In some cases verification engineers outnumber designers 2:1.

18
 Chip Design Process
General
Customer
Specification and
Requirements
= Architecture

High Level High Level

Chip Design
=
Verification

=
HDL Implementation
Functional
(Logic Design) Fixes To HDL Verification
at RTL Level
Physical Circuit
Design via Synthesis
Or Custom Layout =
Fabricated
Chip

19
 What are you
going to verify?
 How do Designers know whether
a circuit is correct?

Concept

VERIFY: What you specified is what you envisioned

Specification
VERIFY: What you designed is what you specified

HDL Design (RTL)

VERIFY: What you taped out is what the RTL describes

Tape-out
TEST: What was manufactured is what you taped out

Silicon

There is skill, science and methodology behind verification.

21
 Reconvergence Models [Bergeron]

Conceptual representation of the verification process

 Most important question:
What are you verifying?

Transformation

Verification

 Purpose of verification is to ensure that the result of

some transformation is as intended or as expected.

22
 Verification vs. Test
 Often confused in the context of HW design!
– Purpose of test is to show design was manufactured properly.
– Verification is done to ensure that design meets its functional
intent prior to manufacture!

HW Design Fabrication
Specification Silicon
Chip
Verification Test
Netlist

23
 Formal: Equivalence Checking
Compares two models to check for equivalence.
 Proves mathematically that both are logically equivalent.
– Commonly used on lower levels of design process.
 Example: RTL to Gates (Post Synthesis)

Synthesis

RTL Gates

Equivalence Check

24
 Equivalence Checking

F
Inputs Outputs
xor

 Conceptually, we are asking the question:

“Is there an input vector such that
the output of the XOR gate can be “1”?
25
 Cost of Verification
Necessary Evil
 Always takes too long and costs too much.
 As number of bugs found decreases, cost and time of
finding remaining ones increases.
So when is verification done? (Will investigate this later!)
– Remember: Verification does not generate revenue!

Yet indispensable
 To create revenue, design must be functionally correct
and provide benefits to customer.
 Proper functional verification demonstrates
trustworthiness of the design.
 Right-first-time designs demonstrate professionalism
and ”increase” reputation of design team.

26
Verification is similar to statistical hypothesis testing
Hypothesis ”under test” is: The design is functionally correct.

Good Design Bad Design

(no bugs in design) (buggy design)

Bugs found

No Bugs found

27
Verification is similar to statistical hypothesis testing
Hypothesis ”under test” is: The design is functionally correct.

Good Design Bad Design

(no bugs in design) (buggy design)

Type I:
Bugs found
False Positive

No Bugs found

Type I mistakes (“convicting the innocent”, a “false alarm”):

- Easy to identify - found error where none exists.

28
Verification is similar to statistical hypothesis testing
Hypothesis ”under test” is: The design is functionally correct.

Good Design Bad Design

(no bugs in design) (buggy design)

Type I:
Bugs found
False Positive

Type II:
No Bugs found
False Negative

Type I mistakes (“convicting the innocent”, a “false alarm”):

- Easy to identify - found error where none exists.
Type II mistakes (“letting the criminal walk free”, a “miss”):
- Most serious - verification failed to identify an error!
- Can result in a bad design being shipped unknowingly!

29
 Summary
 What is Design Verification?
– Why do we care?
– Verification vs validation
 Bugs
– Sources of bugs
– Cost of bugs
– Importance of Design Verification
 Impact of increasing design complexity
– Shrinking time to market windows
– Increasing Productivity
 The chip design process
– Where does Verification “fit”?
 Reconvergence Models
– Help us identify what is being verified

30