Transcript slides

Optimal Constraint-Preserving Netlist
Simplification
Jason Baumgartner1, Hari Mony1,2, Adnan Aziz2
IBM Corporation1
Dept of ECE, University of Texas at Austin2
March 2008
Outline
Introduction to Constraints
 Modeling Design Environments
 Constraint Semantics
Redundancy Removal under Constraints
 Constraint Pitfalls
 Redundancy Identification Challenges
 Redundancy Removal Challenges
 Optimal Redundancy Removal
Simulation under Constraints
Conclusion
2
Outline
Introduction to Constraints
 Modeling Design Environments
 Constraint Semantics
Redundancy Removal under Constraints
 Constraint Pitfalls
 Redundancy Identification Challenges
 Redundancy Removal Challenges
 Optimal Redundancy Removal
Simulation under Constraints
Conclusion
3
Modeling Design Environments
 Constraints: environmental assumptions to prevent illegal input scenarios

Assumptions in assume-guarantee reasoning
 Most verification efforts require some form of assumptions
4

Functional verification: inputs adhere to documented protocol
•
An input vector must be one-hot
•
Instructions not transferred if instruction buffer is full

Sequential Equivalence checking:
•
Self-test disabled; clocks driven consistently
Modeling Design Environments
 Two fundamental mechanisms to specify assumptions
1. Imperative generator-based approaches

Input filters are synthesized, composed with design
2. Declarative constraint-based approaches

Utilize language-specific constructs
•
constraint in SystemVerilog; assume in PSL
“Generator-Based Verification” ICCAD03
5
Modeling Design Environments
 Declarative approaches are popular
 Simpler to specify; easy to update

Enables the checker-assumption duality paradigm

Used for case-splitting to decompose complex verification tasks
•
Constraints may generally refer to design inputs, internals, outputs
“Decomposing Refinement Proofs using Assume-Guarantee Reasoning” ICCAD00
6
Outline
Introduction to Constraints
 Modeling Design Environments
 Constraint Semantics
Redundancy Removal under Constraints
 Constraint Pitfalls
 Redundancy Identification Challenges
 Redundancy Removal Challenges
 Optimal Redundancy Removal
Simulation under Constraints
Conclusion
7
Constraint Semantics
 Verification problem: Netlist with DUT, environment, assertions
 Constraint: specially-labelled gate that must evaluate to 1 in every state
explored by the verification tool


Though without special labelling, may evaluate to 0 or 1
Unlike SDC invariants, constraints thus prune traces
 Asymmetry between invariants, constraints is an intricate topic


8
Invariants: redundant gates
•
Useful only to tighten over-approximate analysis
Constraints appear redundant, though if removed they no longer hold!
Outline
Introduction to Constraints
 Modeling Design Environments
 Constraint Semantics
Redundancy Removal under Constraints
 Constraint Pitfalls
 Redundancy Identification Challenges
 Redundancy Removal Challenges
 Optimal Redundancy Removal
Simulation under Constraints
Conclusion
9
Redundancy Removal under Constraints
 Redundancy removal benefits many tasks
 Essential for sequential equivalence checking
 Enhances property checking
 Constraints have a big impact on redundancy removal
1. Constraints prune reachable states => more redundancy


Imposes a don’t care condition
Need to be exploited for optimality
2. Merging redundant gates may weaken constraint evaluation

10
Constraint-enhanced redundancy removal could lead to overapproximation
Outline
Introduction to Constraints
 Modeling Design Environments
 Constraint Semantics
Redundancy Removal under Constraints
 Constraint Pitfalls
 Redundancy Identification Challenges
 Redundancy Removal Challenges
 Optimal Redundancy Removal
Simulation under Constraints
Conclusion
11
Constraint Pitfalls
12
Constraint pitfalls
 Simplify logic outside constraint fanin using power of constraints
 Valid to simplify constraint fanin if not using its constraining power

