Ecological Niche or Survival Gear? Improving an FMCAD 2006

advertisement
Ecological Niche or Survival Gear?
Improving an
Industrial Simulation Methodology with Formal Methods
FMCAD 2006
Wolfgang Roesner
IBM Systems & Technology Group
Hardware Verification
Austin, TX. USA
wolfgang@us.ibm.com
July 13, 2016
1
(c) IBM Corporation
Overview
1. The Target : High-End Server Micros/Systems
2. The Gorilla
Scaling the Simulation-Based Methodology
3. Successes in the Application of (S)FV
4. New Design Challenges
5. Growing the Brain
Scaling the (S)FV - Methodology
July 13, 2016
2
(c) IBM Corporation
High-End Server: POWER5 Chip
Topology:
Two cores on chip, a 2-way SMP.
Core private L1s (64KB I, 32KB D)
Simultaneous Multi Threading SMT
Chip private 1.875 MB L2
L3 directories on chip.
L3 36 MB data off chip.
Technology:
130nm Copper & SOI
389 mm2 die size.
8 Layers of metal
276 million transistors on chip.
1.9 GHz clock.
> 1.5 M Lines of VHDL
Several 100s of people
July 13, 2016
Custom & Semi-Custom Design Style
High Frequency Constraints
3
(c) IBM Corporation
High-End Server: POWER5 Multi-Chip Module
95x95mm
Four POWER5 Chips
Four Cache Chips
4,491 signal I/Os
89 layers of metal
MCM builds 8 way SMP.
July 13, 2016
4
(c) IBM Corporation
High-End Server: POWER5 64-Way SMP System
Interconnection exploits enhanced distributed switch
All intra MCM POWER5-to-POWER5 connection run at processor speed
All other POWER5-to-POWER5 and POWER5-L3 connections run at half
processor speed and scale with processor frequency
July 13, 2016
5
(c) IBM Corporation
RTL Verification
RTL
(VHDL, Verilog)
Physical VLSI
Design Tools /
Custom Design
PSL et al.
Driver/Checker
Assertions
Language Compile
Model Build
Test Program
Generator
Cycle-Based
Model
C++
Testbench
Formal
Verification :
Boolean
Equivalence
Check
July 13, 2016
(Semi) Formal
Verification
Constraint
Random
Unit
Testbench
Software Simulator
Hardware
Accelerator
6
Hardware
Emulator
(c) IBM Corporation
Overview
1. The Target : High-End Server Micros/Systems
2. The Gorilla
Scaling the Simulation-Based Methodology
July 13, 2016
7
(c) IBM Corporation
Scaling the Simulation-Based Methodology
Hardware Emulator
Engine (10k – 100k x)
VPO Level
HW/FW
Verification
VBU Level
Gen: random-biased test pgm + rand. irritation
Check: re-use element check + arch rules
check
Chip Level
Element Level
Gen: random-biased, transactions, test pgm
Check: re-use unit check + pre-calc exp.
results
Unit Level
Software Sim
Engine (1x)
Gen: POR + “bare-metal exerciser” + Linux
Check: pre-calc exp. Results
Gen: random-biased test pgm + rand. irritation
Check: some checker re-use + arch rules
check
System Level
Hardware Accel
Engine (10-1k x)
Gen: POR + Firmware + O/S Boot
Check: pre-calc exp. Results
Gen: random-biased, on-the-fly
Check: detailed, score-boarding, rules
Hardware Verification
VBU = Virtual Bring-up (chip)
VPO = Virtual Power-On (system)
July 13, 2016
8
(c) IBM Corporation
Scaling the Simulation-Based Unit Environments
Driver
Unit 1
Model
Driver
Driver
Testbench
Components
Driver
Unit 2 Checker
(properties)
Unit 1 Checker
(properties)
Driver
Unit 2
Model
Unit 1
Model
Unit 2
Model
Unit 1 Checker
(properties)
Unit 2 Checker
(properties)
Driver
Design
Components
July 13, 2016
9
(c) IBM Corporation
Scaling the Simulation-Based Methodology (cont.)
Success Factors:
Simulation Technology scales well
cycle-based streamlined algorithms
super-linear scaling with “parallel instance support”
large workstation “farms”
Hardware engines for acceleration/emulation
Layered Re-use of checking components
“vertical re-use” -> major productivity
unit->core->chip->system
Sophisticated generation technology
simple constraint-based random at unit level
constraint-based, on-the-fly transaction generation for data-mover
units (e.g. memory sub-system)
heavy constraint-based test program generation at core/chip/system
July 13, 2016
10
(c) IBM Corporation
“Gorilla Muscles”
Unit Level :
Interface-specific checking
Intrusive checking
Implementation dependent
Lots of code ( > 500k LOC C++)
Score-boarding
accumulate state in data structures
Sophisticated drivers (constraint random)
System
Chip
Core Level :
Integrate unit level checkers
Re-use drivers or use architecture testgen
Core
Unit
Chip Level :
Integrate cores + select/re-use
Architecture testgen
# Verification
Engineers
July 13, 2016
System Level :
Big environment integration job (several chip env)
Architecture testgen
11
(c) IBM Corporation
Don’t Underestimate the Gorilla’s IQ
Experienced verification engineers
productivity differences >10x
Sophisticated Generation Technology
model-based generation
Coverage Technology
July 13, 2016
12
(c) IBM Corporation
Overview
1. The Target : High-End Server Micros/Systems
2. The Gorilla
Scaling the Simulation-Based Methodology
3. Successes in the Application of (S)FV
July 13, 2016
13
(c) IBM Corporation
Formal Methods
Formal Methods are a vital complement to simulation flow:
Abstract Coherency Protocol verification
Equivalence Checking (Boolean & Sequential) [Paruthi]
almost total elimination of gate-level verification
Coverage Reachability Analysis
RTL - Special Focus areas
sub-unit level, macro, multi-macro
designer-assertions and FV-expert testbenches
FPU – unit data-path verification [Jacobi]
“Pervasive Logic” [Gloekler]
Lab Bring-up Bug re-creation
often faster repro
high-coverage/proof of side-effect-free fixes
July 13, 2016
14
(c) IBM Corporation
RTL Verification Summary
Successes:
Methodology scaled well even for POWER5/POWER6-size project
POWER6 : two-core, 4-5GHz, 750M transistors
POWER4/5/6 systems booted O/S with first pass hardware
RTL abstraction worked well, even for full custom chip design style
Very repeatable, disciplined, verifiable methodology
Extension of verification with (S)FV helped in many areas of critical
complexity
July 13, 2016
15
(c) IBM Corporation
Endangered Species ??
… or is the Gorilla really a Frog ??
July 13, 2016
16
(c) IBM Corporation
Overview
1. The Target : High-End Server Micros/Systems
2. The Gorilla
Scaling the Simulation-Based Methodology
3. Successes in the Application of (S)FV
4. New Design Challenges
July 13, 2016
17
(c) IBM Corporation
New Pressures On the Ecosystem
New design requirements that multiply complexity (aside from multi-core explosion )
Error Recovery
high-end designs have lots of error detection logic
many different recovery schemes
centralized – checkpoint/restart from recovery unit
decentralized error check/correction
Strategy : error injection
Problems :
myriads of injection points in almost any “mainline state” of the design
end-to-end spec easy (architectural correctness) but unit-level
specification is extremely hard and always in flux
Asynchronous Interfaces
higher integration
creates much larger distances between parts of chip – difficult to control clock skew
globally
modular high-frequency building blocks for productivity
July 13, 2016
18
(c) IBM Corporation
New Pressures On the Ecosystem (cont)
New design requirements that multiply complexity (aside from multi-core explosion )
Power Save Modes
clock gating
nap, doze, sleep modes
functional power gating – unplug power from part of the design
Again : a unit-based specification of correctness is not easily available
-> Partitioning of the problem to unit-level is hard or impossible
Observation :
Many of the above challenges involve “override” or exception functionality
under all conditions, if <exception> then some properties hold
this allows specifications that replace large logic cones to be replaced by free variables
easy problem reduction by (S)FV tools
while simulation still runs a full model
July 13, 2016
19
(c) IBM Corporation
Overview
1. The Target : High-End Server Micros/Systems
2. The Gorilla
Scaling the Simulation-Based Methodology
3. Successes in the Application of (S)FV
4. New Design Challenges
5. Growing the Brain
Scaling the (S)FV - Methodology
July 13, 2016
20
(c) IBM Corporation
Scaling the (S) FV Methodology
Scaling our use of (S)FV is undisputedly our main lever to improve pre-silicon
verification
Wherever we use (S)FV successfully, the verification is stronger
Our strategy to improve verification quality is
Non-Intrusive Formal Verification [Baumgartner]
Rather than wait for
“the new verification engineer” (in large numbers)
or a break-through in technology
Shape overall methodology to allow leverage of most work in
both halves of the methodology
simulation
(S)FV
What are the successes, what are the obstacles ?
July 13, 2016
21
(c) IBM Corporation
Sidebar
Sidebar 5 Ground rules for successful methodology evolution
July 13, 2016
22
(c) IBM Corporation
Ground Rule 1 : Management Force Is Not Effective
A team that does not buy into a methodology change
will make it fail
Example : Design Verification Coverage
the “6-KiloTon-Coverage” story
July 13, 2016
23
(c) IBM Corporation
Ground Rule 2 : It’s Evolution
Don’t bank on quick revolutions in
design/verification methodology development…
… unless there is reason to hire a new
design/verification team
… unless a previous project was a disaster
Design/verification methodologies advance in
evolutionary ways
teams want to keep successful methods
exchange only deficient parts of existing
methodology
July 13, 2016
24
(c) IBM Corporation
Anticyclic Investments; Iterative, Collective Learning
Methodology Change Cycle
effort
Design Project Cycle
Evolution happens in time windows between projects – these windows shrinking !
time
Introduction of new technologies/methodologies
Technology
utilization
Example:
the “Logic-Synthesis” story
Second cycle back-lash
time
Early exuberant enthusiasm
July 13, 2016
25
(c) IBM Corporation
Ground Rule 3 : Balanced Optimization
A methodology optimization along just one axis
of the design constraint space is doomed
Example : Design Verification Coverage
Higher-level design specification
the “FSM-Design-Language” story
Automatically extracted specification
the “Inferred-FSM” story
July 13, 2016
26
(c) IBM Corporation
Ground Rule 4 : Exploit Synergies
Any verification methodology/technology advance has to
embrace the verification team
A new tool or method must not put additional burden on
the verification team w/o significant overall gain
Success is more likely if the additional effort can be
used synergistically for more than one purpose
July 13, 2016
27
(c) IBM Corporation
Ground Rule 5 : Leverage Industry Standards
A new methodology/technology will be more easily
embraced if it involves learning a new, marketable skill
Examples:
the “xxx-to-VHDL” story
Counter-Example:
the “The-Team-That-Signed-Up-For-Life” story
July 13, 2016
28
(c) IBM Corporation
Sidebar
Sidebar
July 13, 2016
-
END
29
(c) IBM Corporation
Synergistic Sim/FV Methodology
Crucial Areas of Synergy :
1. Common Design Model
No semantic gaps between simulation / FV
2. Common Design Partitions / Units
3. Common Designer Assertions / Coverage Specifications
4. Common Verification Properties / Testbench Checkers
5. Common Environment Specs / Testbench Drivers
July 13, 2016
30
(c) IBM Corporation
1. Common Design Model
RTL
(VHDL, Verilog)
Physical VLSI
Design Tools /
Custom Design
PSL et al.
Driver/Checker
Assertions
Language Compile
Model Build
Test Program
Generator
Cycle-Based
Model
C++
Testbench
Formal
Verification :
Boolean
Equivalence
Check
July 13, 2016
(Semi) Formal
Verification
Constraint
Random
Unit
Testbench
Software Simulator
Hardware
Accelerator
31
Hardware
Emulator
(c) IBM Corporation
2. Common Design Partitions
The functional unit is the center of gravity for simulation-based
verification
FV technologies that scale only to macro (sub-unit) level require
specifications at non-documented, fluid interfaces
“impedance mismatch” between simulation/FV effort
Aggressive scaling of (S)FV (e.g. SixthSense) with unit level capacity
goal
July 13, 2016
32
(c) IBM Corporation
3. Common Designer Assertion/Coverage Specifications
Synthesizable assertions / coverage events
easy : designers stay in their domain
hard : designers do “extra work”
Assertion-based verification is a great example of successful
methodology evolution
PSL / SVA embed assertions in HDLs
Use (S)FV to discard unreachable assertions / coverage events
automatic integration into simulation flow largely lacking
July 13, 2016
33
(c) IBM Corporation
4/5. Common Testbench
RTL
(VHDL, Verilog)
Physical VLSI
Design Tools /
Custom Design
PSL et al.
Driver/Checker
Assertions
Language Compile
Model Build
Test Program
Generator
Cycle-Based
Model
C++
Testbench
Formal
Verification :
Boolean
Equivalence
Check
July 13, 2016
(Semi) Formal
Verification
Constraint
Random
Unit
Testbench
Software Simulator
Hardware
Accelerator
34
Hardware
Emulator
(c) IBM Corporation
4./5. Common Testbench (cont.)
An FV requirement for a separate testbench (esp. driver) is the biggest
obstacle against larger proliferation
Most success in situations where little or no specific environment specification
is necessary :
interfaces/properties where mostly non-deterministic driving is sufficient
use of an abstract HDL reference model and SEC (FPU data path [Jacobi])
Re-use between Sim/FV requires a synthesizable testbench
High-level HDL synthesis for verification (minimize states for FV)
Goal conflict between…
..easy to code sequential algorithms with dynamic score-boards (a la C++ container
classes)
..efficient mapping to hardware structures
Synthesis from HVL (high-level verification languages) has been worked on (for emulation)
but with very limited success
SystemC (SVC) synthesis ?
Different language candidates ?
July 13, 2016
35
(c) IBM Corporation
4./5. Common Testbench (cont.)
Re-usable HDL template libraries seem practical way to drive forward
Needs gradual re-education of verification engineers
The same engineers that just went through the HVL transition 
Testbench drivers
First simple approach is to separate:
port driver - synthesizable, translator of transaction to pin
interface ( aka transactor)
generator –
runtime constraint-based/pre-gen’d transactions for sim
non-deterministic environment for FV (procedural or constraint
specified)
July 13, 2016
36
(c) IBM Corporation
Conclusion
Hardware verification still is the bottle-neck
We desperately need the increasing scalability of (S)FV base technologies
and take their arrival as a given
Simulation technology is improving in parallel, but does it get enough
academic focus ?
We need better
re-use
synergy
seamless mix & match
of the verification work in simulation and FV
We need to force investment in future verification infrastructure to support
dual-use technology
July 13, 2016
37
(c) IBM Corporation
Ecological Niche or Survival Gear?
Improving an
Industrial Simulation Methodology with Formal Methods
Thank you!
July 13, 2016
38
(c) IBM Corporation
Download