Home > Community > Blogs > Industry Insights > challenging misconceptions about verification languages
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Challenging Misconceptions About Verification Languages

Comments(2)Filed under: Industry Insights, DVCon, SystemC, OVM, verification, e, OOP, HVL

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

Comments(2)

By hevangel on March 12, 2010
Where can I find the two paper?  Thanks.

By Richard Goering on March 12, 2010
The DVCon papers mentioned in this blog are available in the Cadence Resource Library at www.cadence.com/.../default.aspx.

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.