E.g., using SDCs alone, and/or other constraints
 Disable simplification in constraint fanin if using power of constraints


13
Constraint cones can be fairly large
Arbitrarily suboptimal for subsequent verification?
Outline
Introduction to Constraints
 Modeling Design Environments
 Constraint Semantics
Redundancy Removal under Constraints
 Constraint Pitfalls
 Redundancy Identification Challenges
 Redundancy Removal Challenges
 Optimal Redundancy Removal
Simulation under Constraints
Conclusion
14
Assume-then-Prove Redundancy Identification
1. Guess redundancy candidates
2. Create speculatively-reduced model
=0?
=0?
A
A
B
B
Miter without spec reduction
Miter with spec reduction
3. Attempt to prove suspected equivalence on reduced design
4. If successful, exit with reduced model
5. Else refine unprovable redundancy candidates, goto step 2
Spec-reduction: Key to scalability; enables orders of magnitude speedup
15
Redundancy Identification under Constraints
 Spec reduction: Key to scalability of redundancy identification
 Spec reduction may weaken constraint evaluation

Causes sub-optimal redundancy identification
 Validity of candidates unknown during spec-reduction



16
May strengthen constraint evaluation, discarding reachable states
Unsound redundancy identification
Similar to soundness issues in circular reasoning in assume-guarantee
paradigm [HQR00]
Redundancy Identification under Constraints




17
Replicate the combinational fanin of each constraint
Re-label the replicated gates as constraints
Restrict equivalence classing, spec merging to original gates
Run typical assume-then-prove framework using this model
Outline
Introduction to Constraints
 Modeling Design Environments
 Constraint Semantics
Redundancy Removal under Constraints
 Constraint Pitfalls
 Redundancy Identification Challenges
 Redundancy Removal Challenges
 Optimal Redundancy Removal
Simulation under Constraints
Conclusion
18
Redundancy Removal under Constraints
 Once all redundancy is identified, how may we leverage it?
 Theorem: Merging of redundant gates sound, but maybe incomplete

Behaviour may be altered in constraint-violating states

Unreachable states may become reachable
 Theorem: Merging sound and complete if merged-from gate not in
combinational fanin of constraints



19
Constraint valuation in reset state unchanged
Merges cannot alter next-state; time I + 1 valuation unchanged
What about the rest?
Redundancy Removal under Constraints
 Can we further simplify given known equivalences in the combinational
fanin of constraints?
 Yes: using an abstraction-refinement framework
1.
2.
3.
4.
5.
6.
20
Merge all equivalent gates
Verify resulting simplified design
If proof is computed, exit with this result
If counterexample is obtained, validate on original design
If consistent, exit with this result
Else refine abstraction; goto step 2
Outline
Introduction to Constraints
 Modeling Design Environments
 Constraint Semantics
Redundancy Removal under Constraints
 Constraint Pitfalls
 Redundancy Identification Challenges
 Redundancy Removal Challenges
 Optimal Redundancy Removal
Simulation under Constraints
Conclusion
21
Optimal Redundancy Removal under Constraints
 Refinement algo w.r.t. counterexample p
1. Identify set of merged gates whose behaviour was altered in p
2. In place of each merge of step 1, inject a conditional merge

A mux selected by an auxiliary variable, which drives either the original
or merged value
3. Cast a max-SAT problem to see how many merges may be
preserved while avoiding a counterexample under p

22
The rest will be eliminated upon refinement
Optimal Redundancy Removal under Constraints
 Refinement procedure is optimal w.r.t. single iteration
 Suboptimality may occur across iterations due to compatibility issues,
non-uniqueness of max-SAT solution
 Solution: refine w.r.t. original maximally-merged design using all
counterexamples, vs. refining w.r.t. prior refinement

