Four customer presentations at CDNLive! Silicon Valley, held Oct. 5-16, provided some valuable tips for users and prospective users of formal verification tools. The presenters included three users of Cadence Incisive Formal Verifier (IFV) and one user of the recently announced Incisive Enterprise Verifier (IEV). I came away from these presentations with some fresh perspectives on what it takes to be successful with formal verification, including the criteria listed below.
1. Choose the right problem
Formal verification can be a killer application if applied to the right block or chip. Chaitanya Kosaraju of Xilinx described his use of IFV to verify a multiplexed pad interface block. Due to the large number of input combinations, such a block would be very time-consuming to verify using a traditional simulation testbench. Using IFV, Kosaraju was able to verify in a month a block that would have taken 3-4 months using a testbench approach.
2. Use formal verification early
Balekudru Krishna of Chelsio Communications noted that his company has been very successful with “designer-centric” formal verification, where verification engineers and design engineers collaborate early in the design process. He presented a case study of IFV use with a datapath block in a page manager module, in which the goal was to start formal verification very early and complete an end-to-end verification of the module.
IEV provides a “dual power” interface between formal verification and simulation engines, allowing new capabilities such as property-driven simulation, formal-assisted simulation, and simulation-assisted formal analysis. One big win, said Ying Yu of Marvell, is the ability it gives designers to do some fairly extensive verification before a testbench is developed and deployed. She said IEV enabled a simulation bring-up time of three days for a memory controller module, a process that could have taken months with a traditional approach.
3. Have a plan
Yogesh Bhagwat of Cisco talked about his use of IFV as the primary verification tool for a DDR3 command buffer ASIC. His methodology started with the creation of a formal verification test plan. This plan identified subsets of modules suitable for formal verification, and identified interfaces for which assertions needed to be written. Subsequent steps include writing properties for requirements, writing constraints for inputs, and writing cover statements for monitoring coverage.
4. Design for formal verification
The Chelsio presentation cited a number of ways that designers can help make formal verification more successful. These include carefully partitioning the design with clear boundaries, using smaller logic cones, isolating modules that use FIFOs or require liveness guarantees, and being willing to re-partition the design if required for optimal use of formal verification. These are also good coding practices, Krishna noted.
5. Strategize to avoid convergence problems
Chelsio engineers ran into some state-space problems when trying to verify a page manager that managed 1,024 pages. They realized they only needed to evaluate states for one page at a time, and replaced a component of the module with a manual abstraction that served as a stub that maintained states for just one page. To boost proof convergence, they also kept datapath and control path circuitry independent, and took advantage of data type symmetry to create reduced instances of the design.
6. Use automated features when available
A key element of Xilinx’ success with the pad interface block was the use of the IFV Connectivity Package, which automatically generates assertions from a spreadsheet.
7. Keep attending CDNLive!
Well, nobody actually made this point during the above-mentioned presentations, but it seems to me that listening to customer experiences like these will be helpful to anyone involved in design or verification. CDNLive! papers will be available on-line to Cadence Community members within the next few weeks.
Richard Goering