The Pentium Chronicles: The People, Passion, and Politics Behind Intel's Landmark Chips (Practitioners)

by Robert P. Colwell

  The question is how to speed up the project’s conceptual phase while attaining the same goals as before. One proposal that just won’t stay dead is to have a specialized team of researchers and architects, whose sole job is to anticipate the microarchitecture and feature set that some future chip will require, and have that design ready by the time the design team becomes available.

  I hate this idea.

  Who are these people who can see even further out than the usual chip architects? They are the same chip architects, who, much to their dismay, have been unceremoniously yanked from another design project. How does that simple reassignment help anything? It certainly cuts the close ties to the design team that might otherwise have been possible. Granted, this estrangement could, at least in principle, help some architect see something promising he might have overlooked, but it’s also highly likely that architects, working alone and without designers to keep them honest, will make some fundamental assumptions about die size, power, circuit speeds, or design effort that will force a restart to the architecture work anyway.

  While these architects are off working on basic research for a future chip, who is finishing the existing designs? The temptation is always strong to pull the architects themselves off a project once it has taped out, but I think that is a mistake. They can productively spend part of their time on current designs, and part in concept development meetings. Many architects would rather spend their time dreaming up new ideas for future chips than facing daily reminders that not all their previous ideas worked out the way they had hoped (which is a really good reason to keep them engaged with the current design).

  Another reason advance development does not work is that these teams tend to be like the United Nations. Everybody wants their interests represented or, better yet, unfairly biased toward them if possible, and researchers quickly find that they have many masters. In a short while, realizing that no single solution will satisfy the logical union of all requests, they begin to examine the politics. If they can’t satisfy all their masters, it is prudent to identify the most important ones and at least make them happy. Even this is problematic, however, because the folks with the power today might not be the ones who have it in five years.

  Advance development thus produces imponderables that require leadership to define a useful path. And where will that leadership come from? From one of the masters, of course. Under these conditions, the advance development team can easily spend lots of time employing high-powered engineers and yield essentially nothing, doomed from the start by the lack of clear mission and goals.

  Not that all research efforts must have this gloomy end. Advanced development can productively investigate new features that require specialized knowledge of the field, such as security or encryption engines. Requiring chip architects to do this investigating is inefficient, at least with the intense schedule of a chip development. If done properly, the advance development team can draw a map of the technical possibilities, indicating which feasible points match the requirements for that feature. With this expert tutelage, the architects can quickly and with low risk incorporate new features into their products.

  Coding, Egos, Subterfuge

  One thing that attracts certain people to engineering is that they can objectively evaluate a healthy fraction of everyday ideas. These are issues with concrete answers, and people agree that they have concrete answers. They are not a matter of opinion, personal philosophy, or religious faith.

  Many of the same people who insist on objectively provable answers will engage with apparently unlimited fervor in topics for which there are multiple feasible approaches with no commonly accepted means for numerically resolving them. Typically, two or more camps will emerge, both of which believe the issue at hand really can be resolved objectively if only the other side were not so illogical and obtuse.

  Old-timers will recognize the choice of Unix editor as being one of these topics. To some, the simplicity and unpretentiousness of the vi editor was the only right choice; to others, it made sense to enter the emacs universe and never leave it. PCs or Macs, Intel or AMD, Windows or Unix-all attract the unresolvable fury that intuitive certainty engenders.

  Coding standards is another such topic. Professional programmers who collaborate on a design project must at some point reach a working consensus on languages, interfaces, overall product architecture, and so on. Because they know that achieving such a consensus is essential to the product’s success, they push to find a useful common ground.

  Early in the P6 project, several of us set out to write a simulator that would validate some of the key microarchitectural concepts we were considering. On day two of this effort, we discovered that we had five (or possibly six) different ideas of what constituted readable, maintainable C code. One person had been trained to make his code look like Kernighan and Ritchie’s classic C book [30]. Another believed white space was a resource to be rationed and that indenting was worth at most one space on the next line, and sometimes the next line part was optional.

  Some of us realized it would be better to try to converge on a viewpoint at the beginning of code development, not after writing lots of widely disparate code. So we convened one of the more rancorous meetings it was ever my misfortune to attend. The size of the indignation evinced by nearly every attendee was obviously out of proportion to the gravity of the issue. Eventually, it became clear that the problem was not a technical or even a rational one. In effect, we were not really trying to mutually determine the best compromise between our differing ideas on what constituted good-looking C code. The issue, clearly (albeit subconsciously) perceived by all, was that in the absence of data, opinion and intuition would decide, and nobody wanted to defer to anyone else on that basis.

  Then I had an inspiration. We all go through stages of computer maturity when learning computer science and programming. At first, the computer strikes us as really obtuse and stupidly designed, and then positively malevolent, as though it is actually sentient and working very hard to make our lives miserable. Eventually, the student outgrows this feeling and no longer takes it personally when an attempted compile generates a long list of error messages. In effect, the student learns that the computer is simply following its internal rules and has no opinion about that student whatsoever, so it is clearly a waste of indignation to react to it emotionally.

  I decided to use this learned behavior to help channel coding conventions toward an acceptable common ground, while also defusing the personality conflicts that were fueling useless style debates. I proposed that all coders had to filter their code through the Unix “lint” tool before it would be accepted. If the filter did not modify the code, then the coding convention was being adhered to. If the tool complained, the coder was required to alter his code accordingly. Even though the particular flags that governed the lint tool’s scrutiny were themselves selected by one of us (me), the coders did not feel devalued, because they were conditioned to resignedly accept what the computer wanted.

  Why did this subterfuge work so well? All the participants had well above average intelligence; they knew the scam that I was perpetrating. It worked anyway because it allowed all egos to back out of the conflict without visible loss of face. It moved the conflict from “who knows best,” which can be resolved only by anointing one coder above all others, to a mechanical means for homogenizing the code to a mutually acceptable level. Paying attention to this kind of human dynamic has many other applications in a long, large design project.

  The issue was that in the absence of data, opinion and intuition would decide, and nobody wanted to defer to anyone else on that basis.

  3

  THE REFINEMENT PHASE

  The Pentium Pro, launched by Intel Wednesday, is now the world’s fastest. But apart from sheer speed, it offers nothing that isn’t already available.

  A TV anchor introducing P6

  “Apart from sheer speed … ?” What did that TV anchor want his microprocessor to do, tap dance wh