23
Incremental max-SAT instance can take into account all spurious behaviours
to be eliminated
Redundancy Removal Results
Design Info
Name
Gates
Constraint-Safe Merging (Mo05)
Constraint-Enhanced Merging
Tgts
Gates
Merged
Unsolved
Tgts
Resource
(s: MB)
Gates
Merged
Refined
Merges
Improv
.
Resource
(s : MB)
FPU
115037
1
2022
1
5465: 690
4928
0
143.7
%
1140: 384
IBUFF
19230
303
222
14
77: 91
831
20
260.8
%
144: 160
IBM_FV
24
13391
1
313
0
70: 119
793
7
151.1
%
83: 137
 IBM formal / semi-formal toolset SixthSense
 Constraint-Safe Merging: No merging in constraint fanin using power
of constraints
 Constraint-enhanced merging solves every target
 Enables 2X merges
24
Outline
Introduction to Constraints
 Modeling Design Environments
 Constraint Semantics
Redundancy Removal under Constraints
 Constraint Pitfalls
 Redundancy Identification Challenges
 Redundancy Removal Challenges
 Optimal Redundancy Removal
Simulation under Constraints
Conclusion
25
Simulation under Constraints
 Sequential constraints can result in dead-end states


States for which no valuation to inputs will satisfy constraints
E.g., is_instr_buffer_full checks if instruction buffer is full

Consider (not is_instr_buffer_full) as a constraint

State with instruction buffer filled is a dead-end state
 Dead-end states complicate simulation


If encountered, simulation must backtrack
Sequential constraints readily expressible; less manual effort
 Simulation is critical for various algos


26
Semi-formal bug-hunting
Obtaining simulation signatures for forming initial equiv-class candidates
Simulation under Constraints
 With dead-end states need look-ahead based SAT-solving
 At every time-step i of sim, solve constraints for i,…,i+k
27
Simulation under Constraints
 Min input delay: earliest time any input can affect constraint valuation
 Max input delay: the earliest all inputs has affected the valuation
 Windowed log-2 search between min and max delays
 SimGen [YPA 99] fails with 57 cycles
 Windowed search ~400X than pure SAT-based solution
28
Conclusion
 Constraints may increase reduction potential
 Care must be taken to ensure that identified redundancy is optimal and correct
 Once identified, some merges may be safely performed; others may entail
spurious failures
• Similarities & differences with constraints vs. invariants
 Optimal abstraction-refinement procedure presented
 Enables maximal merging
 Sound and complete verification procedure
29
Backup Slides…
30
Aside: Constraints vs. ODCs
 Possible to emulate constraints by adding ODC condition on properties
 Though doing so is computationally unattractive: lose corresponding
unreachability invariants
31
Sequential Constraint Challenges





32
Only Valid instructions with legal opcodes at Execute
Add constraint illegal opcodes => invalid instr
Fetch and Decode ensures that invalid instr => illegal opcode
Redundant gates: valid and illegal are complements
Merging valid and illegal weakens the constraint
Constraint Pitfalls
 Redundancy removal, if enhanced by constraints, may entail
overapproximation in subsequent verification
 We could preserve constraint cone (disable merging therein)
•
•
33
Though doing so may be arbitrarily suboptimal for subsequent verification
To what extent can we safely optimize constraint cones?
Redundancy Identification under Constraints
 Consider that we have identified a set of gate pairs that are equivalent in
the constrained reachable states
 Theorem: Merging any set of equivalent gate pairs is sound and
incomplete, if the merged-from gates are not in the combinational fanin of
constraints
34

Time-0 constraint evaluation is unchanged by such merges

Since merged gates are equivalent, cannot alter next-state function
evaluation; time i+1 constraint evaluation unchanged by the merges
Redundancy Identification under Constraints
 Theorem enables a modification of assume-then-prove framework to
identify every equivalent gate

1.
2.
3.
4.
35
Key idea: miter assertability for incorrect candidates is strictly preserved
Replicate the combinational fanin of each constraint
Re-label the replicated gates as constraints
Restrict equivalence classing, spec merging to original gates
Run typical assume-then-prove framework using this model