Download presentation

Presentation is loading. Please wait.

Published byTaliyah Drown Modified over 2 years ago

1
Cut Points On Steroids: Handling Complexity for FPV Erik Seligman CS 510, Lecture 12, February 2009

2
Agenda Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

3
Agenda Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

4
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

5
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?

6
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

7
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

8
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

9
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)

10
Agenda Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

11
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

12
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

13
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

14
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

15
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 assertions with one assertion that covers all cases Warning: may reduce simulation coverage –Simulator just checks sample value

16
Free Variable Example parameter CONTROL_RING = 357; generate for (i=0;i

17
Free Variable Example parameter CONTROL_RING = 357; generate for (i=0;i

18
Agenda Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

19
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

20
Is All Logic Needed For Proof? P1: assert property (o1 |-> !o2); P2: assert property (!o2 |-> o3); P3: assert property (o4 |-> (!i3 | !i4));

21
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

22
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

23
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!

24
Agenda Basic FPV Complexity Handling Design Abstraction The FPV Frontier Intelligent Pruning

25
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

26
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

27
‘Free’ Example free n1 // Now P1: assert property (o1 |-> !o2); is provable

28
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

29
Blackbox Example blackbox submod; // Can we prove P2: assert property (!o2 |-> o3); now?

30
‘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

31
Blackbox With Include blackbox submod; include n1; // Can we prove P2: assert property (!o2 |-> o3); now?

32
Advanced Pruning Directives Level Include only levels of logic preceding each node in property Can override with include Siglevel Include levels of logic preceding designated signal These are shortcuts Could replicate with lots of frees Again, not directly in JG, but doable with scripts

33
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

34
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

35
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?

36
Manual Pruning Step 2 level 1; include n1; // Now we can prove P2: assert property (!o2 |-> o3);

37
References / Further Reading vlsi08.pdf vlsi08.pdf

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google