Being involved in a major microprocessor design project like the P6 feels exactly like that except for the passage of time. Most ocean voyages do not take the 4+ years we invested in the P6.
From the beginning, my publisher wanted to title this book “The Pentium Chronicles.” I was initially skeptical. When I hear “chronicle,” I immediately think of a history, and I am no historian. But the second definition of chronicle, “narrative,” fits exactly with what I envisioned for the book-a series of events as told by a P6 insider. So, reassured by this definition and the publisher’s prediction that Pentium Chronicles would have the majestic draw of Lord of the Rings, I acquiesced to the title (as long as Orlando Bloom plays me in the movie version).
WHAT YOU WILL FIND HERE
The substance of this book, its heart blood, are the events that taught me something about the craft of computer design in the context of a large company. Most of the narrative centers on events surrounding the P6 project, with some devoted to the Pentium 4 project as well. I had several reasons for focusing on P6, but the main one is that the project is far enough in the past that I can confidently avoid its intellectual property issues. The Pentium 4 project is still too recent; I cannot yet disentangle the general engineering lessons we learned there from the specific product context.
You will find real names in this book, but not in every instance. My policy on real names is simple: I refuse to purposely show any specific engineering colleague in a negative light. My intention is to use real incidents and events to illuminate the general engineering methods; it doesn’t matter who made a particular mistake. What matters are the conditions that led up to a particular design or project error, and how someone might prevent a similar occurrence in future designs. We all make mistakes-that’s one of the book’s major themes. Our designs have to work flawlessly despite us.
But I will use real names in other cases. One major reason is to avoid giving the impression that I was solely responsible for the outstanding engineering being described. The P6 project had many more than its fair share of brilliant engineers, and credit should go where it’s due.
Parts of this book may come across as my personal treatise on how to do technical project management. It is not my intent to compete with the mountain of “how to do project management” tomes in existence. I learned more from my talented and dedicated design manager partner, Randy Steck, than I did from the dozen or so project management books I read along the way. My intent is simply to describe what we did in the P6 project and how it worked out-the bad along with the good.
I believe that in any well-intentioned, well-run engineering endeavor, choices will be made among multiple plausible options, some of which will turn out to be brilliant, others not. We should always learn from our mistakes, but if we are striving for excellence, we should also consider the triumphs and tribulations of others. I sincerely hope that by exploring lessons from the P6 and Pentium 4 projects, this book provides a way to do that.
HOW THE BOOK IS ORGANIZED
I wrestled with the question of how best to present these lessons. I could simply describe what happened in the project and let the reader draw inferences as needed. But then I would be guilty of breaking an important rule I learned as an engineering manager: Never let an engineer get away with simply presenting the data. Always insist that he or she lead off with the conclusion to which the data led. The engineer’s job in that presentation is to convince you that he reached the right conclusion. If he or she cannot draw a conclusion, or will not, then either the work or the engineer lacks the maturity to justify making the presentation at all.
I could also write a book that consists only of the lessons learned, with anecdotes provided to buttress the case where necessary. The trouble with that approach is that it might become boring, pedantic, quite possibly pretentious, and would push the book into the already overpopulated camp of how to manage design projects.
I decided to seek a middle ground, one that relies on actual events for its authenticity and immediacy, but is heavily seasoned with what I personally found important and educational about the events’ outcomes. My aim is to make that narrative compelling, and if it falls short in places, then at least it will be entertaining.
Readers who know me, who have heard me deliver technical talks, or who have read my columns in Computer, the IEEE Computer Society’s flagship magazine, know that I hold lots of opinions on pretty much everything, including other projects and product lines within Intel, other microprocessor design firms, the future of the industry, and so on. You won’t find me expounding on those topics at great length within these pages. Read the column and go to the talks. A book stretches my plausible deniability safety net just a little too far.
Having arrived at my middle ground, I was then faced with how to build on it. The most natural way was to present the P6 project chronologically, so the book is mostly organized in that sequence, although it is hardly linear. P6 was a big project that started with one person (me), grew over several years to 450+ people, and then eventually decreased to zero staff. In between were waves of concurrent activity. For the first year or two, the project was a handful of chip architects conceiving and documenting a general approach that would realize the project’s overall goals. Meanwhile, a design team was being recruited, organized, and trained so that it would be ready to hit the ground running when the architects were ready. Two validation teams, presilicon and postsilicon, were also recruiting, training, and writing tests for the day when they were needed. Other groups were trying to anticipate the requisite manufacturing production challenges and what could be done to ameliorate them. Marketing was preparing their campaign strategies, marketing literature, and promotional materials, and setting up customer visits to validate the architects’ design feature choices and to inform potential customers of what lay ahead on Intel’s product roadmap. Try plotting all that on a single line.
At the P6 project outset, we were charged with designing a new microprocessor for Intel. But before we could start thinking about how transistors could be organized, we had to consider how the project would be organized. P6’s first architecture manager, Fred Pollack, and P6’s design manager, Randy Steck, came up with an initial division of labor and made judgment calls about overall team sizes and effort allocations. It’s also clear in retrospect that Fred, in particular, was a masterful corporate diplomat, keeping the existing corporate antibodies from killing or damaging our project, back when we were a bunch of unknowns proposing odd plans and slinging scary-sounding phrases like “out-of-order microarchitectures” and “glueless multiprocessing.” Even early on, Fred gave us the freedom to roam, and trusted us to come back with something worth keeping.
The basic steps that the P6 project would have to accomplish were reasonably clear: conceive a micro architecture, do the detailed chip design, debug first silicon, and drive the chip into production. You can map these steps informally into microarchitecture conception, writing the structured register-transfer logic (SRTL) software model, and debugging early silicon. But looking at the project with the benefit of hindsight, I believe it’s more useful to view it as four phases: concept, refinement, realization, and production. Consequently, these four phases constitute most of the book and can serve as a kind of framework for any large chip-development project.
Naturally, not every lesson stems directly from the P6 project. Any undertaking is influenced by its environment, and the P6 project was no exception. The book is filled with lessons about how teams, corporate policies, and even location can affect a project’s effectiveness.
As a final chapter, I couldn’t resist including some of the more interesting questions that I’ve been asked over the years.
FOR THE RECORD
I dreaded writing the following section. I knew I couldn’t do an adequate job of acknowledging the indispensable contributions of hundreds of people, and only a few words to those I explicitly name isn’t nearly enough. I cannot do justice to all who contribute
d to the microprocessor developments outlined here. Just listing all the names would make the book twice as long and still would not be sufficient recognition for the dedication, creativity, enthusiasm, and unstoppable elan of a great design team.
But it would be an even greater injustice to say nothing. So with considerable humility and trepidation, but profound gratitude, I offer the following thanks.
ACKNOWLEDGMENTS
The P6 project was an effort of many people, and, on a smaller scale, so was this book. In a quasirandom order, here is a list of people I must single out for thanks.
Richard Calderwood, for being an outstanding patent attorney, an astute reviewer of partially baked manuscripts, and a reliable friend.
Dave Papworth, Glenn Hinton, Michael Fetterman, and Andy Glew-with you guys on my team, I’d do it all again.
Wen-mei Hwu, for your encouragement, your perspective, your unselfishness, and your foreword to this book.
Readers of my IEEE Computer Magazine “At Random” column, for your interest and support. You convinced me there might be a book hiding somewhere in my memories of the P6 project. This book is all your fault.
Dadi Perlmutter, Mike Fister, Will Swope, and Pat Gelsinger, for the opportunities you gave me and the errors you forgave. In your own way, each of you gave me the maneuvering room to try new things and the support I needed when a few of them went awry.
Lew Paceley, Jerry Braun, Richard Dracott, and John Hyde-by your examples, you showed me where my biases were regarding marketing, and the lessons you taught me were among the most important that I learned at Intel. Frank Binns, thanks for proving that marketing people can do real technical work, and for having a twisted sense of hu-mor–balm for tough days. Terry Nefcy, Adrian Carbine, Gary Brown, Jim Hunt, Tom Marchok, John Barton, Donald Parker, Keshavan Tiruvallur (“K7”), Bob Bentley, Ticky Thakkar, Rani Borkar, and Steve Pawlowski-thanks for helping make Intel a great place at which to work. Katie Abela-Gale, thanks for the candy and the smiles.
Dawn Kulesa, Human Resources representative extraordinaire-for me, you were the human face of what sometimes seemed a cold, impersonal corporate machine. Your initiatives on training and mentoring at Intel were exemplary and helped the team enormously.
Mary Kay Havens and Mary Killeen-it wasn’t your job, but you showed me the ropes of managing a large group and routinely went well beyond the call of duty. You can be on my design team any day.
Nancy Talbert, this book’s editor-thanks for your innumerable improvements to this manuscript. You helped turn a pile of ideas into something approaching coherency. Joseph Malingowski, for your constant mentoring as I was growing up. It becomes
clearer to me with each passing year how uniquely valuable your tutelage in technology really was. The details of how things work, I learned in college and industry; how to organize and think about them, I learned from you.
Scott Hamilton and Judi Prow, Computer Magazine’s dynamic duo: I wouldn’t have written this book if I hadn’t been writing the “At Random” column, and I wouldn’t have done that column without your help and encouragement.
Randy Steck, my partner in this enterprise-nobody does it better.
My parents, Bob and Agnes Colwell. I still aspire to the standards that you set, and thank you for that invaluable legacy.
Ellen Colwell, my wife, sounding board, editor-in-chief, and best friend. She wasn’t on the payroll, but in a very real sense she was also a member of the P6 team. I couldn’t have done that project, nor this book, without her unwavering support. Thanks also to my children Kelly, Ken, and Kristen, who grew up during the P6 and Willamette years and often wondered where Daddy was.
THE JOY OF PURPOSE
I realized early on that it would not be easy to capture the nuances of a project of this magnitude. P6 was a landmark design project and microarchitecture, both for Intel and for the industry. I felt that way during and after the project, and dozens of other project engi neers have told me they felt the same. For those very reasons, I felt compelled to record at least some of the vast experience that went into P6 development insights and vision that might otherwise be lost.
George Bernard Shaw wrote, “This is the true joy in life, the being used for a purpose recognized by yourself as a mighty one … the being a force of nature instead of a feverish, selfish little clod of ailments and grievances complaining that the world will not devote itself to making you happy.”
Here’s to mighty purposes and vicarious educations.
I
INTRODUCTION
God tells me how the music should sound, but you stand in the way. -Arturo Toscanini, to a trumpet player
In June 1990, I joined Intel Corporation’s new Oregon microprocessor design division as a senior computer architect on a new project, the P6. This division would eventually grow to thousands of people but at the moment it had a population of exactly one-me. I spent my first day buried in forms, picking primary health-care providers mostly on the basis of how much I liked their names. The second day, my boss stuck his head in my office and said, “Your job is to beat the P5 chip by a factor of two on the same process technology. Any questions?” I replied, “Three. What’s a P5? Can you tell me more about Intel’s process technology plans? And where’s the bathroom?”
P5, as it turned out, was the chip the Intel Santa Clara design team was developing, the team that had created the very successful 386 and 486 chips. P5 would become the original Pentium processor when it debuted in 1993, but in June 1990, my time frame, P5 was little more than a letter and number.
The P6 project was to follow the P5 by two years. Extrapolating from Moore’s Law, it appeared that P6 might have as many as eight to 10 million transistors and could become a product as soon as late 1994. My job and the job of the team I was to help recruit was simply to figure out what to do with those transistors and then do it.
In summer 1992, two years after joining the project, I was promoted to architecture manager and served as Intel’s lead IA-32 architect from 1992 through 2000.
Somewhat to my surprise, the P6 design project turned out to be a watershed event in the history of the computer industry and the Internet; it could keep up with the industry’s fastest chips, especially those from reduced-instruction-set computer (RISC) manufacturers, and it had enough flexibility and headroom to serve as the basis for many future proliferation designs.
It also gave Intel a foothold in the maturing workstation market, and it immediately established them in the server space just as the Internet was driving up demand for inexpensive Web servers.
The P6 has become the most successful generalpurpose processor ever created.
The P6 project would eventually grow to over 400 design and validation engineers and take 4.5 years to production. But that huge investment paid off P6 became the Pentium Pro microprocessor, was adapted to become the Pentium II and then the Pentium III, and, most recently, has evolved into the Centrino mobile line. From the basic design have come numerous Xeon and Celeron variants.
In short, the P6 has become the most successful generalpurpose processor ever created, with hundreds of millions of chips being shipped. This book is my personal account of that project, with occasional excursions into Pentium 4.
P6 PROJECT CONTEXT
To fully appreciate where the P6 came from, you must first consider the industry and technology context. The microelectronics industry has been blessed for several decades with an amazing benefaction: The silicon chips on which we place our circuits improve drastically about every two years. New process technology historically provides twice the number of transistors, makes them fundamentally faster, and generally reduces the power requirement as well. If we were to do no engineering other than to simply convert an existing design to the newly developed silicon process, the resulting chip would be faster and cheaper without our having done very much work. That sword has two edges, though. The good news is that if I start designing a new CPU chip today toward a production goal that is, s
ay, three years away, I know I can count on having a new process technology. So I design to that new process technology’s particular set of design rules, and I am pretty confident that this better technology plus my design team’s clever innovations will give my new chip a clear advantage over what is available today.
But the main reason to go through the expense and effort of designing a new CPU is that it will be substantially better than what exists. For microprocessors, “better” generally means higher overall performance that will enable more interesting software applications, such as operating systems with improved user interfaces and shoot-‘em-up games with ever-more-realistically rendered bad guys. My new chip has to deliver higher performance than its predecessors or I have accomplished nothing. My competition will also migrate to the new process technology within my three-year horizon and its existing chip will have become faster. That’s the sword’s other edge: The target isn’t stationary. A new chip has to beat the competition’s new design, as well as any process-migration chips from any source, including my own company.
My and my fellow chip architects’ job was, therefore, to find ways of organizing the new microprocessor’s internal design so that it would clearly be superior to any others. Naturally, the first step was to identify “any others” and thereby establish the focus of our project goals. In 1990, Intel was still developing Intel 486 chips-33 MHz,’ 50 MHz, and 66 MHz, eventually reaching 100 MHz by 1992. P5 was the code name of the design project being done in Santa Clara by (mostly) the same team that had produced the 486 and the 386 before that. Task 1 was, therefore, to scope out the P5, analyze its performance potential, investigate the techniques the Santa Clara team was using, and then come up with something that would be twice as fast.
The Pentium Chronicles: The People, Passion, and Politics Behind Intel's Landmark Chips (Practitioners) Page 2