To break the functional verification bottleneck, you must improve the quality of design, speakers told last week's Design and Verification Conference (DVCon) here. They called for a new design methodology that will result in fewer bugs in the first place.
San Jose, Calif. To break the functional verification bottleneck, you must improve the quality of design, speakers told last week's Design and Verification Conference (DVCon) here. They called for a new design methodology that will result in fewer bugs in the first place.
Statistics show that functional verification can represent 35 to 70 percent of the total design effort. With verification teams often larger than design teams, dramatic improvements are needed before people start tackling the 50 million-gate designs possible at 90 nanometers and below.
Even the massive verification effort is not enough, observers say. In his key-note, Walden Rhines, Mentor Graphics Corp.'s CEO, said that two-thirds of chip designs require at least two spins, and that three-quarters of those spins are due to logic errors or other functional bugs.
Panelists repeatedly returned to the theme that the real culprit is design. "We need to move from verification after the fact to a prove-as-you-design," said Harry Foster, chief methodologist at Jasper Design Automation (Mountain View, Calif). "We should build quality in from the start."
In an an apparent reference to his JasperGold tool, Foster said a "new generation" of formal verification tools will help. Jasper's tool verifies high-level requirements and uses a "provably correct design methodology."
One way designers can help with verification and sometimes they already do is to add assertions to their RTL code. The emerging SystemVerilog language will ease that. "Experts tell me you should have an assertion in your code just about everywhere that you would put in a comment," Rhines said. "An assertion every 10 lines is not unrealistic."
But Limor Fix, principal engineer at Intel Research (Pittsburgh), said designers are doing assertions the wrong way. Today, she said, people design first and put in assertions later.
"We design and then annotate that this is what we want," Fix said. "We do it in the wrong order. We should specify assertions or design intent first, and then specify the lower-level details."
Andrew Piziali, senior product engineer at verification tools provider Verisity Inc. (Mountain View, Calif.), said it's important to distinguish specifications an early abstraction of the design from documentation, which writes down what's already been done. "You can improve first-time silicon quality two-fold by integrating the functional spec into the design process," Piziali said. "You can expose flawed ideas in the earliest stages."
For Kevin Normoyle, architect at Azul Systems Inc. (Mountain View, Calif.), better design means keeping it simple. "We brag about complexity, but I think the reality is that we're not very good at what we do," he said. "In most places where I've seen a lot of bugs, it's in useless stuff that adds no value."
Disagreement arose at DVCon over whether to have separate design and verification teams. Verisity's Piziali said yes, arguing the importance of an independent verification review.
But Gary Smith, chief EDA analyst at Gartner Dataquest, contended that "as soon as you separate the design and verification teams, verification productivity drops by 25 percent."