Get email delivery of the Cadence blog featured here
Ever since Assertion-Driven Simulation (ADS) became available, I have been working with customers to integrate ADS into their standard design and verification flow. Below are some true stories from my direct experience with ADS out in the wilds of Silicon Valley.
The very first use mode I helped a customer to put together is what I call "Integration Bring Up". This flow is very applicable to designs with standard interfaces, and/or if you already have done significant module level formal verification such that you can reuse the existing interface constraints. (Of course, if the interfaces are in Cadence's Verification IP catalog, you can save even more time with this off-the-shelf solution.) In this specific customer case, they were designing a brand new, fairly large IP block -- a bridge with DDR on one side and standard AXI on the other.
While the DV team worked on bringing up the simulation environment (a process that wound up taking months), in parallel we brought this IP block up in Incisive Enterprise Verifier (IEV). For the AXI side of the bridge, we used the Cadence AXI Assertion Based Verification IP. For the DDR interface, we left it free running because for DDR slaves the timing of data sampling of data is fixed; and thus there is really no control needed. Hence, the constraint setup for this test case was very minimal. As noted above, this block was quite large in size, so we fully expected that pure formal would probably struggle with proof convergence. Instead, we applied the ADS methodology with IEV, using both simulation and formal engines simultaneously. We used random seeds, and ran ADS for hundreds and thousands of cycles depending on the specific constraint set. Bottom-line: in a short window of two months (well before the pure simulation testbench output its first test vector) we found over 30 integration level design bugs.
Another effective ADS use case is what I call "Constraint Development Aid". In the pure formal world, it is standard practice to debug constraints through debugging assertion failures. As such, the time spent on constraint development can start to add up quickly -- often requiring several iterations of debugging and tweaking. However, with ADS we have a new tool to help us to both debug and also visualize our constraints. As I'll explain momentarily, this combination has proven to be very powerful and efficient when it comes to constraint development.
The next real world story begins with a customer developing a packet oriented design. We put together a series of constraints, and then ran ADS in IEV. Looking at the waveform output by ADS, we discovered that after a certain number of transactions, all the buses started to hold steady with no more transactions coming in. We tried a couple different seeds and saw the same behavior in all waveforms. At that point, we knew we either had a constraint problem, or there was a bug causing the design itself to lock up. Hence, we zoomed into the very end of the traces where the buses start to hold steady and debugged the waveform outward from there. It turned out that given the value of the buses, to satisfy all the constraints IEV's engines would have to hold all the buses stable. That's why there is no more traffic coming in afterwards, and thus we instantly realized that we had issues in our constraint implementation. We fixed our constraints and verified that our traffic in ADS waveform ran nonstop before we moved onto prove our assertions.
In a related note: such "dead ends" are not uncommon in the process of constraint development. As described in detail in a prior post by my colleague Vinaya Singh, most dead ends are caused by constraint problems. In my experience, in almost in every deployment of ADS we have identified constraint problems through dead end debugging. And in roughly 50% of the time, the constraint issues would have been very tricky and/or time consuming to unearth with pure formal alone.
In summary, based on dozens of real world experiences with a wide variety of customers and design styles, I can say that ADS is one of the great tools a D&V engineer can have in their toolbox. I've sen with my own eyes how it can rapidly bring-up blocks without any conventional testbench at all, and save a lot of time & pain developing constraint sets. Leverage it whenever you can, and enjoy verification!
Bin JuSr. Application EngineerSilicon Valley, Californiafor Team Verify
On Twitter: http://twitter.com/teamverify, @teamverify
P.S. I'd also love to hear how YOU have leveraged ADS, and/or to see if your experiences have been similar to mine - please comment below!
Reference Links:Brief review of Assertion-Driven Simulation (ADS)
Me presenting at the recent Club Formal San Jose on the rapid bring-up methodology enabled by ADS