SoC Verification

1

SoC Verification Methodology

Prof. Chien-Nan LiuTEL: 03-4227151 ext:4534

Email: [email protected]

2

Outline

l Verification Overviewl Verification Strategiesl Tools for Verificationl SoC Verification Flow

3

What is Verification ?

l A process used to demonstrate the functionalcorrectness of a design

l To making sure your are verifying that you areindeed implementing what you want

l To ensure that the result of some transformationis as expected

Specification Netlist

Transformation

Verification

Source : “Writing Test Benches – Functional Verification of HDL Models” by Janick Bergeron, KAP, 2000.

4

Verification Problems

l Was the spec correct ?l Did the design team understand the spec?l Was the blocks implemented correctly?l Were the interfaces between the blocks

correct?l Does it implement the desired

functionality?l ……

5

Testing v.s. Verification

l Testing verifies manufacturing– Verify that the design was manufactured correctly

Specification Netlist Silicon

HW Design

Verification

Manufacturing

Testing

Source : “Writing Test Benches – Functional Verification of HDL Models” by Janick Bergeron, KAP, 2000.

6

SoC Design Verification

l Using pre-defined and pre-verifiedbuilding block can effectively reduce theproductivity gap– Block (IP) based design approach

– Platform based design approach

l But 60 % to 80 % of design effort is nowdedicated to verification

7

VerificationDesign

High Level Design

RTL and Block TestSynthesis

Timing Analysis

DFT

Extended Simulation

Equivalence Checking

Emulation Support

Emulation Software

System Simulation

ASIC Testbenches

BEH Model

Source : “Functional Verification on Large ASICs” by Adrian Evans, etc., 35th DAC, June 1998.

An Industrial Example

Bottleneck !!

8

Verification Complexity

l For a single flip-flop:– Number of states = 2

– Number of test patterns required = 4

l For a Z80 microprocessor (~5K gates)– Has 208 register bits and 13 primary inputs

– Possible state transitions = 2bits+inputs = 2221

– At 1M IPS would take 1053 years to simulate alltransitions

l For a chip with 20M gates– ??????

*IPS = Instruction Per Second

9

When is Verification Complete ?

l Some answers from real designers:– When we run out of time or money

– When we need to ship the product

– When we have exercised each line of the HDL code

– When we have tested for a week and not found anew bug

– We have no idea!!

l Designs are often too complex to ensure fullfunctional coverage– The number of possible vectors greatly exceeds the

time available for test

10

Typical Verification Experience

Functional

testing

Weeks

Bugs

per

week

TapeoutPurgatory

11

Error-Free Design ?

l As the number of errors left to be founddecreases, the time and cost to identifythem increases

l Verification can only show the presenceof errors, not their absence

l Two important questions to be solved:– How much is enough?

– When will it be done?

12

Reference Book

l System-on-a-Chip VerificationMethodology and Techniques

l byPrakash RashinkarPeter PatersonLeena SinghCadence Design Systems Inc., USA

l published byKluwer Academic Publishers, 2001

13

Outline


14

Verification Approaches

l Top-down verification approach– From system to individual components

l Bottom-up verification approach– From individual components to system

l Platform-based verification approach– Verify the developed IPs in an existing platform

l System interface-based verification approach– Model each block at the interface level

– Suitable for final integration verification

15

Advs. of Bottom-up Approach

l Localityl Catching bugs is easier and faster with

foundational IPs (sub-blocks)l Design the SoC chip with these highly

confidence “bug-free” IPs

16

Verification Environment

Design under

Verification

Testbench

Input Pattern(Stimulus)

Output(Response)

DUV

17

Terminology

l Verification environment– Commonly referred as testbench (environment)

l Definition of a testbench– A verification environment containing a set of

components [such as bus functional models (BFMs),bus monitors, memory modules] and theinterconnect of such components with the design-under-verification (DUV)

l Verification (test) suites (stimuli, patterns,vectors)– Test signals and the expected response under given

testbenches

18

Testbench Design

l Auto or semi-auto stimulus generator is preferredl Automatic response checking is highly

recommendedl May be designed with the following techniques

– Testbench in HDL

– Tesebench in programming language interface (PLI)

– Waveform-based

– Transaction-based

– Specification-based

19

Types of Verification Tests (1/2)

l Random testing– Try to create scenarios that engineers do

not anticipate

l Functional testing– User-provided functional patterns

