At the recent Jasper User Group, I said that there were several themes. For overall coverage of the event, see my post Jasper User Group 2018 . One was post-silicon debug, which I wrote about in the post Formal Post-Silicon Debug . Another theme was transitioning formal from pure RTL verification towards formal signoff. That is the topic of this post. Broadcom Khurram Ghani from Broadcom was the most direct about formal signoff, and presented Replacing Simulation with Formal for Block-Level Signoff: A Case Study . His group took a project and developed a strategy for formal signoff and then used it on a real block. Of course, they were not doing this from a standing start, they already had extensive experience with formal, and this was the natural next step. They picked a block called Alderaan (not its real code-name) where the existing simulation test suite was poor, and the RTL was getting unwieldy. To make it worse, there were significant spec changes at the start of the project, too. But this made it a natural choice for the project since they would have to re-write both the RTL and the verification. They bit the bullet and planned to verify completely in formal without a single planned simulation at the block level (although they kept simulation for integration testing at the chip-level). Alderaan was a networking packet router (think Ethernet). It had a 64b interface with another block Hoth, with handshake and flow-control protocols, multiple streams, pointer management, etc. A serious block, not any sort of "toy" test. There were two main block milestones: feature complete, meaning all the RTL coded, all properties coded and none failing. Then the closure milestone for signoff, with both simulation and formal coverage. Run management turned out to be a challenge, with 172 tasks due to functional splitting etc, and multiple properties per task (63K in all!), along with the usual real-world constraint of limited queue and license resources. Everything was tracked and reported via Cadence vManager. Above shows the methodology for closure. The block naturally falls into two main parts, the receive database and the transmit datapath. Khurram went into a lot of detail on some of the things they did to get proof coverage. I'm going to skip to their results. This was approximately a 1-year project and they delivered to plan. Most RTL time was spent on feature-complete activity. Most verification time was spent on closure activity. They were doing this for the first time, so there was both a learning curve and new technology to be developed. The receive datapath was closed, but they didn't complete the bounded proof closure on the transmit datapath for various reasons, including difficulty in assessing complexity and determining which abstractions to apply. The benefits of this approach were: Close cooperation between RTL and verification, resulting in quicker debug turnround, and earlier discover of corner case RTL bugs (formal's sweet spot and simulation's weakness). Integration simulation test: zero functional bugs found, some performance concerns but none that required fixes. The number of "formal-literate" people grew, and they now have methodology etc. They are using this on a new block Yavin which will be verified completely in formal. Perhaps the best recommendation to the approach came from one of the Alderaan RTL designers: I'm dreading going back to simulations! ST Microelectronics Mirella Negro Marcigaglia of ST's microcontroller division presented Static and Dynamic Verification: Interoperability in Digital IP Verification . She covered more than just formal signoff. One of their focuses was to move towards a formal-only IP verification strategy. She estimated that they saved 30-40% of time versus simulation with this JasperGold-based flow. She admitted it wasn't appropriate to all blocks. The best candidates were control blocks with small sequential depth, and data transfer blocks with limited data manipulation. They could then use either end-to-end checkers or a white-box approach depending on the IP complexity. She covered a lot more detail on combining dynamic verification (simulation) but in a formal-first environment. The focus for simulation was on re-using assertions from formal, combining coverage, and adding more randomness (random hardware configuration, for example). Samsung Junhyuk (John) Park of Samsung presented From Apps to Signoff: Advancing Usage of Formal Verification . He started with a taxonomy of designs, splitting them into designs suitable for bug-hunting, and designs suitable for signoff. The diagram below shows the various dimensions: He discussed a specific project for a peripheral DMA controller (PDMA). They ran this project with formal signoff in parallel with simulation so they could do ROI comparison. The plan was to do signoff of the main data transfer functionality and arbitration among channels. They actually achieved 100% functional coverage, catching 16 design bugs along the way. They reduced the design from 12 channels to 4 since they were repeated instances of the same module: any problem in 12 would also show up in 4. But there was one bug missed that was found only in simulation, where it was detected by a timeout. This type of bug, which shows up a huge number of cycles later, is a weak spot for formal. It requires better deadlock detection than is in current formal tools. John's final conclusions were: Formal sign-off methodology Establishes criteria for verification closure even though full proof is not obtainable Provides the technologies to achieve it, which makes Formal verification measurable Important to select amenable design at the initial phase Formal sign-off can replace simulation verification effectively for formal friendly design For a complex design, formal can be used as bug-hunting for critical sub block Conclusion Three companies doing formal signoff in different circumstances. I guess that the conclusion would be that for the right kind of block, this is just about possible. Where it is possible, the ROI is better than simulation, at least once the original learning curve and methodology creation is complete. However, there are still some limitations on what type of block is "formal-signoff-friendly". Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
↧