jasper lecture

8/16/2019 Jasper Lecture

1/37

Industrial Application of Industrial Application of Formal VerificationFormal Verification

Industrial Application of Industrial Application of Formal VerificationFormal Verification

yste n o sru Jasper Design Automation

yste n o sru Jasper Design Automation


2/37

- 2 - ©2008 Jasper Design Automation

INTRODUCTION TO JASPERINTRODUCTION TO JASPER


3/37

Jasper Design AutomationJasper Design Automation

• Develop tools for formal functional verification

• Customers: Primarily large semiconductor companies

– AMD

– NVIDIA

– Sony

• Develop tools for formal functional verification

• Customers: Primarily large semiconductor companies

– AMD

– NVIDIA

– Sony


– Sun– ...– Sun– ...


4/37

Jasper Design AutomationJasper Design Automation

• Head office in California

• Other offices

– Sweden (Gothenburg)

– Brazil

– Japan (through distributor)

• Head office in California

• Other offices

– Sweden (Gothenburg)

– Brazil

– Japan (through distributor)


• Total number of employees: ~50– Currently distributed 50/50 between sales and engineering

• Gothenburg team

– ~10 employees

– 5 from Chalmers (most from Computer Science)

• Total number of employees: ~50– Currently distributed 50/50 between sales and engineering

• Gothenburg team

– ~10 employees

– 5 from Chalmers (most from Computer Science)


5/37


6/37


THE VERIFICATION PROBLEMTHE VERIFICATION PROBLEM


7/37

Functional Verification is a Huge, Growing ProblemFunctional Verification is a Huge, Growing Problem

• Verification consumes up to 70% of design resources• Verification consumes up to 70% of design resources

a t i o n T i m e


• The problem is growing exponentially

–More simulation is not the answer

• The problem is growing exponentially

–More simulation is not the answer

Verification Design Design Size

S i m

u l


8/37

The Stakes Are HighThe Stakes Are High

• “A majority of ASICs/ICs require at least one respin.71% of respins are due to functional bugs verification

should have caught.”- Collett International Research, Inc.

• “A majority of ASICs/ICs require at least one respin.71% of respins are due to functional bugs verification

should have caught.”- Collett International Research, Inc.


os o o mas se = o +Total cost of respin to project = ~$10M


9/37

Verification MethodologiesVerification Methodologies

• Dominating verification methodologies

– Directed Simulation

• Requires specification of test bench

• Requires manual targeting of corner cases

– Constrained Random Verification

• Dominating verification methodologies

– Directed Simulation

• Requires specification of test bench

• Requires manual targeting of corner cases

– Constrained Random Verification


• Verification quality measurements

– Coverage metrics

• Line coverage

• Expression coverage• Functional coverage

• Verification quality measurements

– Coverage metrics

• Line coverage

• Expression coverage• Functional coverage


10/37

Formal Technology: A Simple ViewFormal Technology: A Simple View

Design

?Can this

scenario happen?


YESNO

Guarantee that the scenariocannot happen for ALL possible

ways design can operate

FormalTool


11/37

Formal Verification in a NutshellFormal Verification in a Nutshell

DesignSpec


• Analytical reasoning eliminates testbench creation

• 100% state space coverage for given constraints• Can produce counter-examples to show spec violation

• Can establish correctness of design against spec

• Analytical reasoning eliminates testbench creation

• 100% state space coverage for given constraints• Can produce counter-examples to show spec violation

• Can establish correctness of design against spec

ReasoningΠΠΠΠD ΠΠΠΠSMathematical

Modeling


12/37

Who Uses Formal?Who Uses Formal?

• Mostly ASIC vendors

– FPGA verification not as critical

• Proliferation– Still limited

– Mostly dedicated verification people

• Mostly ASIC vendors

– FPGA verification not as critical

• Proliferation– Still limited

– Mostly dedicated verification people


– Some companies have dedicated formal teams• Trends over resent years

– Market is clearly growing

– Most people have now heard about formal

– Some companies are looking for wider proliferation

– Some companies have dedicated formal teams• Trends over resent years

– Market is clearly growing

– Most people have now heard about formal

– Some companies are looking for wider proliferation


13/37


WHERE TO APPLY FORMALWHERE TO APPLY FORMAL


14/37

Where to Apply Formal: Design SizeWhere to Apply Formal: Design Size

• “How large blocks can your tool handle?”

– No good answer to this question!

– Totally function dependant

– Fundamental problem is NP complete

• Rule of thumb, Focus on:

• “How large blocks can your tool handle?”

– No good answer to this question!

– Totally function dependant

– Fundamental problem is NP complete

• Rule of thumb, Focus on:


– Designer sized blocks– Critical functionalities

• “Ensure Correctness Where it Matters Most”

– Designer sized blocks– Critical functionalities

