Algorithmic Testbench Synthesis
I had one of those “Doh! Why didn’t I think of that?” moments at the Mentor booth today. Mentor have a new tool [1] in the pipe called InFact which solves a problem in stimuli generation that you might not even have realised you had [2]. Once it’s pointed out to you, you might start wondering why you put up with it for so long.
Have you ever run a regression and found it took ages to hit those last few functional coverage points? For example, you fully define your AHB transaction, but you never seem to hit that weird WRAP8 BUSY 16bit OPCODE scenario. No matter how many tests you run, it just never seems to get hit, although you’ve hit some other scenarios a million times.
That seems like a bit of a waste of time.
The problem is that although your AHB stimuli describes all of the possible bus transactions, it doesn’t necessarily define the order that these bus transactions have to be generated in. Unless you were being very cool and clever when designing your testbench, the chances are that you left the generation of these bus transactions completely to chance, and just accepted them in any order.
Getting slightly technical, you have a graph of all possible bus transactions, but no control over how that graph is traversed. Every time your testbench generates a new bus transaction, it takes a path through the graph, but you don’t have much control over the paths taken.
Sure, you can set some constrains to control the /amount/ of the graph that can be traversed (e.g. you can say - no BUSY transactions, or more WRAP16s), but it would be difficult to control the order that it was traversed.
This is where InFact comes in. In simple terms, it lets you:
- specify the valid bus transactions (the graph) using a proprietary, but easy looking, declarative specification language, and
- lets you control how the graph is traversed
The “algorithmic” in the title refers to the algorithms used to traverse the graph. One algorithm ensures that each path is only taken once, which means that you’ll hit all possible scenarios in the minimum amount of time (there will be no duplicates). Another algorithm - the “Spatially Distributed Traversal” - ensures that the next path chosen is the one furthest away (most different) to all of the previous ones chosen. This means you’ll cover a whole bunch of different options and modes quickly, rather than going deep in a narrow area.
There are three controls for each algorithm (scope, intensity and coverage) which let you tweak the operation, and there are a whole bunch more algorithms to select from. I would tell you more, but the DVD they gave us on the way out was blank!
Apart from specifying the graph, you have to supply code for all of the leaves of the graph - the end points where you need to get the testbench to do something. These can be Verilog, SystemVerilog, C, C++ or SystemC tasks, such as do_wrap4() which actually causes a wrap4 transaction to occur.
I’m not sure when you can expect to see this as a released product. The Mentor guy (Mark Olen) claimed it was in X customers already, with another Y more evaluating it, but searching the Mentor site reveals almost nothing with this name (although you can find a paper on it [3]).
Anyway, I thought it looked like a pretty cool and useful tool, and definitely something I’d like to use on future projects.
David
[1] The tool was originally developed by Lighthouse Design Automation, but has somehow made its way into Mentor, so the tool shouldn’t really be “that” new. There are articles dating back to 2004 discussing it
http://www2.dac.com/41st/41exhibitorarea.nsf/0/BEA72D04EEA6722987256E2E007D6F6B
[2] I’ve suffered from it before, but just shrugged it off as “just one of those things”
[3] Start at http://www.mentor.com/products/fv/techpubs/index.cfm and navigate your way to it
