|Home » Learning Curve
A Hot Chip Retrospective
Richard Mendes on the Intel Core Duo rush to market.
I ran across this while cleaning out my mail.
Hot Chips: Intel's dual-core Pentium 4 a rush job
August 17, 2005 4:00 pm ET MacCentral
Intel Corp's first dual-core chip was a hastily concocted design that was rushed out the door in hopes of beating rival Advanced Micro Devices Inc (AMD) to the punch, an Intel engineer told attendees at the Hot Chips conference Tuesday.
With the realization that its single-core processors had hit a wall, Intel engineers plunged headlong into designing the Smithfield dual-core chip in 2004 but faced numerous challenges in getting that chip to market, said Jonathan Douglas, a principal engineer in Intel's Digital Enterprise Group, which makes chips for office desktops and servers.
'We faced many challenges from taking a design team focused on making the highest performing processors possible to one focused on multicore designs', Douglas said in a presentation on Intel's Pentium D 800 series desktop chips and the forthcoming Paxville server chip, both of which are based on the Smithfield core.
Intel was unable to design a new memory bus in time for the dual-core chip, so it kept the same bus structure used by older Pentium 4 chips, Douglas said at the conference at Stanford University in Palo Alto, California. This bus was capable of supporting two separate single-core processors, but it was not as nearly as efficient as the dual-independent buses that will appear on the Paxville processors or the integrated memory controller used on AMD's chips. The memory bus or front-side bus on Intel's chips is used to connect the processor to memory.
All of Intel's testing tools and processes had been designed for single-core chips, Douglas said. This meant that the company had to quickly come up with a new testing methodology for dual-core chips that could measure the connections between both cores.
Also, a new package had to be designed for the Pentium D chips that could accommodate both cores. 'We're putting two cores in one package, it's like trying to fit into the pair of pants you saved from college', Douglas said.
Intel would have preferred to design a package that would put two pieces of silicon in a single package, like the design that will be used for a future desktop chip called Presler, but its packaging team simply didn't have time to get that in place for Smithfield, Douglas said.
The company's Pentium D processors consist of two Pentium 4 cores placed closely together on a single silicon die. That design creates some problems in that dual-core processors must have some logic that coordinates the actions of both cores, and those transistors have to go somewhere in an already small package, Douglas said. This caused signaling problems that needed to be overcome, he said.
Intel also had to design special thermal diodes into the chip that would closely monitor the heat given off by the combination of two fast processor cores, Douglas said.
In total, Intel completed the Smithfield processor core in nine months, Douglas said. By Intel's standards, that is an extremely aggressive goal for a major processor design, said Kevin Krewell, editor in chief of The Microprocessor Report in San Jose, California.
'Most designs take years', Krewell said. 'But it was very important for them to get back in the game and have a road map.'
Intel began to put together the Smithfield project around the time it publicly announced plans in May 2004 to cancel two future single-core designs and concentrate on multicore chips. The company realized that wringing more clock speed out of its single-core designs would require a significant engineering effort to deal with the excessive heat given off by those chips.
At the time, AMD had already started work on a dual-core version of its Opteron server processor that it would demonstrate in September of that year. AMD unveiled its dual-core Opteron chip in April, a few days after Intel launched Smithfield. AMD has since released dual-core desktop chips.
One reason for the aggressive schedule set for Smithfield was the need to respond to AMD's actions, Douglas said, without mentioning his company's competitor by name. 'We needed a competitive response. We were behind', he said.
Despite the rush, Smithfield was good enough to get Intel into the dual-core era, Krewell said. 'It's not an optimal solution, but it's a viable solution. It works, and it works reasonably well', he said.
Intel took a little more time designing the server version of Smithfield, known as Paxville, Douglas said. For instance, the company was able to address the bus inefficiencies by designing Paxville to use dual-independent front-side buses. Also, the more sophisticated package was available in time for Paxville, which helps reduce the chip's power consumption, he said.
Paxville will be released ahead of schedule later this year in separate versions for two-way servers and for servers with four or more processors. Intel had originally expected to release the chip in 2006, but will get Paxville out the door in the second half of this year, it announced Monday. Another dual-core server processor, code-named Dempsey, will be released in the first quarter of 2006.
Future multicore designs will present additional challenges, Douglas said. Point-to-point buses and integrated memory controllers have been prominent features of other multicore designs, such as Opteron and the Cell processor. These designs help improve performance, but Intel isn't necessarily sold on the concept because it requires a larger number of pins to deliver electricity into the processor and that can hurt yields, he said.
Reading it, you can argue that Intel was overly hasty in its effort to compete with AMD at the time. Or you can argue that Intel was being aggressively competitive. Seeing how the initial dual-core processors were so quickly and negatively reviewed, I'd conclude that they were in too much of a rush to get something out the door. But at least they get points for trying.
Marketing vs quality. DEC taught me the value of marketing (because they effectively had none) but I don't think you should ever sacrifice quality.
|'I just want you to know I'm really trying to do a schlock job.'|
I started work for a software developer the week they were supposed to be pushing out a new release. All the senior management was off at a hotel preparing a pitch for a major prospect. After 2 days of staying out of everybody's way, I was told that I was responsible for making sure the product shipped by the end of the week. I spent the next 3 days in the same suit and staying in a hotel a couple of blocks from the office.
I spent 2 days wandering the halls finding out what was going on and listening to the analysts blaming the programmers, the programmers blaming the analysts, a bitchy senior analyst blaming the tech support people whom she sabotaged with incorrect information about the sequence of installation and file conversion (if you can believe it). I finally hit the operations manager who hailed from the Caribbean. Deep voice, lovely accent.
'MON WE HERE IN OPERATIONS ARE DOING THE BEST WE CAN. IF THE PROGRAMMERS AND ANALYSTS WOULD JUST DO THEIR JOBS WE'D BE FINE!' he intoned.
I heard something snap. Like a pencil. But between my ears.
'Harold', I said, 'I've been walking the halls for two days, and do you know, in all that time, not one person has walked up to me and said 'Richard, I just want you to know I'm really trying to do a schlock job.'
As I walked out of the room I savored the image of him with his jaw hanging down in the vicinity of his belt.
PS. I left Saturday morning as the first tapes were being cut. As I explained, I was leaving because if I didn't get home in time for my daughter's dance recital I didn't have to bother coming home at all.
A few days later the senior VP took me out to lunch and asked for my evaluation. I told him that if I were a Japanese company looking for a new market, I'd either buy a company like ours, or start a new one to compete with us. The new product would be limited in features initially but would be built using the best design and programming practices available. Initial marketing would be at a low price due to the lack of features but there should be a plan to add new features that would build on the foundation. Each product cycle would add a new unified set of features, comply with the overall design criteria, and add value to the product.
|'That was the first time in the history of the company that a release went out on schedule.'|
Further, if prospects came with demands for features that were planned 2-3 releases out, they would be told to take their chances with some other vendor which was prepared to slice and dice their system in an unplanned fashion. By the time they found the other product unreliable and unsatisfactory, they could come back to us and we'd probably have the features they needed by then. The way I figured it, the first year or so would be grossly unprofitable, but within 2-3 years of the first release they could own the marketplace based on delivering bulletproof software that 'just worked'. Right out of the box.
As it turned out, that product release was riddled with quality problems.
The VP got even with me by putting me in charge of coordinating the next release, which ended up as a huge release. I set up daily meetings with key staff from each group to coordinate every activity (bored everyone to death without a doubt) until the last few days when everything was hectic and everyone knew what had to be done and I could keep track by wandering the halls.
That was the first time in the history of the company that a release went out on schedule (OK it was 20 minutes before midnight before the first customer tape was cut and FedEx was closed but it wasn't my fault that the tapes couldn't be shipped until the next day). The people who stayed (I trapped 2 programmers when QA caught a problem after most of the staff had got home) went berserk and pulled reams of continuous feed paper out of the printers, made 'WE DID IT' signs and autographed them and hung them in the two VPs' offices.
The senior VP kept his up (it wrapped around the whole office up near the ceiling) for a couple of weeks and explained what it was all about whenever he had prospects or clients in for meetings. The executive VP to whom I reported came in the next morning. No one was around. His office door was closed and he thought he'd left his key at home. He kicked the door, it flew open, and he saw the sign in his office and cracked up.
OK, there were some quality problems with that release too, but nothing to compare with the previous one.
I still feel that way about quality. Which is why I feel the way I do about operating system security.
Richard Mendes is a former systems analyst and marketing consultant specialising in IBM and DEC rollouts.