• “Ensure Correctness Where it Matters Most”


15/37

Where to Apply Formal: FunctionalityWhere to Apply Formal: Functionality

• Formal is not good for everything!

• Good candidates:

– Data transportation

– Control logic

– Parallel interactions

• Formal is not good for everything!

• Good candidates:

– Data transportation

– Control logic

– Parallel interactions


• Bad candidates:– Data transformation

– DSP (Digital Signal Processing)

– Mathematics (FPU)

– Data encryption

• Bad candidates:– Data transformation

– DSP (Digital Signal Processing)

– Mathematics (FPU)

– Data encryption


16/37

Good Design Candidates for FormalGood Design Candidates for Formal

• Arbiters

• On-chip bus bridge

• Power management unit

• DMA controller

• Arbiters

• On-chip bus bridge

• Power management unit

• DMA controller

• Interrupt controller

• Memory controller

• Token generator

• Cache coherency

• Interrupt controller

• Memory controller

• Token generator

• Cache coherency


• Scheduler,implementing multiplethreads

• Virtual channels for QoS

• Scheduler,implementing multiplethreads

• Virtual channels for QoS

Common characteristics of these blocks:

Concurrency and multiple data streams, which are difficult to completelyverify using simulation

• Standard interface(USB, PCI Express…)

• Proprietary interfaces

• Clock disable unit

• Standard interface(USB, PCI Express…)

• Proprietary interfaces

• Clock disable unit


17/37

Example 1: Network traffic managerExample 1: Network traffic manager

• Bandwidth allocator for network switch

– Customers buys a certain bandwidth access (eg 10 Mb/s

access)– Switch must ensure that:

• Customer gets at least 10 Mb/s access

• Customer does not et more that 10 Mb s access

• Bandwidth allocator for network switch

– Customers buys a certain bandwidth access (eg 10 Mb/s

access)– Switch must ensure that:

• Customer gets at least 10 Mb/s access

• Customer does not et more that 10 Mb s access


– Each customer can by different bandwidth sizes• 256 Kb/s

• 512 kb/s

• ...

• 10 Mb/s• ...

– Each customer can by different bandwidth sizes• 256 Kb/s

• 512 kb/s

• ...

• 10 Mb/s• ...


18/37

Example 1: Credit ManagerExample 1: Credit Manager

• Bandwidth allocation controlled by credit manager

– Buying a bandwidth of speed n gives you x credit tokens on

the switch– The tokens denote access to switch memory

– Packet enters design: 1 token deducted from credit pool

–

• Bandwidth allocation controlled by credit manager

– Buying a bandwidth of speed n gives you x credit tokens on

the switch– The tokens denote access to switch memory

– Packet enters design: 1 token deducted from credit pool

–


• Verification problem

– Are token always returned correctly?

– Failing to do so could cause token leakage

– Memory access would be blocked– Switch would hang

• Verification problem

– Are token always returned correctly?

– Failing to do so could cause token leakage

– Memory access would be blocked– Switch would hang


19/37

Example 1: Token Leakage VerificationExample 1: Token Leakage Verification

• Problem characteristics

– Huge number of possible scenarios

– Hundreds of communication channels active at the sametime

– Impossible to verify sufficiently with simulation

–

• Problem characteristics


– Hundreds of communication channels active at the sametime

– Impossible to verify sufficiently with simulation

–


• 1 token leaked every second would force reboots every day

• Perfect fit for formal

– Impossible to enumerate corner case scenarios

– Full proof important

• 1 token leaked every second would force reboots every day

• Perfect fit for formal

– Impossible to enumerate corner case scenarios

– Full proof important


20/37

Example 2: MicrocontrollerExample 2: Microcontroller

• Microcontroller supporting two simultaneousexecution threads

• Verification Problem:– Does instruction execution behave according to spec?

• Property example:

• Microcontroller supporting two simultaneousexecution threads

• Verification Problem:– Does instruction execution behave according to spec?

• Property example:


– Instructions in memory should be executed sequentially• Problem characteristics:


• Combinations of instructions

• Thread context switching

• Interrupt handling

– Instructions in memory should be executed sequentially• Problem characteristics:


• Combinations of instructions

• Thread context switching

• Interrupt handling


21/37

Example 2: Flow Control BugExample 2: Flow Control Bug

• Condition:

– Both threads active

– Thread 1 executes branch– User interrupt kills thread 1 at the same cycle as branch

instruction executes

• Condition:

– Both threads active

– Thread 1 executes branch– User interrupt kills thread 1 at the same cycle as branch

instruction executes


•

– Branch information not cleared

– Causes Thread 2 to branch instead

• Bug characteristics:

– Requires a very specific and cycle accurate scenario tooccur

– Almost impossible to find with simulation

•

– Branch information not cleared

– Causes Thread 2 to branch instead

• Bug characteristics:

