lec2 introduction
TRANSCRIPT
-
7/25/2019 Lec2 Introduction
1/28
2011, Meeta Yadav 1
ASIC VerificationIntroduction to Verification
Fall 2011
Meeta Yadav
-
7/25/2019 Lec2 Introduction
2/28
2011, Meeta Yadav 2
Why do we need Functional Verification?
Designs are becoming more complex
Increased functionality increasesthe number of transistors and the
possibility of error in the design
The cost of undetected problems grow
over time
There is little cost in detecting aproblem during device verification
but the cost increases substantially
if the bug is detected by the
customerVerification Systems
Test
Customer
Time
C
ost
Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier
The age of digital
convergence
-
7/25/2019 Lec2 Introduction
3/28
2011, Meeta Yadav 3
Which is more complex?
Saturn V moon rocket 45 nm ASIC
300,000 parts in 70,000assemblies
1 Billion transistors with ~10 BillionSub-compoments
-
7/25/2019 Lec2 Introduction
4/28
2011, Meeta Yadav 4
Design Failures: Example
Pentium floating point bug* (1994) Chip generated inaccurate computations to certain floating point
calculations
x= 4195835, y= 3145727, and z=x- (x/y)*y
gave the answer as 256 instead of 0
Error occurred due to omission of entries and was hard to detect sinceonly 1 in 9 billion calculations were affected
Explosion of Ariane 5** rocket (1996)
Unmanned Ariane 5 rocket of the European Space Agency exploded 40
seconds after lift-off (Cost $7 billion + $500 million)
Error in conversion of 64 bit horizontal velocity number to a 16 bit signed
integer
* http://www.maa.org/mathland/mathland_5_12.html
** http://www.cnn.com/WORLD/9606/04/rocket.explode/
-
7/25/2019 Lec2 Introduction
5/28
2011, Meeta Yadav 55
IC/ASIC Designs Requiring Re-Spins by Type of Flaw
0% 20% 40% 60% 80% 100%
OtherFirmware
IR Drops
Power Consumption
Mixed-Signal Interface
Slow Path
Delays/Glitches
Yield/Reliability
Fast Path
Tuning Analog Circuit
Clocking
Logic/Functional
Percent of Designs Requiring Two or More Silicon Spins
2002 Market Study
2004 Market Study
Principle contributors:
- Functional bugs
- Clocking related bugs
[Collet 2005]
Verification Trends
50% of ASICS require more than one respin
-
7/25/2019 Lec2 Introduction
6/28
2011, Meeta Yadav 66
The Verification Challenge
Two major verification challenges are:
The challenge of state space explosion
Formal Verification
The challenge of detecting incorrect behavior Functional Verification
Constrained Random Tests
Coverage
Assertions
There are more theoretical
states in todays design than
there are atoms in the
universe!!!
-
7/25/2019 Lec2 Introduction
7/282011, Meeta Yadav 7
Design
Gap
Verification
Gap
Ability to Verify (Directed)
Ability to Design
Ability to Fabricate
DesignSizeinMillionsofGates
7
* Based on data from the Collett International 2004 FV Survey
The Design & Verification Gap Many companies still using 1990s techniques
Traditional verification techniques cant keep up with todays designs
The Verification challenge
-
7/25/2019 Lec2 Introduction
8/282011, Meeta Yadav 8
Traffic Controller
Design description
Light should stay green for1 minute in each direction
when the intersection is
busy
Main StreetElmStreet
-
7/25/2019 Lec2 Introduction
9/282011, Meeta Yadav 9
Traffic Controller
Wait 60
seconds
Main St. traffic?
Elm St. traffic?
Elm St.
turns green
Main St.
turns green
yes
yes
no
no
Algorithm for a Traffic Controller by Eagelton Signal Controllers
And Parking Engineering Solutions (ESCAPES)
Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier
Algorithm Implemented
Is there a problemwith the design?
-
7/25/2019 Lec2 Introduction
10/282011, Meeta Yadav 10
Functional Verification
Customer
requirements
General
specification
and architecture
High level
chip design
HDL
implementation
at RTL level
Functional
verification
Physical circuit
design via
synthesisFabricated Chip
Fixes to
HDL
Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier
Goals of Functional verification are to
ensure The design accurately performs the tasks
intended by the overall system architecture
To detect a missing feature
To detect a missing corner condition
There are no bugs in the tasksimplemented in the design
Functional Verification testbenches
should be built from the general
specifications and architecture
-
7/25/2019 Lec2 Introduction
11/282011, Meeta Yadav 11
Functional Verification
Source: Will, Goss, Roesner:
Comprehensive Functional
Verification: Elsevier
Customer
requirements
General
specification
and architecture
High levelchip design
HDL
implementation
at RTL level
Functional
verification
Physical circuit
design via
synthesisFabricated Chip
Fixes to
HDL
Timing Analysis
System Testing
Manufacturing
Customer
A well-verified chip reduces cost byavoiding:
Re-fabrication
Re-calls
Design Process
-
7/25/2019 Lec2 Introduction
12/282011, Meeta Yadav 1212
Cost of Bugs
Verification Systems
Test
Customer
Time
Cost
Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier
The cost of undetected problems grow over time
-
7/25/2019 Lec2 Introduction
13/282011, Meeta Yadav 1313
Verification Productivity
Time
Num
bero
fBugs
Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier
Verification productivity reduces cost and schedule
Verification Systems Test
Productivity improvements
drive early problem discovery
-
7/25/2019 Lec2 Introduction
14/282011, Meeta Yadav 14
Overall Testbench Functionality
Generate stimulus
Apply stimulus to the Design Under Test (DUT)
Capture the response
Check for correctness
Measure the progress against the overall verification goals
Design
Under
TestStimulus
Application
StimulusGene
ration
Response
Capture
CorrectnessC
heck
Golden Model
Progress Check and Control of
Verification Process
-
7/25/2019 Lec2 Introduction
15/282011, Meeta Yadav 15
Directed Testing Approach
Directed Test Progress
Writing stimulus vectors to exercise various individual features of the design
Is a time and resource consuming exercise
Good for small test space with limited variations
100%
Time
Coverage
Directed
Test
Time and resource consuming
Directed Test Progress
-
7/25/2019 Lec2 Introduction
16/282011, Meeta Yadav 16
Directed Testing Approach
Directed Testing Coverage Individual test cases cover individual features in the design space
Over time the entire design space can be covered
Increase in the complexity of the design causes an increase in the time to
cover the entire design space
Directed Test Coverage
Covered
Features
Bug
UncoveredFeatures
-
7/25/2019 Lec2 Introduction
17/282011, Meeta Yadav 17
Randomization
Why Randomize? Create VALID corner states : system states of maximum device
discomfort
What do you randomize?
Device Configuration: Move device to states of least probability
Input data
Error handling:
Exception handling by protocols (bus protocols, handshaking, memory
interface)
Recovery from errors in system states Relative timing between blocks
Blocks operating at different rates
-
7/25/2019 Lec2 Introduction
18/282011, Meeta Yadav 18
Stimulus: Constrained Random Testing
Constrained Random Test Progress Constrain stimulus to VALID limits and allow tool to generate values at random within limits
Random stimulus is required to exercise a complex design
Useful in finding unanticipated bugs
Achieves coverage faster
Constrained Random Test Progress
100%
Time
Coverage Random
Test
Directed
Test
More time to writeConstrained random tests
Less time to achieve
100% coverage
-
7/25/2019 Lec2 Introduction
19/282011, Meeta Yadav 19
Stimulus: Constrained Random Testing
Constrained Random Test Coverage Random tests cover wider design space than directed tests
Tests may overlap
Directed tests are still needed to test uncovered features
Constrained-Random Test Coverage
Directed
testcase
Test Overlap
? ?
?
New Area
-
7/25/2019 Lec2 Introduction
20/28
2011, Meeta Yadav 20
Coverage Convergence
Add
constraints
Many runs
different seeds
Identify
holes
Functional
Coverage
Constrained Random
Tests
Minimal Code
Modifications
Directed
Tests
How do we achieve coverage convergence?
Start with a fully randomizable testbench Run many randomized simulations
Analyze cumulative coverage and coverage holes
Then with minimal code changes
Add constrained stimulus to fill coverage holes
Finally:
Make few directed tests to hit the remaining holes
-
7/25/2019 Lec2 Introduction
21/28
2011, Meeta Yadav 21
Coverage Feedback
For a large verification space consider coverage feedback
Time (Code Writing and output
checking)
Coverage(%o
fposs
iblebugs
checked)
Latency for coding
constrained random tests
Constrained Random without
Coverage Feedback
Constrained Random with
Coverage Feedback
Directed tests
-
7/25/2019 Lec2 Introduction
22/28
2011, Meeta Yadav 22
SystemVerilog Assertions in Verification Strategy
Assertions:
1. Captures Designer Intent
2. Allows protocols to be defined and verified
3. Reduces time to market
4. Greatly simplifies the verification of reusable IP
5. Facilitates functional coverage metrics
-
7/25/2019 Lec2 Introduction
23/28
2011, Meeta Yadav 23
SystemVerilog Assertions in Verification Strategy
Time
Time to Market
Upfront Cost
Bugs
Block Design System Integration
Ship
Ship much later with margin of errorShip much
earlier with less
risk and cost
Assertions reduce time to market
-
7/25/2019 Lec2 Introduction
24/28
2011, Meeta Yadav 24
Writing an Effective Testbench
Testbench: Emulates the environment of the DUT
Features of an effective testbench
Re-usable and easy to modify for different DUTs
Object-oriented!! Layered: Orthogonalize concerns
Transactors (encapsulation of protocol) and Interfaces!!!!!
Catches bugs or achieves coverage quickly
Randomizable!!
-
7/25/2019 Lec2 Introduction
25/28
2011, Meeta Yadav 25
Benefits of testbench environment
Environment updating takes less time
Testbench is easy to constrain from the top level file
All Legal Device Configurations are tested
Regression can select different DUT configurations
Configuration object is randomized and constrained Enables reuse
-
7/25/2019 Lec2 Introduction
26/28
2011, Meeta Yadav 26
Levels of Verification
Memory
Access unit
Memory Bus Snoop
Unit
DMA Cache ALU FPU
ProcessorPeripheral Local
memory
Board
Bus
arbiter
Memory PCI
controller
South
bridge
Peripheral
Backplane Node
System
X Y
Designer
level
Unit
level
Chip
level
Board
level
System
level
Hierarchical Diagram of Multiple Node System
Figure Courtesy: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier
-
7/25/2019 Lec2 Introduction
27/28
2011, Meeta Yadav 27
Levels of Verification and Bugs Detected
Time
Bugs
Designer Unit Chip System
Lower levels of verification tend to uncover more bugs since they occur earlier
in the design cycle and because verification of each designer or unit level occurs in
parallel with the others. It is a good practice to wait until the bug rate begins to drop
in the low levels before moving to the next level
Figure Courtesy: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier
-
7/25/2019 Lec2 Introduction
28/28
Thank You