We all want our next-generation Pocket Rocket to do new stuff (and do the old stuff better), as well as get smaller, run longer, and cost less. We also don’t necessarily want to wait for the holiday season for it to hit the shelves. We gadget freaks are often rather impatient in that regard.
For the design team, these marketplace realities don’t exactly lead to a leisurely existence. Instead, it means negotiating the extraordinary challenges of making it all happen and getting it right in an increasingly compressed timeframe. The system-on-a-chip (SoC) that gives wings to your Pocket Rocket is becoming more expensive to design with each new generation, and even more expensive to ensure that it does what you think you designed it to do.
With 65-nm process technologies becoming mainstream and 45/40-nm processes emerging, average gate counts are on the rise. In turn, this makes the functional-verification bottleneck even more burdensome (Fig. 1). For designers, design is the rock and verification is the hard place, and they find themselves in between. In this article, we’ll examine how verification methodologies are changing to cope with the sheer size of today’s designs.
WHERE WE'VE COME FROM
As process technologies have moved down the curve toward the deep-submicron nodes, there have been distinct approaches to how engineers write their testbenches or the suite of test vectors that are run against their designs in simulation. The most typical approach in years past was to use directed tests. “Such tests are reasonably high in quality, as they were usually written by the same people who designed the circuit,” says Mark Olen, marketing manager for the SoC business unit of Mentor Graphics.
However, SoCs have become so complex that even the designers themselves don’t have the time or comprehensive insight required to write enough tests to cover all of the functionality, including all of the corner cases caused by any number of minor (or major) changes to the RTL along the way. Face it, even very smart people are apt to forget things.
Along came the addition of constrained-random testing, which solves the quantity problem. “If you want lots of testbench sequences, use constrained random testing. However, this comes at the expense of quality,” says Olen (Fig. 2). “Your engineers are giving up control and direction of test generation to a random number generator, guided by algebraic constraints.”
The constraint solvers used today for random test generation are quite sophisticated, allowing engineers to write constraints that guide the randomness of the testing to some degree. This enables constrained-random methodologies to cover more of a complex design than directed tests. Still, a gap remains between what was designed and what gets tested—and that chasm tends to keep verification engineers up at night. If they knew how to bring the two together, they would. But they don’t.
WHERE WE'RE GOING
The logical conclusion is that to improve the quality of verification, while achieving greater efficiency in the process, there needs to be automation applied to directed testing and less emphasis on randomness. “We see the trend moving back to engineers wanting to make sure they test everything,” says Adnan Hamid, CEO of Breker Verification Systems. “They’re saying, ‘I don’t have time to write all the tests so I want a tool to generate the tests.’”
Verification is headed in the direction of the so-called “intelligent testbench” (a term widely attributed to analyst Gary Smith of Gary Smith EDA). Such technologies are taking shape, largely under the auspices of a few startups such as Breker, NuSym, and Certess, as well as in at least one large, established EDA company—Mentor Graphics. Some of these technologies are “white box” in nature, providing a clear view of the design’ s internals, while others are more of a “black-box” approach.
Meanwhile, other EDA houses are attempting to leverage the powerful verification capabilities inherent in the SystemVerilog language to instill more intelligence into the tried-and-true constrained-random methodology. Such approaches are usually augmented by increased reliance on assertions.
smartening up So what exactly is an “intelligent testbench,” anyway? That depends on who you ask. “Keep in mind that the true intelligent testbench includes the automation of the tool flow, including formal verification, and the automation of the methodology,” says Smith. Not every vendor necessarily complies with that caveat, though.
Breker Verification Systems’ approach was forged in the company’s roots inside Advanced Micro Devices. “In CPUs, random testing never made sense,” says Hamid. “We went to directed test cases and started using a graph-based approach. Now the big breakthrough was to combine graphs with a constraint solver.”
Continue on Page 2
Reprints
