1. © 2006 Synopsys, Inc. (1) CONFIDENTIAL Simulation and Formal Verification: What is the Synergy? Carl Pixley Disclaimer: These opinions are mine alone and not necessarily Synopsys’. Also, I tend toward hyperbole. November 14, 2006

2. © 2006 Synopsys, Inc. (2) FV & SIM similarities FM must use assertions. SIM may (or may not) use assertions. Neither REQUIRES a golden model. Both are used to find bugs. For unit level both need environmental assumptions  SIM needs a testbench.  FM needs constraints or synthesizable model.

3. © 2006 Synopsys, Inc. (3) Constraint Based Verification (of course) Reuse constraints as environments for MC & generators for simulation Reuse constraints as assertions in both FV & simulation Enable assume/guarantee Specify protocols with assertions Use constraints as assumptions for Boolean Equivalence checking ….

4. © 2006 Synopsys, Inc. (4) SIM/FV Problems Too many languages  Why VHDL & Verilog?  Why SVA & PSL & OVA?  Why E and SysVerilog?  Why 12 versions of C for various purposes?  EDA venders spend HUGE amounts of $$$ supporting languages. Don’t look for vendors to fix this:  We do what our customers pay for, no matter how ridiculous.

5. © 2006 Synopsys, Inc. (5) Solution: My rules 1. Don’t propose a hardware design language unless you ALSO propose a tool to cost effectively compare it to what gets implemented on the chip.  That pretty much means formal modeling and synthesis. 2. Don’t propose a language unless it can be used for formal analysis.  Case in point: Testbench languages

6. © 2006 Synopsys, Inc. (6) Synthesizable TB Synthesizable testbenches are possible! They are needed for a true SIM/FM synergy. FV needs formal model of design – pretty much synthesizable in the usual sense. Emulation could use Synthesizable TB also.  Put everything on the emulation box and let ‘er rip.

7. © 2006 Synopsys, Inc. (7) HL Design – Why?  Models in C are needed for software development and for showing IC development progress to customers.  Time to market Less code Simulation is faster and hence can be more comprehensive Transaction level is better for architectural decisions RTL has many implementation details in it making it irrelevant for many HL decisions.  Software can be run on software models of a design, e.g., Virtio and others

8. © 2006 Synopsys, Inc. (8) HL Design – Huge Research Opportunities Model Checking at the transaction level  Increased capacity?  Better environmental information? Equivalence verification to RTL Leverage SW checking techniques Coverage opportunities ….

9. © 2006 Synopsys, Inc. (9) Summary Constraint Based Verification Verifiable design languages Synthesizable Test Benches HL opportunities

10. © 2006 Synopsys, Inc. (10) Puzzle of the Month Fact 1: Verification accounts for 50% to 70% of the design resources (time, people, compute) on many chip projects. Fact 2: Verification tools make only a fraction of revenue compared with implementation tools (e.g., synthesis, place and route, DFM, etc.) in EDA.  FORMAL verification tools (including logic checking) make a VERY small fraction. WHY?

11. © 2006 Synopsys, Inc. (11) Backup slides