Cut Points On Steroids: Handling Complexity for FPV

Erik Seligman

CS 510, Lecture 12, February 2009

Agenda

Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

Agenda

Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

Complexity in FPV

Complexity shows up in several ways• FPV never terminates

• FPV runs out of memory

• Bounded proof, but to bad bound

Much more likely than in FEV• Sequential analysis is more complicated

• Abstract properties may be hard to prove

• Some subset of desired proofs likely hard

Initial Things To Look At

Is proof bound less than expected?• Add cover points to try to justify bound

• Maybe it’s OK after all!

Are better engines available?• Most FPV tools have multiple engines

• Engines tuned for design characteristics– Datapatch or control?

– Arithmetic logic?

– Liveness assertions?

Run At Lower Hierarchy?

Maybe tried to swallow too much logic Tradeoff: may need more assumptions

• Need to examine ROI at lower level

Remember this example?

MPE0

MRA1

MRA0

MPE1

MSB

Case Splitting Large parts of logic operate separately?

• Modes: PCIE 4x/8x/16x

• Opcodes: ADD, MULT, …

Set control bits to constants, verify one• Same technique used in FEV

Often more important for FPV than FEV• Don’t stop at flops interactions more likely

Without case splitting, FPV effectively verifying multiple sub-machines at once• Potential exponential blowup

Property Simplification

Is a property overly complex?• Maybe can replace with 2+ simple ones

• Might be easier for FPV tools

• Maybe one of simplified asserts is provable– Or one easily reveals a bug!

Examples• A |-> B && C

• A ##1 B |-> C ##1 D

Property Simplification

Is a property overly complex?• Maybe can replace with 2+ simple ones

• Might be easier for FPV tools

• Maybe one of simplified asserts is provable– Or one easily revelas a bug!

Examples• A |-> B && C

– (A |-> B) , (A |-> C)

• A ##1 B |-> C ##1 D– (A ##1 B |-> C), (A ##1 B |=> D)

Agenda

Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

Design Abstraction

Think about ways to simplify design• Are there repeated, identical blocks?

• Do size of data structures & buses matter?

• Are complex pieces of logic really used?

Simplify model for FPV• Keep RTL parameterized to enable

– Avoid hard-coded ‘mybus[31:0]’, etc

• Can some structures be ignored?

• Be careful: potentially losing some coverage

May benefit from using free variables

Basic Abstraction

Look for large/repeated elements• Queues, arrays, buses

Can size be reduced for FPV?• Smaller queue, buses, etc.

• Does full size really matter, or is logic repeated?

No need to re-verify repeated logic• Many instances of identical module?

– Blackbox all but one for FPV

Ignoring Extra Logic

Recall memory controller from Lecture 10• Read After Write hazard computation

– Examined 64-bit address bus

• Assertions weren’t testing RAW computation– Were testing controller’s reaction to it

– Didn’t matter if computation was accurate

Compute RAW Controller with

assertions

Ignoring Extra Logic Recall memory controller from Lecture 10

• Read After Write hazard computation– Examined 64-bit address bus

• Assertions weren’t testing RAW computation– Were testing controller’s reaction to it

– Didn’t matter if computation was accurate

Cut & replace RAW bit with free input• Risks…?

Compute RAW Controller with

assertions

General Free Variables

Cutting logic introduces a free variable• FPV assumes any value at any time

• May need related assumptions

Free vars can make assertion general• Helpful for some FPV engines

• Replace <n> assertions with one assertion that covers all cases

• Warning: may reduce simulation coverage– Simulator just checks sample value

Free Variable Example

parameter CONTROL_RING = 357;generate for (i=0;i<CONTROL_RING; i++) begin

ring_elt r1(clk,ff[i],ff[i+1],stuff)

endendgenerate

// Original assert, no free variablemodule r1(clk,cur_ff,nxt_ff,stuff);…a1: assert property (p1(clk,cur_ff,nxt_ff,stuff))

Free Variable Exampleparameter CONTROL_RING = 357;generate for (i=0;i<CONTROL_RING; i++) begin

ring_elt r1(clk,ff[i],ff[i+1],stuff)

endendgenerate

// int test_bit added as top-level inputassm: assume property (##1 $stable(test_bit));

