Verification As A Deterrent?
By Ed Sperling
Verification is becoming more than a bottleneck in semiconductor design. It’s actually deterring companies from adopting the latest techniques for saving power or building certain features into chips.
The problem is one of complexity, and it’s getting worse at every node. While the tools exist to do complex designs, there are the classic tradeoffs of area, power and performance coupled with business decisions about cost, break-even volume, time to market and reliability of the overall design.
“This is all cause and effect,” said Rob Aitken, an R&D fellow at ARM. “You may have formal methods to link four systems together, but that doesn’t mean it will work well with eight systems. And it gets harder with power islands. Verification of that stuff is very hard. The design is hard enough to begin with. Verification is keeping people from using those ideas.”
Adding complexity into a design also adds many more corners for verification and raises questions about just how complete are the verification coverage models. “If you can’t answer the question of how you know if you did something right then you can’t do it,” said Aitken.
Even at existing nodes problems are erupting. Algorithmic-intensive designs have always been problematic, but the utilization of more algorithms to save power and improve performance doesn’t translate well from the language in which those algorithms were created—usually Matlab—to RTL.
“This is showing up in everything from cell phones and video to security,” said Brian Bailey, an independent verification consultant. “They all have algorithms, and most algorithms start off life in Matlab. They’re pure floating-point algorithms with no concern about how they’re going to be implemented. The creators of those algorithms are just trying to figure out what can be done and whether it will actually give them what they want.”
From there, it has to be translated. “You can’t just throw this through high-level synthesis,” said Bailey. “It doesn’t work like that. A reference algorithm may be written in floating point. You have to convert it to fixed point, and when you get to overflow, rounding and truncation you can break the algorithm. You have to constantly go back and ask the question, ‘Have I broken the algorithm?’
One solution is to keep test benches in Matlab, which makes it easier to truncate inverse functions and then find standard deviations. But there is no foolproof verification method at the moment, and that poses a serious problem. There are some efforts that have been taken, so far. Flows from Cadence and Mentor use C++ to define certain portions of the algorithm and the fixed point conversion can run in C using those flows without a simulator. And multiple sources say Synopsys has been working on its own solution, but the company will not comment on unannounced development.
The only comment from Synopsys was that algorithmic design is indeed a growing problem that needs to be solved. “You can get the algorithm done quickly, but from there you need to recode everything to get a full validation of the algorithm,” said Chris Eddington, director of marketing for Synopsys’ high-level synthesis and system-level products. “Going from Matlab to RTL may take three to six months. The real problem is re-verification of all of this. Just to validate the prototype of the algorithms can take three to four months.”
Until this gets resolved, however, and until verification makes more strides toward matching the architectural design on the front end, many developers say privately that design activity may be limited on all but the highest-volume designs where it pays to work out these kinds of issues by brute force—lots of engineers, lots of testing, and lots of trial and error.
Tags: algorithms, Cadence, Matlab, Mentor Graphics, Synopsys, The Mathworks, Verification
September 27th, 2009 at 11:25 am
Your latest blog topic certainly reflects real problems in the semiconductor design flow. Verification is the big issue, and Brian Bailey is right that it can’t be addressed “by throwing high-level synthesis” at it.
But as I read this article, I was struck by an important misconception. It’s true that many engineers who use MATLAB® develop floating point algorithms. Often they do that without full consideration of implementation concerns. While some may attribute the problem to the tool they are using, we have found the real issue to be that many engineers don’t take full advantage of tools already available to them.
In fact, fixed point and other capabilities that are important for implementation-aware design and verification have been available in MATLAB and Simulink® for years. For example, interfaces to all of the major EDA vendors’ RTL simulators provide cosimulation and automate testing and analysis. This eliminates an error-prone step in developing the fixed-point reference, and automates the testing of RTL components, and minimizes the re-verification problem. Customers have reported that these tools cut verification times by 50% or more.
This approach is particularly useful when the test cases need to capture interactions with analog or electromechanical components. The behavior of those components, and the requirements they impose on the digital component behavior, is not easily represented in RTL or digital-centric verification languages. Nor are they easily communicated to the verification engineers.
The methodology employed by engineers who use MATLAB or Simulink testbenches is not brute force, but an effective elimination of redundant effort. They’re just making intelligent use of their algorithm domain expertise and tools deliver useful results to the RTL engineers.
This is an important topic. Thanks for writing about it. Now I’d like to hear what the engineers who use these tools have to say.
Ken Karnofsky
The MathWorks
October 9th, 2009 at 12:50 pm
Past Misdeeds Come Back to Haunt Us
The traditional attitude that Verification Engineers are sort of an inferior species has now come back to bite the industry. Perhaps this will result in the verification guys getting some respect, but I doubt it.
Verification has always been a major part of the chip fabrication process, but prior to the advent of large design teams (circa 1995), the same people who designed the chip were given the job of making sure it really works. This approach no longer works.
Meanwhile, I have lost count of how many job orders I have seen for Verification Engineers which say “verification or design experience required”. Never once have I seen that language attached to a job order for a chip designer. The lesson is clear: If you once accept a verification job, then you will never design again.
Oddly enough, having created a situation in which quality is disregarded and Verification Engineers are scorned, the industry now wonders why the only people they can find who are willing to take Verification Engineering jobs are Half-Priced Half-Wits (H1Bs).
If I may make a small suggestion, boys: This problem can be fixed if you are willing to spend enough time and money, but first you will have to fix your attitude.
-Dave Chapman
Former Verification Engineer