The End of ASICs as We Know Them

A lot of wildly divergent things have been percolating in my mind with respect to ASIC and system design, and I’m ready to take a stab at pouring out the first cup to see how this brew looks. Here are some of the disparate elements that went into this blog entry:

• Jack Ganssle’s Develop Firmware…In Half the Time DVD
• This EDN article: Your chip in half the time? by Rajiv Maheshwary from Synopsys
• eASIC’s very recent announcement of its 45nm Nextreme2 zero-NRE ASIC
• A discussion about ASIC design that I just had with Tensilica’s Chief Architect Bill Huffman (sorry, no hyperlink for this one)

I put all of these disparate elements together and here’s what I get: The end is here for ASIC design as we know it. It really, truly is. ASIC-design teams simply cannot pretend that we’re designing the same sorts of chips that we designed in the early 1990s. You know, the ones with 200,000 gates. System-engineering economics have changed a lot since then and it’s time to unflinchingly recognize that fact and reshuffle priorities so we can get on with the job.

Let’s start with Maheshwary’s excellent article. Here’s a critical graphic from that article:

This graphic shows the pain points in ASIC design. The data is from a Synopsys research study “based on a number of conversations with engineering VPs.” The greatest pain, by far, comes from the inability to complete design verification in a timely manner. (Note that this conclusion echoes the sentiments of Mentor’s Wally Rhines, who has been saying that verification is the biggest problem in EDA today. Wally’s been banging this drum for a couple of years and he’s unquestionably right.)

Now why should that be true? Why is verification killing us? Well, ASIC designs get bigger with each new process technology node. Even though 50% or more of each ASIC is now devoted to on-chip memory, there’s still a lot of logic to verify on today’s 65nm and 45nm designs—literally tens of millions of gates. If that logic consists of all-new logic blocks, there is indeed a lot of verification to do and the situation only gets worse with each new IC fabrication node.

So what’s to be done? Here are Maheshwary’s recommendations from his EDN article:

Focusing on five key solution elements can help design teams move toward achieving 2x productivity. These elements are:

• Integrated design and verification platforms
• EDA tool runtime and capacity
• Access to quality internal and commercial IP
• Hardware platforms for pre-silicon software development
• Proven design and verification methodologies

Data from real customer projects demonstrate that each of these elements can mitigate project risk and accelerate time to results.

The first two points talk about EDA tools. I’m not going to discuss those because I don’t think those are the root of the problem, although they’re clearly important. I really want to talk about the third and last points because I feel strongly that the biggest problems are rooted here.

What is quality IP?

Maheshwary’s third point is that ASIC design teams need access to quality IP, whether it’s developed internally or purchased from a commercial IP vendor. Now here’s where a little tidbit from Jack Ganssle’s firmware-development presentation comes in. Jack says that no software function can be considered generic enough to be easily reusable until it has been reused three times.
 

Three. That’s a real, quantified number. Nothing wishy washy there. The number is three. When you first write a software function, even if you’re really trying to make it generic and reusable, you just don’t have the time to think about all the use cases. After three attempts to reuse the function, it’s finally been used and revised enough to justify calling it a reusable IP component.

I’ll bet the same number applies to hardware IP. After all, how much difference do you think there is between a function written in C and a hardware IP block written in Verilog? From reusability and quality perspectives, probably not nearly as much as you might think until you mull it over a bit.

And that’s the real difference between good commercial IP and internally developed IP. Good commercial IP has already been used to create real, working silicon—several times. You reduce your risk because someone else has already faced that risk for you. In addition, the commercial IP vendor must support that IP if they plan to stay in business. For internally developed IP blocks, the one person who wrote the code for that block leaves the building every night and the probability that he or she will return the next day is always less than one. (That’s another thing I got from Ganssle’s DVD.)

With that said, I do not think it will surprise you that ASIC design teams continue to be reluctant to use purchased IP, for a variety of reasons. By far, the number one reason in my mind is NIH—not invented here. Every hotshot designer worth the title knows they can design a better logic block than anyone else for any given function. It doesn’t matter if you’re talking about processors or video codecs.