l Compliances testingl Corner case testingl Real code testing (application SW)

– Avoid misunderstanding the spec.

20

Types of Verification Tests (2/2)

l Regression testing– Ensure that fixing a bug will not introduce

another bug(s)

– Regression test system should be automated• Add new tests

• Check results and generate report

• Distribute simulation over multiple computer

– Time-consuming process when verificationsuites become large

21

Bug Tracking

l A central database collecting knownbugs and fixes

l Avoid debugging the same bug multipletimes

l Good bug report system helpsknowledge accumulation

22

Bug Rate Tracking

l Bug rate usually follow a well-definedcurve

l The position on the curve decides themost-effective verification approach

l Help determine whether the SoC isready to tape-out

23

Bug Rate Tracking Example

0

1 02 0

3 04 0

5 0

6 07 0

8 09 0

1 0 0

0 2 4 6 8 1 0 1 2

Time

# o

f bugs

report

ed

24

Adversarial Testing

l For original designers– Focus on proving the design works correctly

l Separate verification team– Focus on trying to prove the design is broken

– Keep up with the latest tools andmethodologies

l The balanced combination of these twogives the best results

25

Verification Plan

l Verification plan is a part of the design reportsl Contents

– Test strategy for both blocks and top-level module

– Testbench components – BFM, bus monitors, …...

– Required verification tools and flows

– Simulation environment including block diagram

– Key features needed to be verified in both levels

– Regression test environment and procedure

– Clear criteria to determine whether the verificationis successfully complete

26

Benefits of Verification Plan

l Verification plan enables– Developing the testbench environment early

– Developing the test suites early

– Developing the verification environment in parallelwith the design task by a separate team

– Focusing the verification effort to meet theproduct shipment criteria

– Forcing designers to think through the time-consuming activities before performing them

27

Outline


28

Tools for Verification (1/4)

l Simulation– Event-driven:

• Timing accurate

– Cycle-based:• Faster simulation time (5x – 100x)

– Transaction-based:• Require bus functional model (BFM) of each

design

• Only check the transactions between components

• Have faster speed by raising the level ofabstraction

29

Event-Driven Simulation

l Timing accuratel Good debugging environmentl Simulation speed is slower

AdvanceTime

GetCurrentEvent

EventEvaluation

PropagateEvents

ScheduleNew

Events

More eventsfor this time

Time wheelempty Finish

Y

Y

N

N

30

Cycle-Based Simulation

l Perform evaluations justbefore the clock edge– Repeatedly triggered events

are evaluated only once

in a clock cycle

l Faster simulation time (5x – 100x)l Only works for synchronous designsl Only cycle-accuratel Require other tools (ex: STA) to check timing

problems

Clock

Input

Output

31

Simulation-Based Verificationl Still the primary approach for functional verification

– In both gate-level and register-transfer level (RTL)

l Test cases– User-provided (often)

– Randomly generated

l Hard to gauge how well a design has been tested– Often results in a huge test bench to test large designs

l Near-term improvements– Faster simulators

• Compiled code, cycle-based, emulation, …

– Testbench tools

• Make the generation of pseudo-random patterns better/easier

l Incremental improvements won’t be enough

32


l Code coverage– Qualify a particular test suite when applied to a

specific design– Verification Navigator, CoverMeter, …

l Testbench (TB) automation– A platform (language) providing powerful constructs

for generating stimulus and checking response– VERA, Specman Elite, …

l Analog/mixed-signal (AMS) simulation– Build behavior model of analog circuits for system

simulation– Verilog-A, VHDL-A, …

33

Coverage-Driven Verification

l Coverage reports can indicate how much ofthe design has been exercised– Point out what areas need additional verification

l Optimize regression suite runs– Redundancy removal (to minimize the test suites)

– Minimizes the use of simulation resources

l Quantitative sign-off (the end of verificationprocess) criterion

l Verify more but simulate less

34

The Rate of Bug Detection

Time

Rate ofdugs found

without coverage

with coverage

purgatory releaseFunctionalTesting

source : “Verification Methodology Manual For Code Coverage In HDL Designs” by Dempster and Stuart

35

Coverage Analysis

l Dedicated tools are required besides the simulatorl Several commercial tools for measuring Verilog and

VHDL code coverage are available– VCS (Synopsys)

– NC-Sim (Cadence)

– Verification navigator (TransEDA)