ile juggling spinning plates and singing “Georgia on My Mind”? A computer’s processing speed is its raison d’etre. With few exceptions, it is the additional computational “horsepower” of each new generation that allows new usage models and system features. The TV anchor in question was betraying his near-total lack of understanding of what computers are and how they do what they do.

  But he was also inadvertently revealing how buyers view our products. It’s easy to get so wrapped up in the technology that you lose sight of how buyers will eventually judge your efforts. Few buyers will be motivated by your slick design. Most care only that the product adds value to their lives. It is extremely difficult to make a chip design run faster, so difficult that you become fixated on the task and forget that speed must translate into tangible benefits to the buyers or the chips will not sell.

  This is perhaps the main difference between the concept and refinement phases. The concept phase has generated a few ideas that look promising. The refinement phase must now evaluate them against the project goals, including their appeal to potential buyers.

  In that respect, the refinement phase is a bridge between the concept phase’s blue-sky, anything-goes brainstorms and the realization phase’s nuts-and-bolts schedule pressure. During this phase, architects are still happily juggling several castles in the air, but they are no longer trying to invent new ones. The point of the refinement phase is to settle on the most promising idea that appears to meet the project goals and make it the project’s formal plan-of-record (POR).

  It is not easy to choose from among possibilities that the team has spent months identifying. Senior technical leadership has weighed each proposed direction carefully for its ability to create products that satisfy the major project goals. If all have passed this level of scrutiny, how do you refine the selection further?

  There is also the matter of ramping up from the very few concept phase engineers to the team of hundreds who will realize the design after refinement. Finally, to help design team management, the refinement phase should identify which parts of the skeletal design are likely to be the most difficult and which might be easy (perhaps borrowed wholesale from a previous design). The design manager can then assign the best or most experienced designers where expertise is most needed.

  OF IMMEDIATE CONCERN

  For P6, the identification and assignment process worked reasonably well. On the basis of what we found difficult in the concept phase, we architects guessed what would be most difficult in the logic and circuits, and the best designers found themselves assigned accordingly.

  Who wants to work over the weekend if it means losing 20% of your engineering troops to those who cannot seem to keep up?

  This assignment is not static, however. For many reasons, some parts of the overall design reach maturity before others. Project management must then borrow engineers from the leading units and reassign them to the laggards, because the project is not over until the last unit is finished. This can feel to the leading unit owners like punishment for doing their jobs well, which is likely to damage morale. Who wants to work over the weekend if it means losing 20% of your engineering troops to those who cannot seem to keep up? Project management must keep a constant focus on the “leading edge of the wave” so as to reward and recognize units that are out front. Units that have fallen behind can then measure the lag and plan ways to catch up.

  It is also crucial for project managers to correctly identify why units have fallen behind. The reasons are not always strictly technical. For example, late in the P6 development, the validation manager and I were analyzing the latest validation results and were discussing why one unit seemed to be generating the most design errors when a neighboring unit that we had worried about seemed to be doing fine. We had not expected the unit in question to be so complex as to generate such results. After investigating the engineering-change-order (ECO) trail, the validation bug pattern, and the intrinsic microarchitectural complexity, the answer began to crystallize: The leader of the unit that was doing fine was a conservative, down-to-earth engineer who did not hesitate to ask for help from an architect when he was not sure exactly how his unit should behave under all corner conditions. At the head of the unit in trouble was an engineer determined to make his mark on the project and show that there wasn’t any level of intellectual complexity he couldn’t handle; he never once asked for help. Given enough time, he probably could have succeeded on his own, but there wasn’t enough time. We imported a set of experts into that unit, fixed some things, removed some complexity, and got things back on track.

  The concept-to-refinement project transition is a subtle one. It’s not like throwing a switch. One day you’re dreaming up new ideas, and the next you’ve picked one and tossed the rest out. It’s more of a gradual zooming in on the ideas that look most promising so that the ensuing, more intense focus can identify the one idea that will carry the project to victory.

  SUCCESS FACTORS

  As I described in the previous chapter, quantifying opinions with data is vital to this process. Project leadership must acquire or develop tools and teach the team members how to use them. In this way, a common language and a common data-driven culture evolve, in which to test the team’s ideas and absorb the best ones into the project’s POR.

  On the other hand, you cannot resolve everything with data. Some issues might require too much time, programming, risk, or more market data than is reasonably available, so to be successful a project must rely on intuition as well. Multiple perspectives are also key to success in this phase, and during this time validation and product engineering can provide useful insights. Finally, complexity on the scale of P6 requires both planning and careful modeling if the design is to avoid constant rework.

  Handling the Nonquantifiable

  Multiprocessing (MP) capability was not in the original P6 project goals, but the original P6 architecture manager, Fred Pollack, had an MP background from previous projects and once we had some promising directions from the concept phase, he urged us to consider what it would take to make P6 an MP design. Senior architect Glenn Hinton realized that one outcome of our performance-driven choice to put the L2 cache on the CPU’s backside (not connected directly to the frontside bus) was that the CPU had become selfcontained enough that making it an MP design was now feasible. We then took it upon ourselves to investigate what an MP design would mean to the frontside bus, concluded that it looked doable within project schedule and die-size constraints, and adopted MP as a new project goal.

  Changing a project’s goal in midstream is a delicate matter.

  Changing a project’s goal in midstream is a delicate matter. On the one hand, there’s a strong argument not to. It’s much simpler to identify the right project targets early and permit no distractions while the project is en route. On the other hand, there’s also a strong argument for being flexible. Design projects are long, with enough time for exigencies to arise and for the team to learn things midway through the project that they did not know at the outset. If you resolutely ignore such discoveries, but your competition finds a way not to, their product may turn out to be considerably more compelling than yours. With MP, I believe we did exactly this to AMD, for example.

  How do you decide whether somebody’s midstream brainchild is worth the risk and additional effort? It’s a judgment call that must be made with the cooperation of management (who must sign off on the extra schedule pressure and die size), marketing (who must estimate the size of the additional market made available by the new feature), and, most important, the design team. If the project leadership can sell the new idea to the design team and get them excited about it, that new idea is off to a great start. If the design team feels that the new feature is being imposed on them against their will, its odds of working as envisioned are considerably reduced. Team morale will suffer, as well as their confidence in their leadership.

  Design teams like data. If they can see why the new feature will make a more profitable product,