Even though this NIH attitude is often wildly unrealistic, let’s grant this wishful thinking for a moment. Then, let’s go talk to the ASIC design team that has to use this block a year or two later. What you’ll find, most of the time, is that the internally developed IP block may very well perform exactly as it should in the application it was built for. However, you’ll also find that the block isn’t documented well enough or it’s not flexible enough to use in a new design.

You are also likely to discover that any required development tools (like the vital software-development tools for processors) are either hopelessly outdated or they’re not sufficiently documented to be useful to people who didn’t make the tools in the first place. This sad state of affairs directly connects to Jack Ganssle’s empirical number: 3.

That’s why most companies purchase processor IP from the major vendors. The processor cores have been proven, they’re well documented, and the tools are kept up to date. If any of those elements isn’t there, the IP vendor will not be around very long.

To the Wayback machine, Mr. Peabody

This now takes me back to the way things were back in the pre-ASIC days of the 1970s and 1980s. System designers back then designed logic blocks and entire systems using 7400 series TTL integrated circuits. Look at boards from the early 1970s and you’ll see fields of 14-, 16-, and 20-pin DIPs (dual-inline packages for you youngsters). No big chips on those early boards. Couldn’t get them. However, as system complexity increased, we started buying those 40-pin LSI packages because they represented big, proven (well, mostly proven) blocks of logic that saved us a lot of time and board space. Purchased 8-bit microprocessors (also packaged in 40-pin DIPs, then 16- and 32-bitters in 64 pins, then a whole lotta’ pins) came with assemblers, debuggers and—eventually—compilers.

NIH was certainly around back then. There were engineers who just couldn’t live with those commercial, general-purpose processors in 40-pin packages. Those people learned microprogramming and developed their own processor architectures using TTL and bit-slice chips. But most of us found ways to live with one or more general-purpose microprocessors and microcontrollers. EDN built its reputation on helping system designers pick from the various general-purpose processors and DSPs available.

Those of us who became system designers at the beginning of the 1970s after these bigger LSI (eventually VLSI) chips were starting to appear didn’t feel threatened by using those chips. We didn’t care if those chips used more gates to implement a function than we might have used for our specific application. Mostly, we didn’t even know how many gates there were in the package. For example, I didn’t care how many gates there were in the Intel 8251 USART, I just designed it into my system. The fact that I didn’t need to know how to design a USART to be able to put one into my system and that I didn’t need to verify Intel’s design was the reason I was buying their chip—to get their design expertise.

Driving verification time through the roof

To me, the one thing that must change before we can really start designing 21^st-century ASICs is the attitude that the ASIC design team must code every piece of logic on the chip by hand and then verify all that design. That attitude is the one that’s driving verification time through the roof. That attitude’s gotta go. Fast.

For that attitude to wither and die, we need to drop another very outdated attitude: every transistor is precious. It isn’t. Yet all too often we act like it is true. That attitude arose back in the 1-micron days of ASIC design when every transistor was precious, sort of. Well, not really. But if your design didn’t fit in one member of the gate-array family, you had to move up to the bigger one, if there was one, and that would cost you a lot more money just to get one more transistor.

In reality, if every transistor was precious, you’d size each individual transistor in the ASIC so that it was precisely as big as needed and no larger. We left custom transistor sizing (and disco) behind in the 1980s, but the attitude that every transistor is precious has stayed with us far too long.

What about cost? Wasting transistors drives up silicon costs. Yes, it does. But transistor costs aren’t the only costs in the engineering equation. There are also design and verification costs. There’s the cost of missing your market window. There’s the cost of letting your competitors get the jump on you even if you don’t miss your window. There’s the cost of designing something that cannot be used or adapted for the next-generation design. No design engineer can ignore these other costs. They must all be considered and balanced. To do otherwise is to ignore engineering fundamentals.

Help, I’m drowning

