One of the most-watched verification startups in recent years has been 0-In Design Automation, a provider of "white box" verification tools. The company released early versions of its tools two years ago, and then went into a period of extensive development, releasing its first production-ready tools earlier this year. Today 0-In is shipping 0-In Check, which allows you to embed checkers in your RTL or testbench, either one, and 0-In Search, which uses formal verification techniques to greatly expand the stimulus combinations that might cause these checkers to fire.
John Andrews, member of technical staff at Tensilica, is using both 0-In Check and 0-In Search on his company's configurable microprocessor cores. Here, he describes the respective benefits of these tools and some desired improvements.
EEdesign: With what designs are you using 0-In products?
Andrews: We're just transitioning to production mode right now. I'm using 0-In to verify some new designs I'm working on I can't tell you too much about them. We used 0-In on our current configurable microprocessor core, which can vary in size from 30K to 150K gates.
EEdesign: Do your chips pose any special verification challenges?
Andrews: Well, processors are pretty hard to test in general. You don't have a lot of controllability. All you have is a little instruction stream coming in. With our core, some of the features of the instruction stream are difficult to test. We have RISC core but we have CISC-like features in the core that are hard to test. We generally burn a lot of cycles finding those last few bugs.
EEdesign: What was your verification flow before using 0-In products?
Andrews: 0-In did not dramatically change our flow; it was just an addition to our flow. We use all the popular Verilog simulators, including [Synopsys] VCS and [Cadence Design Systems] NC-Verilog and Verilog XL. We use [Synopsys] Vera to stimulate our design. 0-In is the closest we have to a formal tool. We do have formal tools for RTL-to-gate comparison, but not for RTL.
EEdesign: Why did you decide to try 0-In?
Andrews: It was basically becoming very difficult to flush out those last few bugs, and it will become more difficult in future as our core becomes more complex.
We wanted to try to shrink the time to find those last few bugs, and we also wanted to guarantee we'll ship a high quality product.
EEdesign: When in the design cycle do you use 0-In Check?
Andrews: We generally start around the midpoint of verification. Once you've got all the easy bugs out of way, and it's becoming difficult to find new bugs, at that point you generally start writing a lot of new tests. But I think it also makes sense to bring in 0-In at that point, about halfway through design cycle.
EEdesign: What steps do you go through to use 0-In Check?
Andrews: It embeds checkers in your RTL or testbench, either one. We've integrated it into our flow, and we have a script, so we just add a flag to our script that does everything. What's happening underneath that is that a pre-processor runs over the Verilog code and finds all the checkers. The output to that is used as input to actual Verilog simulation. It's not very difficult to incorporate.
We have mostly used the standard 0-In checkers. We added one checker, which they [0-In] created for us. It doesn't seem real hard to create checkers, but we would tend to use the ones they supply as much as possible.
EEdesign: Which simulator do you use, and what's the output?
Andrews: We use VCS. Once the checkers are good, we turn most of them on during regression. When checkers fire, they put output right into the simulation log. It's very explicit output. It tells you the checker name, what actually fired, and what file you can find that checker in, and gives you the simulation time it fired at.
EEdesign: What's the main advantage of 0-In Check?
Andrews: It finds bugs really early in the simulation. As soon as the error happens the checker will fire, whereas without it, you might simulate for 100 or 1,000 cycles before you actually see the error.
The real test will be on a completely new design, which we will be working on soon. I think the key is to use it from the start. Our designs aren't that complicated, so I think the main benefit for us will be shrinking the total verification time. In very, very complicated designs, it's more likely you'll find something you never would have found otherwise.
EEdesign: What capabilities does 0-In Search add?
Andrews: Check is more geared to finding things extremely quick in simulation, on the cycle where the actual error happens. Search is more likely to find bugs you would not have found any other way. It can shrink a lot of time, or find bugs no one is going to be able to think of, just something that requires a lot of unusual conditions to happen at once.
EEdesign: Found any bugs yet with 0-In Search?
Andrews: Not yet, but right now we're using it on something that has had lots of verification before we applied 0-In, and the complexity is not that high. So the real test will be on a completely new design.
EEdesign: How easy are the tools to learn and use?
Andrews: I'd say its a moderate level of difficulty. You'd have to spend some time reading manuals, or go through their training, or probably both. They are not simple push-button tools, but I've definitely used tools that are more complicated. 0-In helped us a lot in the beginning, but now we're transitioning to running it ourselves.
EEdesign: Any limitations, or things you'd like to see improved?
Andrews: I'd like to see the search execution time be faster. Check slows simulation down by a very small amount. Search slows it down quite a bit, but Search is a much more powerful tool, so that's to be expected.
We're also talking to them about making checkers easier to write. But generally, the tools are in pretty good shape right now.