# Cut Points On Steroids: Handling Complexity for FPV

## Presentation on theme: "Cut Points On Steroids: Handling Complexity for FPV"— Presentation transcript:

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? MSB Maybe tried to swallow too much logic
Tradeoff: may need more assumptions Need to examine ROI at lower level Remember this example? MPE0 MRA0 MSB MPE1 MRA1

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

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 Compute RAW RAW bit Controller with assertions

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 RAW bit Controller with assertions Free Bit

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) end endgenerate // Original assert, no free variable module r1(clk,cur_ff,nxt_ff,stuff); a1: assert property (p1(clk,cur_ff,nxt_ff,stuff))

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) end endgenerate // int test_bit added as top-level input assm: 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
n1 i3 o3 n2 i4 o4 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 i1 o1 i2 o2 i3 o3 o4 i4
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 n1 i1 o1 i2 o2 i3 o3 o4 i4 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 i1 o1 i2 o2 i3 o3 o4 i4 Submod 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 i1 o1 i2 o2 n1 i3 o3 o4 i4 Submod
blackbox submod; include n1; // Can we prove P2: assert property (!o2 |-> o3); now?

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
o1 i2 o2 n1 i3 o3 i4 o4 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 i1 o1 i2 o2 n1 i3 o3 o4 i4 level 1; include n1;
// Now we can prove P2: assert property (!o2 |-> o3);