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.
Some of the misconceptions identified in these talks are as
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
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."
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,"
Misconception #3: Verification productivity =
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.
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
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
Misconception #5: Legacy VIP means you're stuck with
an HVL forever
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
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.
is to support both SystemVerilog and e, along with SystemC. Why pick just
one HVL when you can offer a choice?
Photo by Joe Hupcey III
Cadence Community blogs about DVCon
Before The Storm? And What To Expect at DVCon 2010
Showcasing The Cadence Passion For Verification Excellence
"Day 0" - Quick Report From SystemC Day
SystemC Day - Forging A TLM Design/Verification Flow
2010 - Day 1
SystemC Day Quandry: Need For Third Party TLM IP
Tan Keynote: Rethinking EDA For 2010 And Beyond
2010 - Day 2
Panel: Why Verification Engineers Are "Sleepless"
2010 - Day 3
Panel: Three Ways To Minimize Verification Effort
OOP Falls Short For Verification
OVM Panelists: Easing The Debug Challenge