Looks like Cadence is finally on offensive and pushing Specman strongly over SystemVerilog. As a long time user of Specman, I would like to see Specman wins the HVL war at the end which will make my skill and experience more valuable.

By Richard Goering on March 10, 2010

One thing I learned from the recent DVCon conference is that there are a number of common misconceptions about hardware verification languages (HVLs). I had a few of these myself. Two provocative and well-attended presentations provided a different way of looking at HVLs:

* “Apples Versus Apples HVL Comparison Finally Arrives.” Presented by Brett Lammers of Cadence Feb. 24.
* “Where OOP Falls Short of Verification Needs.” Presented by Matan Vax of Cadence Feb. 25.

Some of the misconceptions identified in these talks are as follows.

Misconception #1: The design language defines the HVL choice

At the beginning of his talk, Brett noted that verification is fundamentally different from design. With design, one is implementing a spec; with verification, one is checking the implementation. Instead of what the device should do, verification engineers are concerned about what the device should never do. Instead of area, timing and power, verification engineers prioritize test generation, coverage, and corner cases.

It thus makes sense that the unique characteristics of verification make HVLs “special,” as Brett put it.

An attentive DVCon audience listened to Brett Lammers’ HVL presentation.

Misconception #2: Object-oriented programming is the best way to get verification reuse

While OOP facilitates reuse in many software applications, it’s not a complete solution for HVLs, Matan argued. His paper explained that verification does not lend itself naturally to classic object-oriented design, and that attempts to insert OOP techniques place an additional burden on programmers. In a video interview in a recent blog by Joe Hupcey III, Matan stated that “what you’re doing with the object-oriented mechanism is emulating a different paradigm, and it would be much easier if the language could use that paradigm directly.”

As Brett noted in his presentation, OOP allows a modular approach by encapsulating behavior within objects, but verification presents many “aspects” (like checking, coverage, and error injection) that cut across many objects. An aspect-oriented programming (AOP) language like the e language makes it possible to represent aspects as modules of their own. “Verification represents a lot of aspects, and AOP allows you to capture them in a more manageable way,” Brett said.

Misconception #3: Verification productivity = simulation runtime

Verification engineers tend to focus on how fast simulators run. But overall project productivity involves more than just simulation speed, Brett noted. If you can shrink the time required to create the verification environment and write the tests, and spend more time, rather than less time, in regression testing, this will provide more time to find and fix bugs.

Brett noted that simulator performance depends on simulation tools and has no inherent connection to the language that’s chosen.

Misconception #4: Compiling languages are best and fastest

Compiled languages such as e and SystemVerilog do provide the highest simulation performance, Brett acknowledged. But a language that can be either compiled or interpreted, such as e, provides more flexibility. A mix of interpreted and compiled code may be better for development, and using all interpreted code helps with debugging.

Misconception #5: Legacy VIP means you’re stuck with an HVL forever

Not so, Brett said. Cadence has extended the Open Verification Methodology (OVM) to support e and SystemC testbenches and verification IP (VIP) along with SystemVerilog. VIP in these languages can be mixed in a common environment. The Cadence Incisive Enterprise Simulator supports e, SystemVerilog, and SystemC, making it possible to migrate from one language to another.

Misconception #6: One HVL is best for all

Not even the e language, with all its capabilities, is the best choice for everyone. Brett’s last slide looked at “which language fits best where.” As you can see, there’s a place for both SystemVerilog and e.