Who wrote the book on formal verification? Depending on whether you want to take the question literally or metaphorically, the answer is either Intel's Erik Seligman or Cadence's Jasper product group. Oz Levia As usual, Oz got things rolling. He pointed out that this is the ninth JUG meeting and the third since Jasper became part of Cadence. I've been to five or six meetings since Jasper was one of the companies that I covered at SemiWiki before I joined Cadence. Oz pointed out that this is the world's biggest gathering of commercial formal verification users. In fact, during lunch I was talking to some engineers from Intel and NVIDIA and they said that it is like a reunion of all of the people who have been working with formal verification for years, before it became mainstream. One actual announcement was that the Jasper Expert System is now ready for deployment and will ship automatically with all copies of JGINT from 2016.12 onwards. Oz went for the analogy of the day, comparing formal to yoga. It's not the solution to everything...but there are some things where it is the best. Hmm, "downward dog" even sounds like a difficult formal proof approach. Oz listed the companies that were presenting during the two days: ARM, Broadcom, Cavium, HPE, Huawei, NVIDIA, NXP, Samsung, ST, TI. And Intel, in the form of Erik Seligman talking about the book. Before anyone asked him, Oz swore that he had read it. Erik Seligman Erik Seligman is a formal verification architect at Intel in Oregon. Along with Tom Schubert and Achutha Kirin Kumar, he wrote the book "Formal Verification: An Essential Toolkit for Modern VLSI Design." When Erik first got involved with formal verification (FV), he looked for books, but there were only academic books aimed at people writing formal verification tools, not aimed at people trying to use formal verification in the real world. He thought back to escapes that nearly got through, and the common errors that people make. One of the most common errors made by newbies and experts alike is vacuity, setting impossible constraints that basically mean that any circuit will verify correctly. But there are lots of tricks, rules of thumb, and techniques that people who have been using FV for years have internalized. Since the book he wanted didn't exist, he decided to write it. He wanted something with more of a "hacker mentality" targeted to practicing verification engineers (and their management), not to people who want to understand the details of the algorithms inside the tools. A FV engineer has to have a variety of skills, from an astronomer to create abstract hypotheses, to bungee jumpers needing to create responsive proof systems. Ultimately, there are four big gaps that Erik was trying to address with the book: Perception: what is formal verification? Goals: when and why to use it Usage: how to use it Effectiveness: learn how to do it better All the academic books that he found were full mathematical theorems, so he had one other rule: No greek letters In the past, FV was regarded as something for specialists, that PhD in the corner who knows how to use it. But it is mainstream now, and should be part of everyone's toolkit, along with simulation and emulation. The idea that FV is an extra cost to a project, an extra safety net for the last mile, also needs to change. FV is not a cost. It saves resources, schedule, and money. In fact, at the keynote at DVCon Europe last month, Hobson Bullman of ARM pointed out that formal finds 35% of the bugs with just 11% of the CPU cycles. Erik thinks that the correct attitude is that FV is the right thing to do. Use FV when you can, and simulate where you must. It should be a "normal" part of any validation plan. He gave many practical tips: The first tip was that full formal rigor may not always be required. At some level, the "correct" thing to do is to put assumptions on the input and assertions on the output, since anything else risks masking errors. But sometimes the assumptions are just so difficult and can waste a lot of cycles. For example, if a block has serial data arriving, which it then decodes, then it may be a lot easier to put assumption on the decoded data. A lot of FV in practice is what Erik calls "wiggling": adding forgotten assumptions (such as telling the tool that the scan test control signal is not changing on every clock cycle), finding issues that are not real bugs. But finally you start to see design errors. It is not that different from bringing up a simulation environment. If the complexity explodes, and the tool runs out of memory, then novices may need to get some help. One bit of advice is to start with covers, not assertions, so that you can see signals and make sure that the circuit is being properly exercised and normal behavior is not being accidentally masked out. One area that gets forgotten is to plan to measure the return on investment. There is no single prescription but data is needed to justify the costs (licences and people) in terms of benefits (bugs found earlier, working RTL sooner, etc). In fact, he hopes that tools like JasperGold can start to provide some of this automatically. It's in Cadence's interest if users can easily justify more licenses, for obvious reasons. Erik was critical of Apps for making FV too easy. Users need to understand context and also recognize opportunities across flows. He told us not to "sell us Apps, but sell us a flexible user-extensible system." I think you need both, since Apps package up common tasks and make them accessible to non-experts. That is the way to convert non-users to users (and maybe, like Erik, to evangelists). Another area that can be problematic is merging coverage metrics from simulation and FV. The first thing is to realize that measuring coverage is necessary. Only in the most trivial cases does formal verification prove that everything in a design is working correctly under all circumstances. However, you can't just dump everything into a single coverage metric naïvely. He would like to see VIP extended from OVM, which is simulation only, to include formal too. Remember, Erik finished with, the bulk of engineering is wiggling. With wiggling and yoga poses, the opportunity for verification visuals are endless! Links for the book are at formalverificationbook.com and at Amazon . Erik is also has an occasional podcast called Math Mutation (and there is a book of the podcast, too). For more information about JasperGold and Cadence's formal solutions, start here . Previous: The Amazing Raspberry Pi Story![]()
![]()
↧