– Requires a very specific and cycle accurate scenario tooccur

– Almost impossible to find with simulation


22/37


FORMAL VERIFICATIONCHALLENGESFORMAL VERIFICATIONCHALLENGES


23/37

What Makes a Property Hard to Prove?What Makes a Property Hard to Prove?

• Example:

– A memory has an 8 bit wide data bus and an 8 bit wide

address bus.– Property: If you write data to an address, then the next time

you read from that address you should get the same valueback as you wrote in unless you have performed another

• Example:

– A memory has an 8 bit wide data bus and an 8 bit wide

address bus.– Property: If you write data to an address, then the next time

you read from that address you should get the same valueback as you wrote in unless you have performed another


wr te n t e mean t me.

• Why is this problem hard to prove?

• How would this be verified in simulation?

wr te n t e mean t me.

• Why is this problem hard to prove?

• How would this be verified in simulation?


24/37

State Space ComplexityState Space Complexity

• The State Space problem

– Formal verification explores all possible states

• What is the size of the state space of the previous design?

– Word size is 8 bits

– ^

• The State Space problem

– Formal verification explores all possible states

• What is the size of the state space of the previous design?

– Word size is 8 bits

– ^


.

– Total number of memory bits: 8*2^8 = 2048 bits

• What is the total number of distinct states that the memory

can be in?– 2^2048 = 3.32 * 10^616– Estimated number of atoms in the observable universe: 10^80

.

– Total number of memory bits: 8*2^8 = 2048 bits

• What is the total number of distinct states that the memory

can be in?– 2^2048 = 3.32 * 10^616– Estimated number of atoms in the observable universe: 10^80


25/37


• Example:

– An 8 bit counter, “cnt1”, counts the number of times an input

signal has been high.– Signal “a” is high when “cnt1” is full.

– An 8 bit counter, “cnt2”, counts the number of times “a” hasone hi h.

• Example:

– An 8 bit counter, “cnt1”, counts the number of times an input

signal has been high.– Signal “a” is high when “cnt1” is full.

– An 8 bit counter, “cnt2”, counts the number of times “a” hasone hi h.


– Signal “b” is high when “cnt2” is full.– Property: “a” and “b” are never active at the same time.

– Signal “b” is high when “cnt2” is full.– Property: “a” and “b” are never active at the same time.

cnt18 bit counter

cnt28 bit counter

i a b


26/37


• Why is it hard to find a counter example for thisproblem?

– Number of memory bits are just 2*8– State space is not a big problem

• Why is it hard to find a counter example for thisproblem?

– Number of memory bits are just 2*8– State space is not a big problem



27/37

Sequential Depth ComplexitySequential Depth Complexity

• How many reachable states are there at any givendistance from reset?

– 1 cycle: cnt2 = 0 and cnt1 = 0 or 1 - #states: 2– 2 cycles: cnt2 = 0 and cnt1 = 0,1 or 2 - #states: 3

– 3 cycles: cnt2 = 0 and cnt1 = 0,1,2 or 3 - #states: 4

• How many reachable states are there at any givendistance from reset?

– 1 cycle: cnt2 = 0 and cnt1 = 0 or 1 - #states: 2– 2 cycles: cnt2 = 0 and cnt1 = 0,1 or 2 - #states: 3

– 3 cycles: cnt2 = 0 and cnt1 = 0,1,2 or 3 - #states: 4


– ...

– 256 cycles: cnt1 = 0 to 256 and cnt2 = 0 orcnt1 = 0 and cnt2 = 1 - #states: 257

– ...

– 65535 cycles: cnt1 = 0 to 256, cnt2 = 0 to 256 -#states: 65536

• JasperGold has to verify all of the 65535 steps beforefinding a CEX!

– ...

– 256 cycles: cnt1 = 0 to 256 and cnt2 = 0 orcnt1 = 0 and cnt2 = 1 - #states: 257

– ...

– 65535 cycles: cnt1 = 0 to 256, cnt2 = 0 to 256 -#states: 65536

• JasperGold has to verify all of the 65535 steps beforefinding a CEX!


28/37

Engines and Design ComplexityEngines and Design Complexity

• Main reasons for performance problems:

– State Space Size

– Sequential Depth

• Proof engines do not use brute force to verify all

• Main reasons for performance problems:

– State Space Size

– Sequential Depth

• Proof engines do not use brute force to verify all


com na ons

– Doing so would cause most problems to blow up

– The different engines use different algorithms to handleverification problems efficiently

• Different engines have different strengths andweaknesses

– Formal Expert contains information about engine selection.

com na ons

– Doing so would cause most problems to blow up

– The different engines use different algorithms to handleverification problems efficiently

• Different engines have different strengths andweaknesses

– Formal Expert contains information about engine selection.


29/37

Recognizing a Hard-to-Prove ProblemRecognizing a Hard-to-Prove Problem