their assessment of its implementation difficulty will be noticeably more optimistic. Unfortunately, many such decisions must be made when there really is no data to support the vision.

  Adding instruction sets is another area that is hard to resolve with data alone because data is hard to get or only partially useful. Company engineers (not those of us on P6, although we contributed) proposed the original MMX instructions because they understood that certain programs would benefit from instructions that performed simultaneous parallel operations on related data. They also knew that implementing these instructions would cost considerable die area, so their task was to convince the powers-that-be that the tradeoff was worth it. Their first two attempts to get this new set of instructions into the x86 architecture were denied on three grounds: no user demand; too much heavy lifting would be required of marketing, compiler, and tools efforts by Intel and the industry; and the die-size increase, however tiny, was unacceptable.

  What compelling data could they use to refute these allegations? Of course there was no user demand; the proposed instructions weren’t there yet. The question really was, “If we build them, will users come?” To answer this, the engineers could easily gather some data about applications rewritten to use the new instructions, and the performance advantages quantified and considered in the decision to use them. Naively, we pointed out that the MMX instructions would substantially speed up certain voice recognition algorithms. Unfortunately, the executives had grown irremediably jaded with regard to the speech recognition promise, having heard for years that this technology was almost ready (and would spark a huge uptick in demand for fast CPUs). In the end, however, the engineers prevailed with assurances that no one would perceive the x86 instruction set as dead, but the competition certainly might drive a new set of instructions first and then we would have to follow. On the basis of these inherently unquantifiable concerns, the executives finally accepted MMX.