l Basic idea is to monitor the actions during simulationl Require supports from the simulator

– PLI (programming language interface)

– VCD (value change dump) files

36

Analysis Results

n Verification Navigator (TransEDA)

Untested code line will be highlighted

37

Testbench Automation

l Require both generator and predictor in anintegrated environment

l Generator: constrained random patterns– Ex: keep A in [10 … 100]; keep A + B == 120;

– Pure random data is useless

– Variations can be directed by weighting options

– Ex: 60% fetch, 30% data read, 10% write

l Predictor: generate the estimated outputs– Require a behavioral model of the system

– Not designed by same designers to avoidcontaining the same errors

38

Analog Behavioral Modeling

l A mathematical model written in HardwareDescription Language

l Emulate circuit block functionality by sensingand responding to circuit conditions

l Available Analog/Mixed-Signal HDL:– Verilog-A

– VHDL-A

– Verilog-AMS

– VHDL-AMS

39

Mixed Signal Simulation

l Available simulators:CadenceAntrimMentorSynopsys……

40


l Static technologies– Lint checking:

• A static check of the design code

• Identify simple errors in the early design cycle

– Static timing analysis:

• Check timing-related problems without input patterns

• Faster and more complete if applicable

– Formal verification:

• Check functionality only

• Theoretically promise 100% coverage but designsize is often limited due to high resource requirement

41

HDL Linter

l Fast static RTL code checker– Preprocessor of the synthesizer– RTL purification (RTL DRC)

• Syntax, semantics, simulation

– Check for built-in or user-specified rules• Testability checks• Reusability checks• ……

– Shorten design cycle• Avoid error code that increases design iterations

42

Inspection

l For designers, finding bugs by carefulinspection is often faster then that by simulation

l Inspection process– Design (specification, architecture) review

– Code (implementation) review• Line-by-line fashion

• At the sub-block level

l Lint-liked tools can help spot defects withoutsimulation– Nova ExploreRTL, VN-Check, ProVerilog, …

43

What is STA ?

l STA = static timing analysisl STA is a method for determining if a circuit meets

timing constraints without having to simulatel No input patterns are required

– 100% coverage if applicable

D Q

FF1

D Q

FF2

A Z

CLK

Reference :Synopsys

44

Formal Verification

l Ensure the consistency with specification forall possible inputs (100% coverage)

l Primary applications– Equivalence Checking– Model Checking

l Solve the completeness problem in simulation-based methods

l Cannot handle large designs due to its highcomplexity

l Valuable, but not a general solution

45


RTL or Netlist

RTL or Netlist

Synthesis


l Gate-level to gate-level– Ensure that some netlist post-processing did not change the

functionality of the circuit

l RTL to gate-level– Verify that the netlist correctly implements the original RTL code

l RTL to RTL– Verify that two RTL descriptions are logically identical

46


l Compare two descriptions to check theirequivalence

l Gaining acceptance in practice– Abstract, Avant!, Cadence, Synopsys, Verplex,

Verysys, …

l But the hard bugs are usually in bothdescriptions

l Target implementation errors, not design errors– Similar to check C v.s. assembly language

47

Model Checking

Specification RTL

RTL Coding

Model CheckingAssertions

Interpretation

l Formally prove or disprove some assertions(properties) of the design

l The assertions of the design should be providedby users first– Described using a formal language

48

Model Checking

l Enumerates all states in the STG of thedesign to check those assertions

l Gaining acceptance, but not widely used– Abstract, Chrysalis, IBM, Lucent, Verplex,

Verysys, …

l Barrier: low capacity (~100 register bits)– Require extraction (of FSM controllers) or

abstraction (of the design)

– Both tend to cause costly false errors

49

New Approaches

l The two primary verification methods both havetheir drawbacks and limitations– Simulation: time consuming

– Formal verification: memory explosion

l We need alternate approaches to fill theproductivity gap– Verification bottleneck is getting worse

l Semi-formal approaches may be the solution– Combine the two existing approaches

– Completeness (formal) + lower complexity (simulation)

50


l Hardware modeling– Pre-developed simulation models for other

hardware in a system– Smart Model (Synopsys)

l Emulation– Test the system in a hardware-liked fashion

l Rapid prototyping– FPGA– ASIC test chip

51

Assistant Hardware

l Rule of thumb– 10 cycles/s for software simulator

– 1K cycles/s for hardware accelerator

