HILLSBORO, Ore. -- The rustic setting at Intel's Jones Farm Campus, here, belies the feverish activity under way inside the facility's semiconductor validation laboratory. Buffeted by the disclosure of two Pentium-related bugs last year--and with lingering memories of the infamous Pentium FDIV floating-point flaw of 1994--Intel in recent months has dramatically increased its efforts to develop improved t echniques to stamp out glitches before microprocessor designs hit the fab lines, according to company sources.

On the immediate agenda is the task of buzzing out "Katmai," the beefed-up MMX processor that's expected to hit the market by year's end. But the toughest verification challenge Intel has ever faced lies dead ahead: the job of wringing all the bugs out of the new IA-64 architecture and its companion 64-bit Merced microprocessor, a highly parallel design of unprecedented complexity which is due for release in a scant two years.

"Verification is a major issue," said Gadi Singer, general manager of design technology for Intel Corp. (Santa Clara, Calif.). "The logic complexity of the new designs is growing very fast. The new microarchitectures have multiple execution units and there's more parallel work. So, if you look at all the possibilities verification has to test for, it becomes more difficult to cover all the bases."

Indeed, the growing complexity of CPU designs raises the specter of a n industry-wide semiconductor verification crisis. With integrated-circuit transistor counts expected to top 50 million within two years, many industry experts believe the tools to ensure that such designs are free of flaws don't exist now and won't for years to come.

"A verification team today is the size of what an entire microprocessor design team was 10 years ago," said David Ditzel, president and chief executive officer of semiconductor startup Transmeta Corp. (Santa Clara, Calif.).

"If you look at verification from the inside out--driven by the requirement to test every block of logic on-chip--as the chip grows geometrically, that task gets tougher," said Michael Slater, principal analyst at MicroDesign Resources (Sebastopol, Calif.). "In Merced, you're going to have two instruction sets, so there's a much more complex set of test-vector requirements. Moreover, in Merced, the compiler will do a lot of the dependency checking, so in some sense the job of verification will have to extend all the w ay back to the [software] compiler."

Intel's competitors, too, are caught in a verification vise. "You're not going to make an X86 processor without errata," said Glenn Henry, president of Centaur Technology (Austin, Texas), which last year unveiled its first CPU, a low-cost Pentium-class clone called WinChip C6. "In fact, the X86 stuff is so ugly that you can't get away from errata--but that doesn't matter. The real standard you care about is, will it run on a PC. Today, people are putting out microprocessors that pass this test."

Indeed, the twin driving forces that could bring the crisis to a head are Intel's effort at the high end to verify IA-64 and Merced, and attempts by numerous X86 competitors to verify ever more sophisticated X86 offshoots replete with multimedia enhancements, sophisticated power-management units or beefed-up translation-lookaside buffers.

The upshot is a microprocessor design environment in which, before the decade is out, verification could become as much--or perhaps m ore--of a competitive selling point as CPU performance and clock speed are today.

"We believe that the technology and the knowledge required to do verification right will be a differentiator among companies and will be a competitive advantage for Intel," said Intel's Singer. "We think Intel will have an advantage, not just because of our design techniques, but because of the ability to put together a complete set of complementing technologies that will allow our designs to be more reliable."

Currently, microprocessor design teams attack the functional-design part of their project with tools ranging from register-transfer-level simulation to cycle-based simulation and IC emulation. Static-timing analyses are also performed to trap timing errors.

Further downstream, verification techniques include the use of logic-simulation software and IC-emulation hardware to detect design errors. Formal verification, a software discipline based on mathematical proofs, has only just begun to move into the mainstr eam. In the commercial EDA world, the first wave of formal tools have hit in the form of products from vendors such as Abstract Hardware Ltd., Avant!, BLDA, Chrysalis and Verysys. Synopsys Inc. is also expected to field a tool in the near future.

For its part, Intel is firmly established as one of the pioneers of the methodology. The chip maker has deployed some of the first formal tools, developed internally, to help verify its Pentium II microprocessor.

But formal verification isn't the whole story. A variety of other methods--some conventional, some seat-of-the-pants, some decidedly unusual--must be employed. For example, in the verification lab at Jones Farm Campus sits a focused ion-beam system made by FEI in Hillsboro, Ore. (FEI is owned by Philips Industrial Electronics International.) The $1 million i-beam machine is used to gingerly burn new vias on prototype silicon in those instances where problems can be corrected without having to change a mask. The technique can be used, in a limited fas hion, to add or remove selected gate sequences from on-chip logic blocks.

Though far costlier than simulation, working with real silicon is a technique many experts swear by when it comes to swatting bugs. "I'm a big believer in prototype silicon," said Centaur's Henry. "No tool is good enough to allow you to build an X86 by simulation alone."

Nevertheless, it's something of an open industry secret that some bugs will find their way into the final product. Tacitly admitting as much, Intel recently lifted the veil on a feature called "BIOS Update," which enables CPU microcode to be patched via software after a processor has been shipped, thus enabling some--though not all--bugs to be corrected.

Microcode is the most elementary form of machine instruction, controlling actual operation of the CPU. Patch-ing or revising microcode is the most desirable way to fix a bug, since it does not require expensive hardware mask changes.

However, flaws that involve the use of physical silicon resources can 't be corrected simply by updating the BIOS.

The BIOS Update feature has been present in some form in a number of Intel CPUs for several years; Intel won't comment as to whether it will appear in Merced.

Meanwhile, the debate rages on as to whether microprocessor complexity has in fact outstripped the ability of verification tools to detect flaws, thus making completely clean designs all but impossible.

"I think it's impossible to do it [formal verification] on something of the complexity of Merced," said Centaur's Henry. "I believe that it's going to be very difficult to formally verify an IA-64 design."

Indeed, Intel's Singer admitted that formal verification alone can't ensure that a design is bug-free. "You have to use a combination of things," he said. "Formal verification is one component. There's gate-level verification. There's all kinds of heuristics. Application-level verification. A combination of the methods that we know of today has to be applied. And it has to be a smart combinat ion, so that you know which areas are best addressed by formal verification, which areas are best addressed by application-level."

Successfully applying that mix to Merced will be crucial if Intel is to avoid being buffeted by bug disclosures. "The ramp of new products into the market is faster than ever," said Singer. "You no longer have a year to get to 100,000 units--a situation where you might be able to do some of the verification with the customer base. This means that, when we first deliver silicon, it has to be absolutely clean. It has to be clean from day one."

Perhaps only half facetiously, analyst Slater put into perspective the reality that Intel may have to turn the page on some past anomalies. "For IA-64 they have a new architectural opportunity to define bugs as features," he said, referring to rare, unusual or undefined instruction-set interactions. "They can put work-arounds into the compilers. All of the RISC processors did this in their days."

A second part of this feature, "CPU clone-makers wrestle with X86 compatibility," will appear here on EE Times Online www.eet.com next Wednesday.

  Go To Previous Story

Go To Next Story  

Back to This Week's News