• Worst case scenario reasoning

– What is the longest possible trace I would get if there is a

bug in my design?

• Example:

• Worst case scenario reasoning

– What is the longest possible trace I would get if there is a

bug in my design?

• Example:


– roper y: a a n egr y across a us r ge

– What if: Data is corrupted when my FIFO underflows?

• Underflow can happen at cycle 2, bug can be detected aroundcycle 2.

– What if: Data is corrupted when my FIFO overflows?

• Overflow can not happen until at least after FIFO lengthnumber of operations. Bug can only be detected after that.Investigate how large the FIFO is!

– roper y: a a n egr y across a us r ge

– What if: Data is corrupted when my FIFO underflows?

• Underflow can happen at cycle 2, bug can be detected aroundcycle 2.

– What if: Data is corrupted when my FIFO overflows?

• Overflow can not happen until at least after FIFO lengthnumber of operations. Bug can only be detected after that.Investigate how large the FIFO is!


30/37


31/37

Coping with Formal ComplexityCoping with Formal Complexity

• Methodology

– Appropriate size design blocks to apply formal analysis on

– Formal friendly modeling of properties and constraints– Leverage symmetries in the design

– Assume/guarantee reasoning

• Methodology

– Appropriate size design blocks to apply formal analysis on

– Formal friendly modeling of properties and constraints– Leverage symmetries in the design

– Assume/guarantee reasoning


• Technology

– Safe abstraction techniques

– High performance engines

• Technology

– Safe abstraction techniques

– High performance engines


32/37

Formal TestplanFormal Testplan

• Hierarchical definition of design functionality

• Identify functional areas:

– What functionality is the design supposed to deliver?

• Example: PCI network card

– Interface protocol compliance

• Hierarchical definition of design functionality

• Identify functional areas:

– What functionality is the design supposed to deliver?

• Example: PCI network card

– Interface protocol compliance


• Standard protocol rules must be respected– End to end data integrity

• Packets must never be dropped, duplicated, corrupted orreordered

• Gradually refine functionalities until function can becaptured by a property.

– Example: Address must remain stable during request

• Standard protocol rules must be respected– End to end data integrity

• Packets must never be dropped, duplicated, corrupted orreordered

• Gradually refine functionalities until function can becaptured by a property.

– Example: Address must remain stable during request


33/37


34/37

Deep FormalDeep Formal

JasperGoldJasperGold

• End-to-end ro erties• End-to-end ro erties

Jasper’s Use ModelsJasper’s Use Models

• Push-button static ABV• Push-button static ABV

Light FormalLight Formal

JasperGold ExpressJasperGold Express

• RTL only• RTL only

InFormal™InFormal™

JasperGold ExpressJasperGold Express


Full verification ofcritical features

Full verification ofcritical features

• Jasper ProofAccelerators™,Lossless Abstractions™,Formal Scoreboard™

• Full proofs

• Jasper ProofAccelerators™,Lossless Abstractions™,Formal Scoreboard™

• Full proofs

Easy bug huntingand proofs

Easy bug huntingand proofs

• Properties & constraints• SVA Local Variables• Powerful debugging• Parallel Engine

Execution

• Properties & constraints• SVA Local Variables• Powerful debugging• Parallel Engine

Execution

RTLExploration

RTLExploration

• Demonstrate legal

design behavior• No properties• No testbench

• Demonstrate legal

design behavior• No properties• No testbench


35/37

™™

The JasperGold Product FamilyThe JasperGold Product Family

GamePlan™

Verification Planner

User-DefinedProperties

StandardProperties

Specification Environment

Formal TestplannerFormal TestplannerProof KitsTemplates

™

RTLCode

DesignEnvironment


JasperGold Verification SystemJasperGold Verification System

Design Tunneling™Architecture Jasper Proof Accelerators™Jasper LosslessAbstractions™

Best Formal StandardLanguage Support

Multiple ParallelProof Engines

Design Analyst

Advanced StaticDebugging

Jasper FormalScoreboard™

JasperGoldJasperGold Verification SystemVerification System

Design Tunneling™Architecture Jasper Proof Accelerators™Jasper LosslessAbstractions™



Design Analyst


Jasper FormalScoreboard™

asper oasper o xpress er ca on ys emxpress er ca on ys em



Design Analyst


Push ButtonEase-of-Use


36/37

Demo Design - Block DiagramDemo Design - Block Diagram

IngressPort 0

Arbiter

Ingress

wr addr/datard addr/data

wr ctrl

rd ctrl

bridgeready

wr ctrl &addr/data

rd ctrl &addr/data


Bridge

IngressPort 2

IngressPort 3

EgressPort 1

Port-select

wr addr/data

rd addr/data

wr ctrl

rd ctrl

selected port


37/37

jasper lecture

Documents