Most chip architects and engineers couldn’t give a whit about the difference between deep ultraviolet and extreme ultraviolet lithography. It’s traditionally been a problem that foundries had to wrestle with, and that was their problem. Even DFM has been slow to catch on because what’s done in a foundry is of little interest up front.

The separation of those two worlds worked fine above 65nm. Architects and foundries had little in common other than their goal to get chips out the door, and architects typically dictated what needed to be done. At 45nm they became much more equal in their say of what could be done. And at 28nm and 22nm, it’s about to turn into a completely different kind of relationship, where the foundry rules dictate what’s has to be done at the architecture level to get a chip out the door on time.

The problem this time is the inability to etch fine enough lines with deep ultraviolet lithography. At 193nm, it doesn’t come close to providing the granularity needed at 32nm or 28nm, depending upon who’s defining the next process node. Immersion lithography doesn’t solve it either. That means the short-term solution is double patterning, which adds significantly to the mask cost, the time it takes to churn out wafers, and the overall cost of devices.

It may take three to five years before we see EUV, which uses a 13.5nm wavelength. Until then, expect the fabs to be far more in control of designs, dictating what can be used, how it can be laid out, and what the parameters will be for defect density. And expect to see more and more companies hanging back a generation or two on the Moore’s Law road map until this gets resolved.

Seeing the light was supposed to be a good thing. Now it turns out there are different kinds of light, and not all of them are equal.

–Ed Sperling

Rising complexity at each new node may require a different skill set for design engineers in the future. What exactly needs to be included in that skill set remains open to debate, and it probably will continue to evolve. But there are some clear trends emerging.

First of all, there’s the software. While software engineers can write code, hardware engineers who understand programming can do it better. I’ve heard that from engineering managers, system designers, professors and even some software developers. The reason is they understand how the hardware utilizes the software, while most software developers write code to the available interfaces. There’s a reason why Intel has been working so closely with Microsoft to make the operating system more efficient.

But if you train engineers to write software, then something has to give on the hardware. You can’t do everything. There are only so many people on a design team, which leads to step number two. Models are essential to absorb some of the complexity in the design process. You don’t have a better design (usually) because you draw the project out by hand or do manual place and route. You have a better design because it draws less power, costs less, and reaches tapeout on time or, better yet, ahead of time.

And you generally get much better rewards when you figure out ways to tweak your design for derivatives and new features without having to do many pieces from scratch because your hand-drawn model isn’t flexible enough or your simulation doesn’t allow for changes.

The bottom line: Some people need to re-learn everything, but everyone needs to re-learn something.

–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