1
2
Functional verification
Marcin KazmierczakSwitchCore AB
3
SwitchCore today
• Fab-less semiconductor company• Develops integrated switching devices with advanced
QoS functionality for the gigabit Ethernet market.• In-house back-end and full-custom design• 85 employees• Offices in Lund, Stockholm, San Jose, Boston and
Singapore
4
Design flow
Specification RTL-DesignBlock-level
Simulations
Top-level
Regression
Synthesis
Regression
Tests netlist
Floorplanning
Layout
Static Timing
AnalysisDRC Tape Out
5
Verification Flow
Specification
Verification Plan
Beh
RTL coding
TB
RTL debug
TC
Ext sim
6
Why verify?
• Check that the design meets the specification• Standards• Bugs cause re-spin• Cost• Time
7
Cost of bug
• Block design• Chip simulation
– More debug– May require change in algorithm
• Silicon in lab– Most often requires new tape-out– Expensive
• At customer environment– Very expensive– Reputation
8
• Simulate• Stimulate a device from its inputs• Monitor outputs for expected behaviour• Show that the DUT works correctly for all valid
combinations of inputs
Functional simulation
DUT
9
Testbench environment
• Software based simulation environment• Resembles hardware lab
– Pattern generators– Logic analyzers
• Bus-functional models• Harness
10
Harness
Testbench environment
DUT
BFM
Engine (Scoreboard, Parser)
Testcases
BFM BFM
11
Bus-functional models
• Interfaces with DUT• Raises level of abstraction• Easier debug• Encapsulation• Protocol checking• Error-injection• Reuse
PHY
sendFrame (N, Size)setParam (N, VAL)setCOL (VAL)
12
Testcases
• Direct testcases• Test isolated function• Automated result• Language• Calls high-level routines in
testbench
Stimuli
PASS FAIL
TB ENGINE
Expectedoutput
13
Verification plan
• General specification• Features• Definition of testcases• Conformance test plan• Specification of environment • Allocation of resources • Goals• Difficult to plan all activities• Block-level verification plan
14
Behavioural model
• External functionality • High-level software
constructs• Keep it simple• Shorter development time• Faster simulations• Debug testcases• Archictectural issues• Differences from RTL
RTL
BFM BFM
BEH
15
Regression
• Test suite• Automation• Run on regular basis• Verify added functionality• Check that nothing already verified is broken• Repeatable
16
Observability
• Propagation• Detection
DUT
17
• Triggering an error condition• Coverage
Controllability
DUT
18
Code coverage
• Statement• Branch• Path• Quality measure of test suite• Deficiencies?
– Hardware concurrency
19
Functional coverage
• State machine – States– Transitions
• Transactions– CPU interfaces
• Sequences– Frames– Cpu accesses
• Combinations
20
Extended verification
• Testplan– Basic sanity– Functions– Stress
• Fill coverage holes• Random simulation• When are we done?
21
Random simulation
• Stress the device (realistic environment)• Internal interactions • Hit corner-case• Requires more advanced environment• Parameters• Error-injection• Repeatable• Run-time
22
Random simulation
• Requirements on verification environment
DUT
BFM
BFM BFM
Randomparameters
Expectedresult
PASS ?FAIL ?
constraintsseed
23
Generation
• Bus-functional models• Higher-level of abstraction• Identification
– Sequence numbers
• Coverage– Frame types– Sequences
24
Checking
• Protocol checkers– Bus-functional models– Standards
DUTBFM BFM
Protocol violation
25
Checking
• Scoreboard– Transfer function– Expected data– Comparison function– Identification– On-the-fly checking– Difficulties?
DUTBFM BFM
ScoreboardMatch/Comparison
26
Parsing
• Testcases written in proprietary format (SwitchCore)• Easy to change and re-run• Pre-processing of testcases (Perl)
Testcase TestfilePre-processor
27
HDL Testbenches
• HDLs (Verilog/VHDL) can be powerful with advanced coding style
• Known languages• But not efficient in testbench coding• Deficiencies
– Non re-rentrant tasks in Verilog– No powerful primitives
28
Specman/E
• Powerful primitives• Functional Coverage Points• Randomization• Methodology• No upfront definition of testcases• Verisity (www.verisity.com)
29
Functional Coverage Points
• Generated stimuli– Frame types
• State machines• Signals
– Values
• Transactions– Cpu access
• Sequence / Combination of events• Crossing coverage points
30
Vera
• Verilog based• Object-oriented• Randomization functions• Checking• Synopsis (www.synopsis.com)
31
TestBuilder
• C++• Class-library• Generation / checking• Open-source• Integration with NC-Verilog• Cadence (www.cadence.com)
32
Formal Verification
• Mathematical• Proof properties• Exhaustive• Size• Properties
• Equivalence checking– netlist - netlist– RTL - netlist
33
White-Box Verification
• Assertions• Increase observability• Better coverage measure • Easier debug• Corner-cases• Used during RTL simulations
DUT
Error!
34
Semi-Formal Verification
• Increase controllability• Formally check if assertions can be violated• Used with assertions during RTL simulations• Not exhaustive• Zero-in (www.0-in.com)
35
System simulation
• Board level (several ASICs)• Interfaces• Interactions• Boundaries?• Simulation models
PHY Q NP IF
RAM
uP
36
Emulation
• System of FPGAs• Faster simulation• Software/Hardware co-verification• Difficulties
– Generation– Checking
• Longer iteration time• Size of design?• Very expensive• www.quickturn.com
37
When are we done?
• How do we know that we have checked everything?• Functions tested• Bug rate• Coverage• Very difficult question...
38
Bugs
• Bug tracking important• Categories
– Minor– Respin– DOA (Dead-On-Arrival)
39
SwitchCore
• ModelSim• Simulation on RTL and netlist (with timing)• Netlist simulation are very slow• Static timing analysis more efficient in finding timing
issues
40
SwitchCore
• Block-level testbenches• Multi-block testbenches• Top-level testbench• Regression suite• Random tests
41
Experience
• Multi-block testbenches• Designer should not verify own block• Random tests important• ASIC general specification• Planning / Goals• Clean interfaces between blocks• Bug tracking important• Release management• Difficult to plan debugging time
42
Future
• Random simulation• Testcase generation• Closed-loop random generation• Formal methods• Hybrid methods (e.g. Semi-formal)• Less RTL coding • Verification more and more important