a1: assert property (p1(clk,ff[test_bit],ff[test_bit+1],

stuff));

Agenda

Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

FPV Analysis Frontier

FPV doesn’t examine all logic at first• True of most engines

• Helps reduce complexity issues

Look from property back to ‘frontier’• If you can prove with subset of logic, good!

• If false on subset, maybe need more logic– Generate partial cex

Many asserts provable with partial logic• But partial cex means more work needed

Is All Logic Needed For Proof?

P1: assert property (o1 |-> !o2);

P2: assert property (!o2 |-> o3);

P3: assert property (o4 |-> (!i3 | !i4));

Attempt #1: Cut Most Logic

P1: assert property (o1 |-> !o2); Proven!

P2: assert property (!o2 |-> o3); False: o2=0, n1=0

P3: assert property (o4 |-> (!i3 | !i4)); False: o4=1, i3=i4=1

Attempt #2: Expand Frontier

P1: assert property (o1 |-> !o2); already proven

P2: assert property (!o2 |-> o3); Proven!

P3: assert property (o4 |-> (!i3 | !i4)); False: o4=i3=i4=1

Attempt #3: Full Logic

P1: assert property (o1 |-> !o2); already proven

P2: assert property (!o2 |-> o3); already proven

P3: assert property (o4 |-> (!i3 | !i4)); Proven!

Agenda

Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

Consequences Of Frontier

Tools begin by examining partial logic Opportunity for user: provide hints

• Directed pruning of logic not needed

• Include logic known to be important Pruning is key to complex FPV

• Designer often knows best

• Makes FPV possible on blocks way too large for automated run

• Be careful– CEXs are suspicious – Unless all constraints known on pruned nodes

Pruning Directive: Free

Free an internal node• Treat as primary input, can get any value

Simplest pruning directive• Very precise : aimed at single node

Free is called ‘stop_at’ in Jasper

‘Free’ Example

• free n1

• // Now P1: assert property (o1 |-> !o2); is provable

Pruning Directive: Blackbox

Blackboxing already seen in FEV Same basic concept: ignore submodule

• Blackbox inputs become primary outputs

• Blackbox outputs become free inputs

Same constraint problem as in FEV• Really worse: no auto-cut at states like FEV

• So expect to see more of previous logic

Blackbox Example

blackbox submod;

// Can we prove P2: assert property (!o2 |-> o3); now?

‘Include’:Mitigating Blackbox

Blackbox is a powerful directive• Ignores all logic in module

Can we un-blackbox just what we need?• Some subset of logic may be relevant

• But still ignore most of submodule

Solution: ‘Include’ directive• Include fanin cone of designated bbox output

• Reverses bboxing for that cone

• Not directly in JG, but doable thru script

Blackbox With Include

blackbox submod;

include n1;

// Can we prove P2: assert property (!o2 |-> o3); now?

Advanced Pruning Directives

Level <n>• Include only <n> levels of logic preceding each node

in property

• Can override with include

Siglevel <sig> <n>• Include <n> levels of logic preceding designated

signal

These are shortcuts• Could replicate with lots of frees

• Again, not directly in JG, but doable with scripts

Manual Pruning: The Negative Method Start by trying to run full module FPV

• Maybe no complexity, then no problem

Next try simple solutions• Engines, hierarchy change, case splitting

Then examine for pruning opportunities• Good FPV tool may give partial-frontier CEX

• See what parts look relevant, vs what looks prunable

Manual Pruning: The Positive Method Start with low level pruning

• Eliminates most logic

• Get cex based on inputs to frontier

Then gradually include missing logic• Look at cex, figure out what’s suspicious

• Include logic (thru include/siglevel) to rule out suspicious cases

JG “design tunneling” aids in gui• Most tools require you do it manually

Manual Pruning Example

level 1;

// Try to prove P2: assert property (!o2 |-> o3);

// Get CEX: o2=0, n1=1, o3=0

// Looks suspicious: Can n1 really be 1 while o2 is 0?

Manual Pruning Step 2

level 1;

include n1;

// Now we can prove P2: assert property (!o2 |-> o3);

References / Further Reading

http://oskitech.com/papers/datta-mc-vlsi08.pdf