Automated tools and standardized methodologies have made functional verification easier, but verification is still arguably the biggest bottleneck in getting chips out the door. The good news, according to panelists at the recent Design Automation Conference (DAC 2013), is that organizational and management changes can ease the verification crisis.
The not-so-good news is that architects, design engineers, and verification engineers will have to step out of the comfort of their "silos" and work much more collaboratively than they have in the past. And companies must foster a culture in which verification engineers are valued.
The panel, held at the DAC Pavilion June 4, was titled "Organizational and Management Solutions to the Verification Crisis." It was moderated by Mike Stellfox, Cadence fellow. Panelists were as follows, shown left to right after Stellfox (far left) in the photo below:
Here are some of the key takeaways from the panel.
1. It's hard to find qualified verification engineers
Stellfox: One of the biggest issues I'm seeing is the lack of verification engineers and expertise in the industry now.
Runner: Certainly verification resources are a critical constraint, and I think all of us are looking at a variety of solutions to address that. One approach is for people who already have the requisite skills to come into a company. Another is to train people to develop verification skills.
Hunter: Here in Austin, it can be difficult getting well qualified people. We are starting to see some graduate courses now, but it is still a challenge.
Ganguly: I notice there's not enough verification talent for the amount of work that needs to get done. In Austin it is very tough to find people with the right kinds of skills.
Runner: I'm from San Diego. I'll add San Diego to that list. And folks in the [San Francisco] Bay Area would say it's hard to find DV [design verification] folks. It's a collective problem overall.
2. Verification must include power and performance
Runner: Not only does lack of verification impact quality, it impacts power. If a power feature is insufficiently verified and doesn't work, it affects the power budget and impacts performance. Performance validation is another critical issue.
Ganguly: Just knowing one particular area isn't good enough. The verification engineer really needs to know, from front to back, where the power is going, and what gates get turned off to enable power management functions.
3. Companies must foster a good verification "culture"
Stellfox: I've seen companies that have a good verification culture, and I've seen companies that don't even have a career track for verification engineers.
Runner: One of the challenges is that verification engineers don't feel appreciated, or don't feel they're on par with design. You need to hold verification on par with design and say both are responsible for verification milestones. For example, if the verification guy finds a bug and the designer has to debug it, whose test plan will be used? It's a joint test planning activity.
Hunter: We try to foster a community around verification. We have a verification conference once a year and we've invited designers as well.
Ganguly: The end result is a joint effort between architecture, design, and verification teams. All of them have to be responsible for the design. I think that at Intel, verification people are treated on par with RTL designers.
4. Designers should be more involved with verification...within limits
Hunter: We try to get designers to think about interface constraints from day one, rather than trying to do it piecemeal after the fact, which just never works, to be honest. We have a good buy-in from the designers.
Runner: In the past we've tried to force the issue that designers should also be DV engineers, in addition to micro-architectural design, RTL coding, timing analysis, synthesis, and documentation. It's not very feasible. But clearly, having designers participate in test planning is very critical. Design for verification is another key area. The problem is to figure out the right roles and responsibilities for the team rather than force designers to do verification.
5. Verification engineers can help the design effort
Ganguly: We were trying to define an architectural protocol, and we had architects, designers, and verification people all in the same room going through that protocol. The verification engineers actually had a lot of perspective and they could point out holes as the architecture was being defined. This cleaned up a lot of problems before they got coded in.
6. Specialized verification engineers need to step out of their silos
Stellfox: Verification is not just simulation. You've got virtual platform teams, software integration teams, emulation teams, simulation teams, post-silicon environments -these groups tend to be working in silos in the company, because they're specialists.
Ganguly: This verification continuum is, I think, the biggest challenge out there. Because of the complexity of our designs we can't do it all in pre-silicon, or emulation, or virtual platforms - we have to have all these working together in order to verify.
Runner: When you have completely independent organizations that don't interact, things become more skewed. If you have disciplined interactions like joint reviews, I think you start to coalesce.
7. Don't try to change too much at once
Runner: When you come in and try to throw a new methodology over the wall to people who have been there 10 or 15 years, it's tough. It's better to align yourself with people who get it and maybe try an initial project. Don't try to do too much.
Ganguly: You might want to start with a joint team including architecture, design, and verification. Once they have proven that it works, you can get more buy-in from the rest of the company.
All in all, this was a very thought-provoking panel that delved into a topic we don't hear much about - how company culture, organization, and management can ease the verification crisis. This discussion was long overdue.
Note: Scott Runner was also a speaker at the Designer Keynote at DAC. For a report on that keynote, click here.