– 100K cycles/s for ASIC emulator

l Hardware accelerator– To speed up logic simulation by mapping

gate level netlist into specific hardware

– Examples: IKOS, Axis, ….

52

Emulation

l Emulation– Verify designs using real hardware (like FPGA?)

– Better throughput in handling complex designs

– Inputs should be the gate-level netlist

– Synthesizable testbenches required

– Require expensive emulators

– Software-driven verification• Verify HW using SW

• Verify SW using HW

– Interfaced with real HW components

– Examples: Aptix, Quicktum, Mentor’s AVS ….

53

Prototyping

l FPGA– Performance degradation

– Limited design capacity (utilization)

– Partitioning and routing problems

l Emulation system– FPGA + Logic modeler

– Automatic partitioning and routing underEDA SW control

– More expensive

54

Limited Production

l Even after robust verification process andprototyping, it’s still not guaranteed to bebug-free

l Engineering samplesl A limited production for new macro is

necessary– 1 to 4 customers

– Small volume

– Reducing the risk of supporting problems

l Same as real cases but more expensive

55

Comparing Verification Options

Source : “System-on-a-chip Verification – Methodology and Techniques” by P. Rashinkar, etc., KAP, 2001.

56

Outline


57

SOC Verification Methodology


58

System Verification Steps

l Verify the leaf IPsl Verify the interface among IPsl Run a set of complex applicationsl Prototype the full chip and run the

application softwarel Decide when to release for mass

production

59

Interesting Observations

l 90% of ASICs work at the first silicon but only50% work in the target system– Do not perform system level verification (with

software)

l If a SoC design consisting of 10 blocks– P(work)= .910 =.35

l If a SoC design consisting of 2 new blocksand 8 pre-verified robust blocks– P(work) = .92 * .988 =.69

l To achieve 90% of first-silicon success SoC– P(work) = .9910 =.90

60

Interface Verification

l Inter-block interfaces– Point-to-point

– On-chip bus (OCB)

– Simplified models are used• BFM, bus monitors, bus checkers

61

Check System Functionality (1/2)

l Verify the whole system by using fullfunctional models– Test the system as it will be used in the

real world

l Running real application codes (such asboot OS) for higher design confidence– RTL simulation is not fast enough to

execute real applications

62

Check System Functionality (2/2)

l Solutions– Move to a higher level of abstraction for

system functional verification

– Formal verification

– Use assistant hardware:• Hardware accelerator

• ASIC emulator

• Rapid-prototyping(FPGA)

• Logic modeler

• …

63

HW/SW Co-Simulationl Couple a software execution environment with

a hardware simulatorl Simulate the system at higher levels

– Software normally executed on an Instruction SetSimulator (ISS)

– A Bus Interface Model (BIM) converts softwareoperations into detailed pin operations

l Allows two engineering groups to talk togetherl Allows earlier integrationl Provide a significant performance improvement

for system verification– Have gained more and more popularity

64

System-Level Testbench

l All functionality stated in thespec. should be covered

l The success and failureconditions must be definedfor each test

l Pay particular attention to:– Corner cases

– Boundary conditions

– Design discontinuities

– Error conditions

– Exception handling


65

Timing Verification

l STA (static timing analysis) is the fastestapproach for synchronous designs– Avoid any timing exceptions is extremely important

l Gate-level simulation (dynamic timing analysis)– Most useful in verifying timing of asynchronous

logic, multi-cycle paths and false paths

– Much slower run-time performance

– Gate-level sign-off

66

Design Sign-off

l Sign-off is the final step in thedesign process

l It determines whether the design isready to be taped out for fabrication

l No corrections can be made afterthis step

l The design team needs to beconfident that the design is 100%correct– Many items need to be checked


67

Traditional Sign-off

l Traditional sign-off simulation– Gate level simulation with precise timing under a

given parallel verification vectors

– Verify functionality and timing at the same time(dynamic timing analysis, DTA)

– Parallel verification vectors also serve as themanufacturing test patterns

l Problems– Infeasible for million gates design (take too much

simulation time)

– Fault coverage is low (60% typically)

– Critical timing paths may not be exercised

68

SoC Sign-off Scheme

l Formal verification used to verifyfunctionality

l STA for timing verificationl Gate level simulation

– Supplement for formal verification and STA

l Full scan BIST for manufacturing test

Documents

SoC Verification