The real truth is: we’re drowning in transistors. The following graph is a conceptual diagram that plots the number of transistors on a chip versus the maximum system operating frequency for the IC process nodes currently in use and the one that’s in the near future. Note that you can get high system operating frequency or you can max out the number of transistors, but you can’t do both. As you put more transistors on a chip, the chip gets bigger. On-chip wire lengths get longer and chip capacitance goes up. Both of these factors drive operating frequencies down.

In reality, we never max out the number of transistors on a die for a high-volume commercial chip. Not at any process node. If we do, we drive manufacturing yield to zero because the chip is so big. We always compromise. We always design chips well inside the curves—never right on the curves. So the discussion isn’t whether or not to compromise, not really. It is how much compromise we will make. Accept this. Get real.

Here’s the next data point in this discussion. Everyone knows that ASIC design starts have been plummeting. This is a years-long trend. There are many reasons for this decline. First, when everything fits on one ASIC (making an SOC), you need fewer ASICs per system—namely one. EDN Executive Editor Ron Wilson’s excellent blog entry recently made this point. Next, it’s getting really expensive to design state-of-the-art ASICs. Count on many tens of millions of dollars for a 65nm ASIC. More for 45nm. That includes a million dollars or two for a full mask set. Economically, ASIC design is less and less attractive except for the most successful, high-volume systems. Ron Wilson also made that point in his blog.

Ah, but now let’s look at eASIC’s Nextreme2 announcement. The company says it has around 100 design wins for the 90nm 1^st-generation Nextreme structured ASIC and is now rolling out the 45nm generation. By zeroing out NRE and cutting turnaround time to a few weeks, products like eASIC’s Nextreme2 structured ASIC could restore the lost luster to custom silicon.

But look what compromises the Nextreme users are willing to make. To a first-order approximation, ASIC designers using the eASIC’s Nextreme as a platform are giving up a factor of two in both system speed and transistor count compared to full-on, HDL-coded, standard-cell ASICs. So what? They’re killing the NRE with its million-dollar mask costs and getting to market faster. There’s a real place for this sort of design compromise. The existence proof is right there.

What do you do with 20 million gates?

So eASIC’s Nextreme structured ASICs bring the ASIC fabrication-cost barriers down and makes ASICs attractive to more system designers. The question then becomes, “What to do with those 20 million ASIC gates?” If the design team plans to code every logic block by hand on a Nextreme2 ASIC, then the team should expect verification to be the number one problem, just like Maheshwary warns. Logic is logic. From a design perspective there’s precious little difference between logic implemented in standard-cell technology and logic implemented with Nextreme2 gates. The logic verification is the same.

If the design team wants to avoid verification hell, it had better find a better way to implement systems than creating 20 million gates of hand-coded logic.

That’s where IP comes back into this discussion. I maintain that 21^st-century SOC (systems on ASICs) design must take the same attitude that board-level system designers had in the 1970s and 1980s. The complexity levels demand this change. Proven, reusable IP blocks will consume the bulk of the logic on future ASICs, which will move verification from block-level verification to system-level verification. That move will be good for two reasons. First, we can perform system-level verification a lot faster than gate-level verification, especially using C-level models for various blocks. So, good purchased-IP blocks must include C-level models. Note: They already do.

Second, the design team can start system-level verification at the very beginning of the project, way earlier than for gate-level verification. After all, you need a gate-level design for gate-level verification. For system-level verification, you can literally start verifying design assumptions when you’ve got a system block diagram and good-but-rough descriptions for the behaviors of each block. Expect to see verification times plummet like a rock when the industry starts embracing this approach to system design.

I expect to see a flowering of systems design and the rise of true system architects. I expect to see system architecture flourish.

Finally, let me return to Maheshwary’s final point: ASIC designers need to use proven design and verification methodologies. I agree with the bit about “proven design methodologies.” The system-level design methodologies I’ve been discussing here were proven for logic design 20-30 years ago. They were temporarily abandoned when gate arrays burst on the scene and buried with the rise of Verilog.

It’s time to dig them up again. We’re gonna’ need them.