Combining Intelligent Testbench Automation with Constrained Random Testing

Who Doesn’t Like Faster?

In my last blog post I introduced new technology called Intelligent Testbench Automation (“iTBA”).  It’s generating lots of interest in the industry because just like constrained random testing (“CRT”), it can generate tons of tests for functional verification.  But it has unique efficiencies that allow you to achieve coverage 10X to 100X faster.  And who doesn’t like faster?  Well since the last post I’ve received many questions of interest from readers, but one seems to stick out enough to “cover” it here in a follow up post.

Several readers commented that they like the concept of randomness, because it has the ability of generating sequences of sequences; perhaps even a single sequence executed multiple times in a row. ¹ And they were willing to suffer some extra redundancy as an unfortunate but necessary trade-off.

Interactive Example

While this benefit of random testing is understandable, there’s no need to worry as iTBA has you covered here.  If you checked out this link – http://www.verificationacademy.com/infact2 – you found an interactive example of a side by side comparison of CRT and iTBA.  The intent of the example was to show comparisons of what happens when you use CRT to generate tests randomly versus when you use iTBA to generate tests without redundancy.

However in a real application of iTBA, it’s equally likely that you’d manage your redundancy, not necessarily eliminate it completely.  We’ve improved the on-line illustration now to include two (of the many) additional features of iTBA.

Coverage First – Then Random

One is the ability to run a simulation with high coverage non-redundant tests first, followed immediately by random tests.  Try it again, but this time check the box labeled “Run after all coverage is met”.  What you’ll find is that iTBA achieves your targeted coverage in the first 576 tests, at which time CRT will have achieved somewhere around 50% coverage at best.  But notice that iTBA doesn’t stop at 100% coverage.  It continues on, generating tests randomly.  By the time CRT gets to about 70% coverage, iTBA has achieved 100%, and has also generated scores of additional tests randomly.  You can have the best of both worlds.  You can click on the “suspend”, “resume”, and “show chart” buttons during the simulation to see the progress of each.

Interleave Coverage and Random

Two is the ability to run a simulation randomly, but to clip the redundancy rather than eliminate it.  Move the “inFact coverage goal” bar to set the clip level (try 2 or 3 or 4), and restart the simulation.  Now you’ll see iTBA generating random tests, but managing the redundancy to whatever level you chose.  The result is simulation with a managed amount of redundancy that still achieves 100% of your target coverage, including every corner-case.

iTBA generates tons of tests, but lets you decide how much to control them.  If you’re interested to learn more about how iTBA can help you achieve your functional verification goals faster, you might consider attending the Tech Design Forum in Santa Clara on September 8^th.  There’s a track dedicated to achieving coverage closure.  Check out this URL for more information about it.  http://www.techdesignforums.com/events/santa-clara/event.cfm

¹ – By the way, if achieving your test goals is predicated on certain specific sequences of sequences, our experts can show you how to create an iTBA graph that will achieve those goals much faster than relying on redundancy.  But that’s another story for another time.