Though the panel was invited to determine "how much verification is enough," that's really the wrong question, said Greg Spirakas, Intel Corp.'s architecture group vice president and director of design technology. "The reality is you typically do validation and verification until you run out of time, cycles or you run out of money," he said.

Spirakas displayed a graph showing that the number of errata based on RTL cycles levels off at a given amount of time. "But if you plot it on a logarithmic scale it looks a bit different," said Spirakas, who showed a second graph indicating that RTL cycles and bugs actually increase over time. "We have fooled ourselves into believing that when we have reached a certain point [when errata based on RTL cycles levels off] we are at the point where we are done. The reality is we are simply looking at design time needed to find the next bug."

Spirakas said he believes the true way to get around creating bugs is by using a correct-by-construction methodology. In this methodology, design teams create a golden formal model, validate that a design meets system requirements, then make small successive refinements down through hardware/software implementation. At every step, designers use formal verification and other techniques to prove that the design still conforms to the original golden design.

"It requires a methodology change and designers must do it in a structured way," said Spirakas. He said the correct-by-construction methodology is especially suited for rapidly evolving markets, because core functionality can be designed first then features added for subsequent products.

One-pass tools and flows advocated by some EDA vendors are encouraging because they attempt to bring all the necessary information together to create design closure, Spirakas said. His group at Intel is also looking forward to new system-level design languages to raise design implementation one level of abstraction above RTL, he said.

Chris Malachowsky, vice president of engineering at Nvidia Corp., said he believes the correct-by-construction methodology is only valid when the exact features and parameters of a design are known at the beginning of the design process. That doesn't happen at Nvidia, he said.

But as an advocate of successive refinement, Malachowsky said he sees validation and verification as separate steps. "Validation is proving through modeling that we have the functionality that we want. From that point on it becomes the golden model," he said.

"The rest of the process is trying to validate that we either built or coded the design the way that we wanted," he said. "We run cycles of verification and at some point we believe that our golden model and our design model are equivalent. Then we take it to silicon and we spend a bunch of verification cycles characterizing and determining that what we got back is what we think we sent in."

Malachowsky noted that his group has a spotless track record at Nvidia in terms of getting top-tier graphics chip sets out the door. "The problem is, I can't distinguish lucky from good," said Malachowsky. "Our logical problems seem few, but it just may be that things end up that way — we are lucky. We're trying to improve things so we don't have to depend on being so lucky."

To firm up its design flow for multimillion-gate chips, Malachowsky said Nvidia plans to enforce particular guidelines for code coverage, do property-based verification, and increase its use of formal verification methods. The company also intends to include packaging and pc-boards in its verification, and to use subsystem emulation in addition to entire system emulation.

Thomas Daniel, vice president of ASIC technology at LSI Logic Corp., said correct-by-construction is a good methodology but smart use of verification is also a necessity.

"People assume that it is a given that once your RTL is correct, you will not find problems later on — this is true, sometimes," said Daniel. "So how much verification is required? The easy answer is to say as much as you possibly afford. But it is not how much, rather it is how smart you apply it."

Daniel advocated the reuse of verification and of intellectual property.

Altera Corp. vice president Bryan Hoyer took a similar view of verification, but pointed out that software's increased role in design will likely help shorten lengthy verification cycles. "The trick is to get the correct product to the marketplace at the correct time," said Hoyer. "It is an economic proposition too — what is the cost of an error. Software solutions decrease the cost of change but also the cost of an error."

To improve manufacturing test, panelists said, a new approach to fault modeling is needed. Janusz Rajski, chief scientist for Mentor Graphics Corp.'s advanced CAD research group, said the standard "stuck-at" fault model needs to be supplemented with path delay, bridging and transition faults.

Tom Williams, chief scientist at Synopsys Inc., agreed that delay testing is badly needed. Williams showed how a resistive short can potentially delay an otherwise correct signal. A "transition fault" model is the best way to model delays, Williams said, but he acknowledged that few chip design teams use this approach.

— Richard Goering contributed to this story.