functional verification lul - sm.luth.se€¦ · functional verification marcin kazmierczak...

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