1 / 35

Optimal Constraint-Preserving Netlist Simplification

Jason Baumgartner 1 , Hari Mony 1,2 , Adnan Aziz 2 IBM Corporation 1 Dept of ECE, University of Texas at Austin 2. Optimal Constraint-Preserving Netlist Simplification. Outline. Introduction to Constraints Modeling Design Environments Constraint Semantics

wcrook
Download Presentation

Optimal Constraint-Preserving Netlist Simplification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related