Developing Infrastructure for an Advanced
Application Specific Integrated Circuit (ASIC)
Verification Course
Meeta Yadav,
Ravi Jenkal,
Bob Oden,
Pete LaFauci,
Paul Franzon
Outline
Outline
• Overview & Intro
• Challenges
• Infrastructure Developed
• Material Covered
• Summary
Why do we need Functional Verification?
The
Theage
ageofofdigital
digital
convergence
convergence
• The cost of undetected problems
grow over time. There is little cost in
detecting a problem during
verification but the cost increases
substantially if the bug is detected
by the customer
Cost
• Designs are becoming more
complex, increased functionality
increases the number of transistors
and the possibility of error in the
design
Verification
Systems
Test
Time
Customer
3
Verification Trends
IC/ASIC Designs Requiring Re-Spins by Type of Flaw
Principal
PrincipalContributors
Contributors
• •Functional
Functionalbugs
bugs
• •Clocking
Clockingbugs
bugs
Logic/Functional
Clocking
Tuning Analog Circuit
Fast Path
Yield/Reliability
Delays/Glitches
Slow Path
Mixed-Signal Interface
Power Consumption
IR Drops
2002 Market Study
2004 Market Study
Firmware
Other
0%
20%
40%
60%
80%
100%
Percent of Designs Requiring Two or More Silicon Spins
Source: 2004/2002 IC/ASIC Functional Verification Study, Collett International Research
50% ASICS require more than one respin
4
Main Goal of Functional Verification
Functional Verification aims 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 tasks
implemented in the design
Minimal iterations in design flow
Customer
requirements
General
specification
and architecture
High level
chip design
HDL
implementation
at RTL level
Synthesis Æ
Place & Route Æ
Verification
Fixes to
HDL
Functional
verification
Fabricated Chip
5
Motivation Attack Representation
Contribution:
•
Industry
IndustryDemand
Demand
•
•
Research
ResearchDemand
Demand
70 % of design time is spent on
Verification
There is a need for well qualified
verification engineers with skills to verify
complex ASICs
Give students an understanding of
challenges associated with verifying
complex designs and motivation to
investigate new research ideas
• Synthesizable verification
• coverage convergence based
verification
• low power verification
6
Skills to LearnAttack Representation
Contribution:
Verification
VerificationMethodologies
Methodologies
Testbench
TestbenchEnvironment
Environment
Interfaces
Interfaces
Stimulus
Stimulus
Assertions
Assertions
Functional
FunctionalCoverage
Coverage
7
Curriculum Attack Representation
Contribution:
Tools
Toolsand
andLanguage
Language
Skills
Skills
• Hardware Verification Language (HVL):
SystemVerilog
• Test environments : Layers
TestÆ ScenarioÆ FunctionalÆ Command Æsignal
• Verification Platform: Mentor Graphics
Questa
• Connecting Testbench and DUT: Interfaces
• Stimulus creation: Directed & Constrained Random
• Smart Constraints: Randomization and its control
• Analyzing testbench effectiveness: Coverage Analysis
• Object-oriented coding for modularity and re-use
8
Curriculum Attack Representation
Contribution:
Advanced
AdvancedConstructs
Constructs
•Assertion based verification:
•Threads and Inter-process communication: testing concurrency
•Analyzing corner cases and creating directed test cases
•Enforcing effective documentation practices: Test-plan creation
9
Laboratory Exercise
Contribution:
Attack Representation
DLX
DLXALU
ALUas
asexample
example
Lab1
Basic Testbench (No Layers and No OOP) + Interface + Questa Tutorial:
Lab2
OOP Introduction: Packetized Stimulus Creation
Lab3
Fully Object Oriented Send Side (Generator, Base Scoreboard and Driver)
Lab4
Fully Object Oriented Receive Side (Receiver, Checker, full Scoreboard)
Lab5
Coverage Coding and Analysis on Questa using UCDB
Lab6
Assertion based verification
10
Laboratory Exercise
Contribution:
Attack Representation
Lab1
Basic Testbench (No Layers and No OOP) + Interface + Questa Tutorial:
Lab2
OOP Introduction: Packetized Stimulus Creation
Lab3
Fully Object Oriented Send Side (Generator, Base Scoreboard and Driver)
Lab4
Fully Object Oriented Receive Side (Receiver, Checker, full Scoreboard)
Lab5
Coverage Coding and Analysis on Questa using UCDB
Lab6
Assertion based verification
• Strive for incremental delivery of
laboratory exercises
• In sync with classroom instruction
& topics
• Foundation for project completion
11
Project Exercises
Contribution:
Attack Representation
Verification
Verificationofofan
anLC3
LC3
Microcontroller
Microcontroller
Bug
Fix ID
170654
‹ Created a pipelined version of the
LC3 Microcontroller
‹ Bugs were introduced in the design
Bug Found
‹ Students had to develop a verification
environment around the DUT
‹ Students had to generate constrained
random and directed tests to detect bugs
Correctness Check
Check
Correctness
LC3
LC3
Microcontroller
Microcontroller
DUT
DUT
Response
Response
Capture
Capture
Golden
Golden Model
Model
Stimulus
Stimulus
Application
Application
‹ A bug fix id was provided to the
students that allowed them to bypass the
bug
Progress
Progress Check
Check and
and Control
Control of
of
Verification
Verification Process
Process
Stimulus Generation
Generation
Stimulus
‹ Students were required to correctly
analyze the bug
Bug
Analysis:
rejection /
confirmation
12
Projects
Contribution:
Attack Representation
Buggy RTL
`ifdef BUGIDXXX
2'd3: begin
DMem_addr <= 16’hxxxx;
DMem_din <= 16’hxxx; end
`else
2'd3: begin
DMem_addr <= 16’hzzzz;
end
`endif
a) Inputs to recreate behavior:
First initialize all registers
to 0 and then Memory instructions
for load
b) Block with error: MemoryAccess
c) Expected Behavior:
if (mem_state == 3){
DMem_addr = 16'hzzzz
DMem_din = 16'hzzzz }
d) Observed behavior:
if (mem_state == 3){
DMem_addr = Previous value
DMem_din = 16'hxxxx }
e) Summary:DMem_addr,
DMem_din and DMem_rd not set to
'z' for mem_state 3
Student reports
Fix ID header file
`define BUGIDXXX
`define BUGIDYYY
Instructor coverage
Student coverage
13
Project Exercise
1 Representation
Contribution:
Attack
Simplified
SimplifiedLC3
LC3Microcontroller
Microcontrollerwith
withonly
onlyALU
ALUinstructions
instructions
‹Simple Layered testbench as shown in Lab 2/3.
‹Report Bugs with full reports and need for re-generatability
Complex
ComplexLC3
LC3microcontroller
microcontrollerwith
withfull
fullISA
ISAleading
leadingtotovariable
variable
timing,
timing,stalling,
stalling,multiple
multiplesystem
systemstates
states
‹Full Object Oriented and layered testbench Lab4
‹Constrained random test creation enforced
‹Golden Model based approach for testing
‹Design Bugs with full reports and need for re-generatability
14
Project Exercise
2 Representation
Contribution:
Attack
LC3
LC3Microcontroller
Microcontroller
‹Creation of coverage constructs for LC3 microcontroller
‹Analysis of completeness and achieving full coverage for LC3
Complex
ComplexLC3
LC3microcontroller
microcontrollerwith
withon
onchip
chipcache
cache
‹Testplan creation
‹Coverage Constructs for LC3 + Cache (merged UCDB)
‹Fully object oriented layered testbench
‹Design Bugs with full reports and 100 % coverage
‹Tested against our own testing wrapper for coverage completion
15
Class Response
Contribution:
Attack Representation
80
72
Percentage of Students
70
52
60
50
40
30
20
10
0
Are you interested in
pursuing research in the Do you currently have or
field of hardware
plan to have a career in
verification?
verification?
Feedback Fall 2007 - 64 students in total.
• 52% students are interested in ASIC Verification research
• 72% students are interested in pursuing a career in the field of
verification.
16
Summary
• Functional Verification Continues to Grow!
• Requirements, Managing Complexity, Tool Capabilities
• Incremental, Project-Based Course Structure
• Well-Defined Architecture and Specifications
• Include Completion Metrics in Labs
• Happy Students: Survey results + growth in 2008 registration
Thank You