Tired of spending all that time doing verification? Yeah, well, everyone is, so get in line for the “Can I Finally Be Done Verifying – PLEEEEZ??” window, where you can submit your coverage numbers and see whether you get a weekend or you get sent back to the lab for more verification.

Verification productivity has always been a hot topic, ever since it was figured out that you guys spend about 70% of your silicon efforts on making sure that the other 30% was done correctly. Mentor Graphics recently made a couple of announcements intended to provide some relief for the poor verifiers that desperately need to get home for a shower and some sleep.

Emulation Follows Formal

The first announcement had to do with emulation. Mentor’s narrative is that of four emulation eras, starting with in-circuit emulation (ICE), then on to acceleration, then virtualization (where everything moves to the data center for online access), and now to the application era.

While that’s a perfectly good story, I did notice yet another narrative – a parallel with formal technology – that provides a complementary angle. The idea behind the application era is that the technology behind emulation can be pushed into the background, overlaid with pre-produced control and visualization wrappers dedicated to a specific problem. By not requiring emulation expertise, this opens emulation up to many more verification engineers.

Why does this sound familiar? Well, if we think back to the history of formal verification, we see something that looks pretty much the same. Formal was a complex, obscure technology requiring one or more PhDs to enable use, and so the technology spent much time buried in the corner, requiring the assistance of experts. Mention formal verification to an average engineer in those days, and you might trigger pre-traumatic stress disorder.

These days, while you can still immerse yourself as deeply as you want in formal technology, there are now “canned” applications for things like clock domain crossings and don’t-care propagation. They convert formal from a verification technique to an enabling technology for solving specific verification problems, with the formal bits disguised by the app that takes care of the lower-level details.

Emulation has itself been somewhat specialized. It’s required its own setup; you have to figure out what portions of the testbench can be (or need to be) synthesized within the emulator; and you may need to change your stimulus (more on that in a moment). This isn’t bad in and of itself, but it can be fussy, and it’s certainly unlike plain-ol’ simulation.

Mentor released a power verification application last year, but at that point it was, as far as we could tell, a one-off. Turns out, in fact, that it was the bell-wether. This year they’ve announced several new applications, with the expectation that more are coming.

The first app in this year’s launch is what they call “Deterministic ICE.” ICE is about connecting external sources of data to ensure that a design works well in the presence of realistic traffic patterns – and what better way to test that than to connect it to actual traffic.

This works, but it’s fiddley (traffic generator speeds don’t match emulator speeds, so you need rate matchers in between), and, traditionally, you had to be in the lab to connect the traffic. Now that this is all in a data center in some other city or country or continent, that gets harder.

But even worse is the fact that the traffic is, for verification purposes, random and, most importantly, not repeatable. If your design stumbles on some traffic it sees, well, good luck replicating that problem, since that traffic is long gone and may or may not show up again within a reasonable timeframe. That makes debug a total nightmare. And if debug leaves you unsure whether you really understand the problem, then you also have no really good way to test your solution to see if you fixed the problem.

Their VirtuaLAB announcement a few years ago addressed this by providing networked traffic generators for some popular protocols. But not everything has a VirtuaLAB generator – in particular if you’re dealing with something proprietary.

So they’ve taken a page from the CodeLink book: you can use a non-deterministic traffic generator, but Veloce will record the session so that, if you run into a glitch (literally or otherwise), you have a record of the session for use in debugging. Now you can debug offline, handing the valuable Veloce hardware over to someone else, and, when you’ve corrected the problem, you can prove so by re-running the failing session – which should no longer fail.

The second app is used to verify DFT circuitry. Yes, the DFT stuff is automatically created and inserted at the gate level, but it apparently can’t be considered to be correct by construction and needs verification. Which, today, using gate-level simulation, takes so long that one typically doesn’t put it in the schedule’s critical path. You say a few prayers and tape out while the DFT testing is still underway.

The DFT emulation app accelerates this by thousands of times, enough to where it can be completed prior to tape-out. This could remove one of those things that are keeping you awake during those 3 AM mental self-flagellation sessions.

Finally, they have a FastPath app. This helps emulation to run faster by being more realistic about the design under test (DUT). As it stands, the maximum clock rate for emulation is figured out by looking for the longest paths and setting the frequency accordingly. But that ignores modes and multi-cycle paths (OK, you can label some of those, but not thousands), meaning that it’s possible that the design could go faster because that slow logic is static, but the emulator doesn’t know that.

FastPath lets the emulator know that bit. It exercises a model that can focus on what’s actually being used in the design, and, if all those paths are fast, then execution finishes that much more quickly.

Always a VIP

A more recent announcement had to do with verification IP (VIP). Just as a reminder, there are two fundamental types of IP: design IP, which will end up in your final circuit, and VIP, which you use to test your IP (whether home-grown or off-the-shelf). A key tenet here is that you don’t want to get your VIP from the guy that built the IP. If you did, you run the risk that errors in the IP will also be reflected in the VIP – meaning the VIP won’t detect the error.

Mentor no longer creates and sells design IP – they feel it competes with their customers who create and sell design IP. VIP is different, however. They say that all of the top-tier VIP companies have been bought and are now captive (although there are some second-tier folks remaining). The point being, that there aren’t really many (if any) VIP creators as customers to compete with. So they create and sell VIP.

Some time back, they announced EZ-VIP – a productivity tool that allows you to select models easily and quickly. In particular, you can swap models without having to recompile the design. The models can also be auto-configured – a step that can take a fair bit of time if done manually.

Further along those lines, they’ve announced numerous new memory models that join the many protocol models already in place (variants on AMBA, PCIe, Ethernet, USB, MIPI, serial, and display). 1600 of them, to be precise – DRAM and Flash, by part number and manufacturer. They announced a new Hyperbus model as well.

My discussion with them also included a couple of other projects that are underway. One is the “portable stimulus” effort happening within the Accellera organization. Mentor and Cadence have submitted SystemVerilog-oriented proposals, Breker has submitted a C++ proposal, and Vayavya has submitted ideas for generating registers, firmware, and drivers from interface descriptions.

The idea is to allow a single stimulus sequence to be re-used in different verification environments without needing a re-write. This means ensuring equivalent semantics wherever it’s used. There are discussions ongoing as to how declarative the syntax should be (Fully? Partially? Mostly?) and how the flow should look. They’re looking at an internal draft this May, with a final standard in January of next year.

One final other interesting effort is the verification operating system (VOS) project. The idea here is to make it easier and faster to run software on an emulator. While it is possible to load Linux (either through execution or possibly via a re-loaded snapshot of the system after Linux is loaded), any time saved is good in emulator-land.

So the idea here is to have a stripped-down OS that has only what’s needed to run the software stimulus. While the formal OS itself is de-featured, it is augmented with capabilities suitable for verification – like error handling.

So there you go. A number of things aiming to speed up verification. (Not that you’re ever going to get ahead or actually take that vacation you’ve been planning…)

More info:

Mentor emulation applications

Mentor VIP