It’s not uncommon to hear engineers express disbelief these days that a complex device actually works. This is both a sign of amazing advancement in system-level design, as well as a scary revelation that’s surfacing from all parts of the design world.

What’s behind this uncertainty is the growing complexity of devices, which has moved design well beyond the comprehension of a single engineer—no matter how good they are or how many pieces they understand—and increasingly even beyond the capabilities of a team of engineers. There are simply too many parts, too many interactions, and too many lines of code to understand it all.

It doesn’t help, either, that IP, subsystems and abstractions are black boxes. No matter how much we try to get comfortable with black-box technology, it still creates an element of doubt that the final product will work as planned. The engineering community is very comfortable with things they understand. They’re far less comfortable taking someone else’s word that it works.

Perhaps even more daunting is the verification piece. With roughly 50% to 70% of the design NRE still in verification—both software and hardware—there is a lot of pressure to reduce costs and cut time to market. Verification is the single biggest target for achieving both. But there also is more to verify, which forces verification teams to rely more on pre-verified IP and software written by other teams who often don’t speak the same language, both from a technology standpoint and literally.

How it all works together is at best an educated guess, and as devices continue to grow in complexity so do the question marks. This isn’t going to get any easier, either, particularly as blocks of IP and software give way to complete subsystems and chips. While this all works better in theory, it also moves the pieces further from the individual engineering teams and re-introduces a virtual silo behavior.

The one link across all of this will be verification. But it remains to be seen just how complete that verification will be, what skills will be necessary for verification teams, and whether the complex products created by an ecosystem really can work flawlessly—particularly in light of some recent failures by some of the most successful IDMs.

–Ed Sperling

One of the most intriguing trends to watch these days is in the area of diversification and differentiation. As we emerge from the worst downturn in the history of semiconductor design—in fact, the only time EDA has ever shown negative numbers other than accounting changes—companies are looking for new avenues of revenue growth that are significantly different than where they drew their revenue going into the downturn.

There are five very good reasons for this:

1. The downturn has shown many companies they need to be hedged across multiple markets if they want to continue showing growth in future years. Because of the convoluted supply chain, which is spread across continents and across different design cycles, not all parts of the design chain feel the pinch at the same time. As a result, we’re seeing moves into a variety of areas such as Mentor pushing into Android devices and Synopsys moving into software prototyping.
2. Not all parts of the industry are poised for significant growth in the future. There will jam-up of competitors in some areas because there are far fewer design starts. While the design starts that do happen will be bigger and more complex, there will be fewer companies developing them because of the cost. In addition, there will be less creativity in other areas that were consistent revenue sources because rising complexity coupled with a lag in lithography technology is forcing more restrictive rules on designers. Just to get chips out the door at 32nm and beyond will require more regular shapes and layouts, which doesn’t bode well for a slew of players fighting for a shrinking place and route market.
3. The value has shifted from just hardware or software to hardware and software. Co-verification, software modeling and prototyping and even operating system and some application development is being done by chipmakers. Companies that can bridge these two worlds effectively will reap bigger rewards than those doing the same thing they were doing two years ago.
4. The pain points are getting more granular. While SoC design is moving to a higher level of abstraction, verification has more things to test. The models work great for blocks, but now those blocks have to be tested, as well. And they have to be integrated and share resources, particularly in multicore chips. Add in various power modes and power islands and complexity goes straight up and off the charts. That also has created new opportunities for startups to gain entry into the industry, and the big guys are struggling to either absorb them or compete against them.
5. There is growth in tangential markets, and far better security in reaching beyond the classic EDA world. Mentor’s push into DFM and test, mechanical analysis and wiring harnesses is a case in point. Synopsys’ push into IP and high-level synthesis are well beyond its normal flow. Even Magma has pushed into analog and mixed signal place and route.

As we emerge from this downturn—and we are still not fully emerged—these moves are likely to become even more pronounced. What is uncertain is just how the industry will look when these changes take root.

–Ed Sperling

Last week’s blog on OVM vs. VMM was like a match on dry timber, which is probably a bad analogy to make in California these days. Weeding through the comments—both on the record and off, and there was plenty more off the record—it appears there’s plenty of work under way to bridge the two worlds, but there’s an inverse amount of information available to the people who use one or the other about those efforts.

Information kept in the hands of a few doesn’t help an industry progress. In fact, it sounds like something out of the movie, “Dr. Strangelove.” So as good responsible citizens of the design world, we’ll certainly help in that regard, both by providing a forum for discussion and identifying what’s changing.

That said, there’s a potentially even bigger issue brewing here. Communication seems to be a problem in the verification world, and that’s only going to become more of an issue because verification engineers have one of the hardest problems to solve in system-level design. There’s a reason that 70% of the time it takes to get a chip from concept to tapeout is spent in verification, and that’s only getting worse as we deal with more cores, more power domains, more voltages and mixed signal functions.

The problem is that verification engineers are considered after the fact, even though they represent the majority of NRE costs. For years, verification was a step taken after the design was already done. It now needs to be moved way up in the process to the point where verification is considered at the architectural level, along with whatever functions marketing wants in a device and what the power budget will be. In some cases, that may require IP up front to allow verification, and in others it may require tweaks to the design itself to make sure it can be verified quickly.

There will always be surprises in any design, and there will always be points in the design cycle of complex chips where brute force is necessary to meet deadlines. But communicating across the various stages of design with all groups that need to get involved has never been a particularly strong point of any team, and it is only made worse now that very few companies have their own fabs. That needs to change.

What do you think?

–Ed Sperling

For all the talk about VMM vs. OVM and how it doesn’t matter…well, apparently it does.

It’s not that one verification environment is so much better than the other. That’s like saying one religion is better than another. People kill each other over those kinds of statements. And the truth is, there are plenty of people who will argue for and against each side.

Strangely, when you really dig into this, you’ll more than likely never get a straight answer because most people don’t know both methodologies. They learn one and that’s complicated enough for most mere mortals.

But complexity is getting to the point even at the most mainstream process nodes where verification headaches are becoming overwhelming. More transistors, multiple cores, multiple power islands and various on, off, and sleep states makes the need for better verification methodologies, languages, and base classes almost essential for debugging these designs. And it doesn’t help when there are different people in an organization with expertise in different methodologies.

There has been talk about bridging the two environments, matching data types or wrapping code. But so far, there has been little progress in this arena and the time needed to verify increasingly complex designs grows accordingly. Where are those corner bugs hiding? You’d prefer not to find out after a product is already out in the market.

It’s time this issue came out in the open instead of being stuck in standards groups. In the past, who used what verification methodology didn’t really matter. But it matters now, and the verification problem is only going to get worse.

What do you think?

–Ed Sperling