Verification gets no respect, panel says

Verification gets no respect, panel says
By Richard Goering, EE Times
March 12, 2002 (11:52 a.m. EST)
URL: http://www.eetimes.com/story/OEG20020312S0032

SAN JOSE, Calif.—Verification gets no respect, according to participants in a "value of verification" panel at the International HDL Conference. Both design and verification engineers on the panel and in the audience expressed frustration with the lack of tooling, methodologies and qualified personnel for a task they called essential and in need of greater attention.

Though verification takes up to 70 percent of an overall design task, for example, it is usually performed by junior engineers, said Bernie Delay, director of intellectual property (IP) development at Qualis Design Corp. "Why would we put the new guy out of college on this task? We'd get the most bang for the buck if we put our best guys into what takes 70 percent of the time," he said.

Delay also said that many verification engineers are stuck with "the worst possible tools," and that many companies have no real verification methodology — no test plan, no coding g uidelines, and no verification IP that can be reused.

Foster White, senior staff verification engineer at Intel Americas Inc., said he'd been in bad verification environments in the past, but is in a good one now. The difference? "My input is valuable, and my management treats me like I'm valuable," he said. "Verification is not just about fixing bugs; it's about exploring the design."

The problems aren't only on the verification side, said two design engineers on the panel. Darius Dabiri, principal ASIC engineer at Agile Storage Inc., noted that designers today typically don't do verification and may often pass "nonsense code" to verification engineers.

"This situation has to change," Dabiri said. "Designs are more complicated, and it's very expensive to maintain this dependency. We need to merge these two tasks somehow."

Steve Golson, an engineer at Trilobyte Systems, said there are three main tasks in a design — architecting a specification; implementing RTL code; and verification — but that most companies create no real specification and dive right into RTL code. In such an approach, intent is not communicated and verification engineers must ask designers how the design is supposed to work.

"Assertions are just a sneaky way to get designers to write a spec," Golson observed.

One audience member noted that he can buy commercial IP with a standalone testbench, but can't get a system-level testbench with it.

"The vendors don't think you value verification IP," responded Delay. "With just a little effort on their part, they could rip out part of their verification environment so you could reuse it."

"IP means that when I find a bug, I have no way to fix it," said another audience member. "All I can do is file a bug report and hope some guys in the U.K. get around to fixing it before my company goes under."

Another audience member said he'd purchased a bus-functional model from Synopsys Inc.'s Logic Modeling Group (LMG) but had t o call the company repeatedly in an effort to get bugs fixed. "It ran five days, ran out of memory, and crashed," he said. "I had to debug it, and I had to get Cadence R&D talking to Synopsys LMG," he said.

Delay suggested that perhaps there should be some standards that define how bus-functional models should interact. "Maybe we need to work at a higher level than just languages," he said.

White had a more skeptical view of standards, however. "What Accellera is doing with Verilog is very promising, but it's too far behind," he said. "I can't wait five years for them to add what I need to do my job."