March 17, 2003
Division of Labor
Please note that contributed articles, blog entries, and comments posted on are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
Peggy Aycinena - Contributing Editor

by Peggy Aycinena - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!

Well, maybe not divine, but certainly unavoidable, expensive, often inefficient and incomplete, yet (almost) always critical to the success of a project and to the level of subsequent customer satisfaction - particularly in multi-million gate designs produced with next-generation process technologies.

But if you've been out and about at technical conferences lately, you may have heard rumors of strategic personnel cutbacks that keep the designers, but eliminate dedicated verification engineers for the sake of the bottom line.

How can this be? How can the industry continue to pay lip service to well-verified designs, when personnel crucial to verification are being laid off? Are the current verification tools capable of picking up the slack? Can the current crop of design engineers handle these tools with the same skill and familiarity as a modern-day verification engineer? Or instead - are all of the rumors simply unfounded?

A variety of verification tool vendors were asked to respond to these questions, and their answers are listed below. Their responses are not identical and it's interesting to discern the subtle distinctions between their opinions. It was tempting to leave the names of the companies off of their responses, to disconnect a company's technology initiatives from its philosophy regarding today's design & verify personnel conundrum. But can you ever separate a company's philosophy from its fundamental technology? Not really, so the names of the companies were left in place.

Meanwhile, after you've had a chance to read the various statements, you'll also have a chance to hear from Janick Bergeron, industry veteran and Moderator of the Verification Guild. He says his opinions on the design-versus-verification engineer issue are “well known.” Nonetheless, it's great to have him weighing in on the discussion and his input is appreciated.

So, consider this to be a panel discussion of sorts. There are 12 panelists and an expert moderator, ready to attack the topic at hand. Read on and learn what you will.

(Editor's Note: The responses here are verbatim, as received. Thanks to all who took the time to respond and to contribute to the dialog. I am particularly grateful to those who refrained, as much as possible, from inserting marketing language into their comments.)

Once again, here's the question:

“Voices in the industry seem to be indicating that many companies cannot afford to - or choose not to - have a separate individual on the design team who handles verification. Therefore, are the verification tools currently available easily understood and used by design engineers who are NOT verification engineers? In other words, are verification engineers no longer needed?”

And here are the answers:

Emil Girczyc, CEO and President at 0-In Design Automation, Inc. - “The trend to having the same person design and verify has been a standard practice in software development for many years. This makes testing more effective because the tester knows both the specification and implementation enabling both black and white box testing. But more importantly, programmers learn to write code that is testable. Placing assertions in C code is common coding practice, as is documenting interfaces, documenting the internal code structure, and most importantly, writing testable code.”

“In the case of hardware design, having designers participate in testing also will lead designers to better instrument their code, document their interfaces, document their RTL structure, and design testable circuits to simplify verification. There is no clearer way to get a designer to appreciate the benefits of design for verification than forcing them to do some verification. The tools that designers need to achieve design for verification are a coding guideline, a rich library of assertion IP, and robust tools for assertion-based verification. Once established, these tools and practices are easy enough for most designers to use to the level required for design for

“However, when the only code checker is the designer that wrote the code, there are holes for many bugs to slip though. In software development, every programmer's code is also tested by other developers, specialists, and customers (alpha and beta testing), and there is always someone who builds a test infrastructure that each programmer leverages. Similarly in hardware development, others need to test each designer's RTL code to insure that the designer hasn't misread the spec, or missed implementing or testing a part of it. Further, since the hardware equivalent of a “beta” or a patch release is very expensive - a silicon re-spin potentially greater than $1 million,
several months' delay, and possibly a field recall - hardware requires more rigorous testing of the RTL implementation than does C code.”

“This will likely be done by verification specialists (or designers acting as verification engineers). There will also always be a role for someone on the team who (full-time or part-time) sets up the infrastructure for regression testing, metrics, etc. that will be used by all verification engineers. This is not just a function of running the tools, but having the extra insight and time to plan a methodology and set up the infrastructure to make verification robust, effective, and efficient.”

Dino Caporossi, Vice President of Corporate Marketing at Verplex Systems Inc. - “When using Accellera's Open Verification Library (OVL), there are few people better to insert the assertions than the designer since he or she is the one who understands how the design should be verified from an implementation point of view. When a designer creates a First In First Out (FIFO) block, for instance, the designer automatically knows that it should be checked for overflow (writing when already full) and underflow (reading when empty). The verification engineer typically stays at a higher level and does not check for such things. Then, errors that could have been caught earlier by
the designer are caught later by the system-level or verification engineer. But at that point, the design has matured to the point where fixes are more difficult and expensive to make.”

Francine Ferguson, Vice President of Corporate and Strategic Marketing at Verisity - “Are verification engineers no longer needed? Absolutely not! Verification has become the most critical business problem electronic companies are facing and hence, verification engineers are becoming more vital to engineering teams than ever before. When tackled correctly - with a mix of experienced engineers, the right methodology, and cutting-edge technology - verification can provide the biggest productivity gains in the entire design schedule. Of course for many companies, separate verification teams, or engineers with the title Verification Engineer, may not exist. But when it comes
to doing system-level verification, they actually do have specialists responsible for the verification that are, in fact, equivalent to a verification engineer.”

Udo Muerle, CEO of TransEDA - “Verification engineers are needed more desperately than ever, so I think the question of whether the tools are easy to use is not the key issue. A verification engineer needs to address and resolve very different issues compared to a design engineer. But both require the best tools available for them to do their job. In chip design today, the most pressing problem is to verify that all functionality integrated into a design will work correctly. In comparison, it is relatively easy to integrate the required functionality, as it is now commonly achieved through IP use. So the question should be: 'How much effort should be spent on
verification?' It is well documented that 70% or more of total design time is spent on verifying the design. This underlines the necessity for verification. Companies cannot afford to not have engineers whose responsibility is focused on making sure a design works as it should.”

Rajiv Kumar, COO, Vice President and Co-Founder of Real Intent - “It is safe to say that the verification engineers are going to be needed for the foreseeable future. But it also is equally safe to say that new verification tools are now empowering the designers to perform verification tasks that have traditionally been done by the verification engineers. More specifically - assertion-based verification (ABV) tools are leading that transition. For example, our formal ABV tool Verix is being used regularly by designers to formally verify behaviors of their blocks with designer-provided assertions. This is taking place well before they hand-off the RTL to the verification
teams. Similarly, the designers are also using Verix to verify multi-clock designs to ensure that signals are safely crossing asynchronous clock domains.”

1 | 2 | 3 | 4 | 5 | 6  Next Page »

You can find the full EDACafe event calendar here.

To read more news, click here.

-- Peggy Aycinena, Contributing Editor.

Review Article Be the first to review this article
CST Webinar Series


Featured Video
Manager, Field Applications Engineering for Real Intent at Sunnyvale, CA
Upcoming Events
SEMICON Europe at Grenoble France - Oct 25 - 27, 2016
ARM TechCon 2016 at Santa Clara Convention Center Santa Clara CA - Oct 25 - 27, 2016
Call For Proposals Now Open! at Santa Clara Convention Center, Santa Clara, CA California CA - Oct 25 - 27, 2016
DeviceWerx - 2016 at Green Valley Ranch Casino & Resort Las Vegas NV - Nov 3 - 4, 2016
S2C: FPGA Base prototyping- Download white paper

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy