

Social aspects of chip design - TriinT
http://michaelnielsen.org/blog/chip-design/

======
supahfly_remix
There are many roles in the design of a chip and the staffing depends on
whether this chip is a new architecture (very rare these days) or a derivative
part. Also, the staffing depends on the phase of the project (a handful at the
beginning with hundreds at the end):

\- chip architects, usually PhD's in computer arch or really senior engineers
+ people to run performance simulators

\- implementors/logic designers: take the architecture, divide it into blocks
(instruction fetch unit, memory interface, etc), create a microarchitecture
and code it in RTL (register transfer language, Verilog)

\- verification engineers: read the specification and write software+tests to
exercise corner cases. verification is usually staffed at twice the number as
implementors

\- layout/backend engineers: synthesize the RTL into logic gates and/or draw
custom transistor circuits where speed requires it

\- circuit designers: design phase lock loops, clock paths, pad drivers, etc.

I don't know the breakdown at Intel, but a new chip architecture can take on
the order of 500 people. The floating point bug would have been in the
floating point unit, so probably at most less than 10 of the logic designers
would have been aware of the design.

~~~
wglb
As i recall about <http://en.wikipedia.org/wiki/Pentium_FDIV_bug>, the error
came about when transferring a mask where one segment was dropped. The
implication was that it was not so much a design bug as it was a production
step. They had tests for the FP, but did not run it at every step.

As an aside, what was amusing to me were the estimates of the probability of
errors that various voices were making: Byte made one, I remember IBM making
one. All of the estimates presumed that the floating point calculations made
were somehow randomly distributed, which is very clearly not the case.

------
chadaustin
I have to second the recommendation for The Pentium Chronicles. I bought that
book at the Computer History Museum in Mountain View and thought that it
looked a bit overpriced at $35... but it was worth every penny.

Robert Colwell tells the story of the P6 architecture with a collection of
anecdotes. It's full of insights and easy to digest at the same time.

For example, many of the issues in processor design stem from miscommunication
about how functional units communicate. Since units on a processor can only
communicate with their neighbors, they arranged the teams in the office to
reflect the actual die layout. This way, teams responsible for a functional
unit could always communicate directly with their on-die neighbors!

~~~
joe_bleau
Yep, fun book. (I was way to cheap to buy it; ILL FTW!)

------
diN0bot
plz post back when you have the answer :-)

