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.
Cadence's approach
is to support both SystemVerilog and e, along with SystemC. Why pick just
one HVL when you can offer a choice?
Richard
Goering
Photo by Joe Hupcey III
Cadence Community blogs about DVCon
2010
Steve
Svoboda: Quiet
Before The Storm? And What To Expect at DVCon 2010
Adam
Sherer: DVCon:
Showcasing The Cadence Passion For Verification Excellence
Joe Hupcey
III: DVCon
"Day 0" - Quick Report From SystemC Day
Richard
Goering: DVCon
SystemC Day - Forging A TLM Design/Verification Flow
Joe Hupcey
III: DVCon
2010 - Day 1
Richard
Goering: DVCon
SystemC Day Quandry: Need For Third Party TLM IP
Richard
Goering: Lip-Bu
Tan Keynote: Rethinking EDA For 2010 And Beyond
Joe Hupcey
III: DVCon
2010 - Day 2
Tom
Anderson: DVCon
2010 Rocked!
Richard
Goering: DVCon
Panel: Why Verification Engineers Are "Sleepless"
Joe Hupcey
III: DVCon
2010 - Day 3
Richard
Goering: DVCon
Panel: Three Ways To Minimize Verification Effort
Joe Hupcey
III: Why
OOP Falls Short For Verification
Richard
Goering: DVCon
OVM Panelists: Easing The Debug Challenge