Optimal Constraint-Preserving Netlist Simplification

1. Jason Baumgartner1, Hari Mony1,2, Adnan Aziz2 IBM Corporation1 Dept of ECE, University of Texas at Austin2 Optimal Constraint-Preserving Netlist Simplification

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. 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

4. Modeling Design Environments • Constraints: environmental assumptions to prevent illegal input scenarios • Assumptions in assume-guarantee reasoning • Most verification efforts require some form of assumptions • 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

5. Modeling Design Environments • Two fundamental mechanisms to specify assumptions • Imperative generator-based approaches • Input filters are synthesized, composed with design • Declarative constraint-based approaches • Utilize language-specific constructs • constraint in SystemVerilog; assume in PSL “Generator-Based Verification” ICCAD03

6. 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

7. 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

8. 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 • Invariants: redundant gates • Useful only to tighten over-approximate analysis • Constraints appear redundant, though if removed they no longer hold!

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

10. 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 • Constraints prune reachable states => more redundancy • Imposes a don’t care condition • Need to be exploited for optimality • Merging redundant gates may weaken constraint evaluation • Constraint-enhanced redundancy removal could lead to overapproximation

11. 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

12. Constraint Pitfalls

13. 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 • Constraint cones can be fairly large • Arbitrarily suboptimal for subsequent verification?

14. 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

15. =0? =0? A A B B Miter with spec reduction Miter without spec reduction Assume-then-Prove Redundancy Identification • Guess redundancy candidates • Create speculatively-reduced model • Attempt to prove suspected equivalence on reduced design • If successful, exit with reduced model • Else refine unprovable redundancy candidates, goto step 2 Spec-reduction: Key to scalability; enables orders of magnitude speedup

16. 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 • May strengthen constraint evaluation, discarding reachable states • Unsound redundancy identification • Similar to soundness issues in circular reasoning in assume-guarantee paradigm [HQR00]

17. Redundancy Identification under Constraints • 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

18. 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

19. 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 • Constraint valuation in reset state unchanged • Merges cannot alter next-state; time I + 1 valuation unchanged • What about the rest?

20. Redundancy Removal under Constraints • Can we further simplify given known equivalences in the combinational fanin of constraints? • Yes: using an abstraction-refinement framework • 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

21. 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

22. Optimal Redundancy Removal under Constraints • Refinement algo w.r.t. counterexample p • Identify set of merged gates whose behaviour was altered in p • 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 • Cast a max-SAT problem to see how many merges may be preserved while avoiding a counterexample under p • The rest will be eliminated upon refinement

23. 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 • Incremental max-SAT instance can take into account all spurious behaviours to be eliminated

24. Redundancy Removal Results • 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

25. 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

26. 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 • Semi-formal bug-hunting • Obtaining simulation signatures for forming initial equiv-class candidates

27. 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

28. 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

29. 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

30. Backup Slides…

31. Aside: Constraints vs. ODCs • Possible to emulate constraints by adding ODC condition on properties • Though doing so is computationally unattractive: lose corresponding unreachability invariants

32. Sequential Constraint Challenges • 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

33. Constraint Pitfalls • Redundancy removal, if enhanced by constraints, may entail overapproximation in subsequent verification • We could preserve constraint cone (disable merging therein) • Though doing so may be arbitrarily suboptimal for subsequent verification • To what extent can we safely optimize constraint cones?

34. 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 • 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

35. Redundancy Identification under Constraints • Theorem enables a modification of assume-then-prove framework to identify every equivalent gate • 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