[MUSIC PLAYING]
Hello.
I'm Jim Montanaro, and I'm going to discuss the implementation
of the Alpha CPU chip.
This tape is the second of two tapes about the Alpha program.
The first tape, by Dick Sites and Dirk Meyer,
discuss the architecture and some
of the high-level implementation issues.
This tape will talk about the lower-level implementation
issues.
The two tapes are independent.
You don't need to have seen the first one in order for this one
to make sense.
They do overlap a little bit, but in general, they
just complement each other.
First I'd like to give you some idea of what
I'm going to talk about.
To start with, I'll discuss the goals
of the program and the chip.
Next I'll describe some of the constraints and resources
available which served as a framework around which
the design evolved.
Then I'll try to describe the design strategy
and philosophy of the team.
Having set that background, I'll talk about the chips themselves
and some of the technical problems that we encountered.
The primary goal of the Alpha program
was to provide hardware and software that
could deliver leadership performance and price
performance in a way that could maintain and expand
Digital's customer base.
The chip team's part of the deal was
to provide the engine, a high-performance RISC CPU chip.
A few things were obvious from the start.
Number one, we were coming into the market
late with a RISC chip, and there was some skepticism
about our ability to deliver.
The first chip had to be fast enough to create a stir
and to be the clear choice for our internal system partners.
An average design would not be sufficient.
Number two, we needed to field a variety of systems,
and given the resources available,
we were only going to be able to design one chip to start with.
Consequently, the chip would have
to be flexible enough to support both the high and lower end
systems, at least at the start.
More specialized chips for parts of the system space
would come if we were successful with the program.
And third, of course, we were in a hurry.
Schedule was important for several reasons.
One reason was that we had to provide a hardware base
for the software development.
Although the chip design task was hard,
and its performance was important,
the program would live or die by the success of the software.
The second, very important reason
was to establish credibility.
We were designing a CPU in a new architecture.
So we had no established following inside digital.
As such, we were at risk of cancellation
if we slipped our schedule or missed the performance goals.
At the beginning of the Alpha program
there was some argument as to whether Alpha was
necessary or even desirable.
And it's probably safe to say that we did not
enjoy the unanimous support of all parts of the company.
Some of these risks would decrease
once we had something real, something
that you could send 2 plus 2 to and hopefully get back
the answer 4.
Those were the goals.
As usual, there are the accompanying set
of constraints, some of which seemed at odds with the goals,
and a collection of resources that we hoped
were sufficient to the task.
First, the constraints-- we needed
to complete the chip by mid-1990 to support the software
development schedule.
However, when we looked at the schedule
for our internal CMOS process development,
we found that the process we needed,
CMOS-4 with 0.75 micron features,
would just be ready by then.
The timing looked awfully tight, and any hiccup
in the process development schedule
would directly impact us.
Then there was competition with the NVAX chip, the VAX
microprocessor that was presented at ISSCC '92,
which was also planning to use CMOS-4 in the same time frame.
The idea of two big chips clamoring
for attention from the process folks
just when they were trying to bring the process up
for the first time didn't seem real appealing.
So we decided to go for plan B. We decided to design
two chips in sequence.
First we would use CMOS-3, a 1-micron CMOS process,
and just implement a subset of the functionality we needed.
We built a system that used that chip,
and the software development could
start while we finished the final chip, which
would contain the full functionality
and be built in CMOS-4.
So there were two chips, called EV3 and EV4,
where the 3 and the 4 correspond to the process in which they
were fabricated.
The original plan was that we'd leave the caches off
of EV3 so that it would fit in the allowable CMOS-3 die size.
Later on, in an effort to accelerate the overall program
schedule by providing chips to the system groups earlier,
we decided to make the EV3 pin bus exactly match the pin
bus which would appear on EV4.
This would mean that, in addition
to software development, the production system
debug could proceed while we finish the final chip.
In order to accomplish this, we changed the subset
of what would go into EV3.
We removed the floating-point unit,
and we added baby IND caches in its place.
With EV3, the floating point instructions
trap to an emulator.
This change was made about a year after the design started.
It injected a major disturbance into the whole design process.
And our attempt to hold the original schedule,
despite making a major change like this,
caused a significant strain on the team.
In the end, we slipped the tape-out date of EV3
about four months past the original target.
On the plus side, we are fortunate to have
an impressive array of resources available.
We have in-house CMOS process expertise in manufacturing.
Digital has been developing CMOS processes since about 1982,
and these processes have been optimized
towards high-performance microprocessor design.
Consequently, the chip designers designed to a single CMOS
process, rather than to the union
of several vendors' processes.
And the chip designers have had input
into the direction process development goes.
People working on the process development
sit about 200 feet away from the chip designers.
So if you have questions about the process,
you can walk across the hall and get them answered.
Within our group, we have expertise in systems, software,
architecture, micro-architecture,
circuit design, and layout.
This is very important, because it
allows you to optimize across all these disciplines.
At the same time, we started the first chip design,
there was one person in the group working on a C
compiler for the machine.
There was also a group of four people from our group in Hudson
and from Digital Systems Research Center in California
working on the design of a system that would use the chip.
These efforts were to design prototypes,
not to design products.
But the parallel development efforts
resulted in important information
that we could draw upon to make good trade-offs
during the course of the chip design.
They were also coordinated to the schedule of the chip,
not to the schedule to any particular product.
So for example, we had a socket waiting in the prototype system
to plug the chip into as soon as it came out
of the manufacturing line.
We have a local CAD group of about 100 people,
who develop our design and verification tools.
This provides access to tools which
are not available in the industry at large,
and which can be customized to the requirements of our design,
sometimes on very short notice.
There are several distinct design groups
within the facility.
Despite some differences in design style
and feuds that go back generations,
each project benefits from the work of the other groups,
either through shared CAD tools or design techniques.
The other groups also serve as a pool of talent and machine
resources for times when a project needs some extra help.
Now I'd like to talk about the design style or philosophy that
was present in the EV3 and EV4 designs.
I have to start with a disclaimer--
this style is specific to EV3 and EV4,
not to digital in general, or even
to other groups in this building.
There were even some variations within EV4,
because the floating point unit was
designed by another group that had
a slightly different approach.
Our method works pretty well for us,
but I don't claim that it's ideal for all groups
and certainly not for all types of chip design.
It is aimed at producing a design which
achieves maximum performance.
The design style of the chip teams reflect, to some measure,
the personality of the team leaders.
If you go into Dan Dobberpuhl's office,
you'll note that the only object which
rises above the stacks of paper is a workstation monitor.
In my office, the bookshelf is stacked with rubber toys.
On one occasion, I found a wind-up toy on my chair
with a note that read, my nephew was going to throw this away,
but I knew you'd want it.
I still have the toy.
With this preface, you might imagine
that we were not the model of organization or decorum.
The team operated with a minimum of organizational hierarchy,
methodological constraints, and documentations.
For example, the behavioral model
is the only implementation spec.
Some projects like to generate detailed descriptions,
in English, of the functionality to be implemented before they
start the implementation.
The only formal documentation for the physical implementation
is a 50-page document, fairly sketchy,
that includes no naming conventions, circuit sizing
and simulation guidelines, global clock waveforms,
flashing and clocking rules, standard latch library,
electromigration limits, CAD tool hints, and guidelines
for layout designers.
It was revised as the project progressed and includes
paragraphs like the following.
"Digression on speed versus functionality issues--
based on some discussions with several designers,
the EV3 Critical Path Appeals Board
would like to clarify, emphasize, and in some cases,
state for the first time some assumptions and guidelines
around the simulation of critical speed paths and race
conditions.
Critical speed paths and races are
treated in a fundamentally different manner
on our project."
"You should think of speed paths as an interesting and enjoyable
challenge and races as evil and odious.
For the purpose of this note, a speed path
is any path which will be guaranteed
to work if you slow down the clock
by some reasonable amount, and a race is a path which will not.
Yes, we know you can argue with this terminology.
No, we don't care."
Decisions were made, and information
was passed, more in hallway conversations
than in formal meetings.
This is fairly efficient, but tends
to break down as a group grows.
It also has a shortcoming that if your office is
not strategically placed, you may not
pick up the hottest gossip.
There are no published minutes from the hallway chats.
Senior people on the project are all technical
and are all involved in doing technical work.
There are no pure managers.
Senior designers wedge in their management responsibilities,
as required.
With a design of this difficulty,
you can't afford to squander your most experienced designers
on management tasks.
The success of a project organized
like this depends much more on the efforts of individuals
than on the proper assignment of people
to tasks and the proper tracking of each step.
This is not an engineering factory.
The demands of the task itself require creativity,
and a structure of this sort encourages that creativity.
It gives considerable latitude to individual designers,
even those with limited experience.
There is, of course, a downside.
It's a bit difficult to get a sense
of how the design is going.
And sometimes creativity just runs amok and creates some
rather spectacular problems.
And there's also sometimes problems
if people don't get sufficient guidance.
On balance, however, the results are
worth the chaos, the uncertainty,
and the occasional crisis.
That's it for philosophy.
Now I'd like to move on to the organization.
The team is organized by specialty.
Three microarchitects wrote the behavioral model
for nearly the full chip.
The circuit designers were divided
by major functional block and worked with the microarchitects
and the layout designers to mold this behavioral model
into the final design.
There's considerable negotiation throughout this process,
and the behavioral model is generally
rewritten as the physical implementation progresses.
There's an alternative team structure
which is also used in groups here,
which give smaller, well-defined sections to individuals
who write the behavioral model and do the circuit and logic
design all themselves.
That structure has the advantage that the designer doing
the work understands all the trade-offs
within that small section very well,
although she's limited in her visibility
outside that section.
It also affords exposure to a larger part
of the design process.
This organizational model was used
by the group who designed the floating point unit for EV4.
The advantage of organizing by specialty
is that the small number of designers
who own the behavioral model get to see the big picture.
They don't worry about transistors at all,
but they know the logic level functionality of the whole chip
very well.
So they can optimize across the whole design.
The challenge of using this sort of method
is that you have to be able to transfer enough
of the information from the behavioral modelers
to the circuit designers so they can understand
what the options are and make an intelligent implementation.
Even though the behavioral model represents the function
in terms of [? NANs ?] and [? NORs, ?] it's not sufficient
to just translate it into Gates and reduce the logic.
You have to understand the intent
and then figure out the best circuit techniques for the job.
Throughout the design process, we
made constant trade-offs between the microarchitecture,
the chip, and the circuit implementation.
And the effect of this effort is evident in the performance
of EV4.
Excluding the floating-point unit,
there were generally between one and three circuit
designers in each of the six major sections.
That number of designers grew for short periods
if there was a local schedule crunch.
The floating-point unit used a team
that included eight engineers who
handled both the behavioral model and the implementation.
Our schematic design style employs very limited hierarchy.
The only circuits that are formally
shared on multiple schematics are the standard latches
that are used by the project.
All transistors are visible on each page
to allow easy optimization of circuits
and to allow designers using the schematics to see
all the interactions.
Our schematics editor supports a form
of symbol definition, which is local
to a particular schematic.
This allows efficient reuse of circuitry on a given schematic,
while still maintaining visibility
into the details of the circuit.
This type of schematic also allows the schematics
to reflect the physical placement of transistors.
Internal CAD tools exist to check tricky circuits
for proper usage.
And when the need arose during the project,
additional CAD tools were developed.
Schematics are assembled by simply appending the transistor
wireless.
Signals which cross schematic boundaries
are connected by naming convention,
and other tools exist to check for consistent naming.
Despite the importance of creativity
and individual efforts in the design of EV4,
it was necessary to manage and track
the progress of the project at some level,
if only to adjust the allocation of resources
as the tasks changed.
The challenge is to accomplish this without negatively
impacting the design.
There is a natural tendency to overmanage
complex projects like this, rather than
trusting individuals to behave reasonably
in the absence of management.
An overmanaged project tends to give the higher
levels of management a warm, fuzzy feeling about how
the project is going, and the manager responsible
is usually rewarded.
However, the goal of the Alpha CPU design project
was to design the fastest chip possible, not
the best-managed project.
And the electrons involved don't really
care how the project was managed.
Consequently, we tried for the minimum acceptable level
of formal management.
The methods used to run the project varied
as the design developed, usually in response
to a recognized deficiency in the current method.
For example, in the early part of the EV3 implementation,
all the circuit designers were getting
used to the single wire two-phase clocking
technique which we were just beginning to use.
We had used a four-phase design on earlier CPUs,
and the new clocking method required new techniques.
While some standard latches had been defined,
there were lots of other issues to be ironed out,
like clever ways to minimize the latch delays in critical paths.
We couldn't just present a set of proven circuits
and tell everybody, use these circuits.
We didn't know what the proven circuits were.
So for a while, people toiled away individually,
discovering what worked and what didn't.
And during this period we instituted a series
of weekly chats to disseminate information between the circuit
designers.
Chats were about an hour long and were held about once
a week.
People generally presented about once a month,
as the topics of the chats rotated around between circuits
from various sections of the chip.
Presenters were allowed 10 minutes
to get ready for the talk and presented
work that was in progress.
The work to be presented was up to the individual.
And attendance was limited to members
of the design team and one representative
from each of the other two CPU design teams in the building.
The intent was to establish an atmosphere where
half-baked ideas could be freely presented and critiqued
in a friendly manner and to allow all team members to steal
clever ideas from each other.
Some of the chats were very useful
and presented ideas that spread throughout the team.
Others were significantly less useful.
And as time went on, we started to see the same circuits
over and over again each week, so we just discontinued
the chats.
In all, they went on for about five months
in the beginning of the project, and they're a reasonable way
to spread information around inside a loosely coupled team.
Formal reviews were generally limited
to reviews of schematics before they entered layout.
These were attended by the leader of the section, the chip
leader, the lead layout designer, the designer
of the schematic, and the layout designer who was
going to receive the schematic.
Participants looked for bad circuit structures,
obscure critical paths, layout constraints, and assumptions.
They did not review SPICE simulations
or logical functionality.
Layout constraints like nonminimum wire width spacings
and sensitive nodes were included
in the schematics as a note and were discussed at the meeting.
In addition to providing a circuit review
for the schematic, the layout review served other purposes.
The meetings allowed the lead layout designer
to more efficiently supervise the layout,
because he understood all the constraints
for each one of the schematics, and he
could check to make sure that they were followed.
It also provided a forum for the layout designers
to object to unreasonable layout assumptions
by circuit designers, and every once in a while,
we slip those in.
And it allowed him to understand what was important
and where they might be able to cheat if they got stuck.
Passing this sort of information between the people
responsible for different stages of the implementation--
either the microarchitects and the circuit designers
or the circuit designers and the layout designers--
it's difficult. There's a lot of information.
There's a lot of assumptions which aren't stated, generally,
and it's not always clear what will
be important to the person at the next level.
However, getting enough of this information flowing
back and forth is essential to producing
a high-performance part.
And the success of this sort of interaction
generally determines the success of the project.
Particularly tricky structures were reviewed individually
before they were ready for layout.
Typical examples include the integer adder and the register
file, and the register conflict logic, which is in the I-Box.
Other sorts of checks on the design
were done by in-house CAD tools, rather than by design review.
Logic verification was performed by running
handcrafted and random patterns on the behavioral model
and comparing the results to the results that
came out of a high-level model.
We ran the equivalent of 30 [? VAC ?]
780 CPU years, about a billion simulated cycles
on the EV4 behavioral model.
The transistor wireless from the circuit schematics
is translated to a logic equivalent.
And that's compared against the results
from the behavioral model for about 380 hand-coded pattern
and lots of random patterns.
The hand-coded patterns comprise about 10 million
simulated cycles.
For both the behavioral- and the transistor-level logic
simulations, the random patterns run constantly
as a background job on the cluster
and just suck up any excess CPU time.
Once these runs are started, you don't have
to pay much attention to them.
They just report errors.
And so it doesn't use up much human effort.
Circuit integrity is assured by a program which
has been developed here at DEC over the last 10 years
to handle our full custom designs.
It runs off the transistor wireless
and accepts data files generated by other programs
and also by designers.
It checks a large set of rules related
to noise margin, coupling, beta ratios, and that sort of thing.
It's intended to guarantee the functionality of the circuit,
but not necessarily the speed.
To verify the speed, several techniques were used.
In addition to masses of circuit simulations using SPICE,
we run a static timing verification
tool on the whole chip.
[? Hit 2 ?] works off the transistor wireless and accepts
extracted node capacitances and wire resistances
generated by other tools.
At these speeds, wire resistances
are not negligible, even for wires
contained in a single section.
So the ability to accurately model the wire delay
is important.
The accuracy of the timing tool is good enough
for the vast majority of our circuits.
The major exceptions are circuits like the integer adder
and the register file that use some non-standard design
techniques.
The tool doesn't replace SPICE at all.
But it complements it nicely, typically finding
paths that are slow, not because they're particularly hard,
but because somebody didn't pay a lot of attention to them,
or because the capacitance that ended up on some of the nodes
was not what was expected.
Now I'd like to talk about what we built. This is the EV4 chip.
It's a 200 megahertz, 64-bit CMOS microprocessor.
It's fabricated in our CMOS-4 process, a 0.75 micron
process with half-micron [? L ?] effectors,
three layers of metal.
The chip is 13.9 by 16.8 millimeters,
contains 1.68 million transistors, about a million
of which are in the two caches.
It's packaged in a 431 pin grid array package,
with 291 signal pins and 140 power pins.
It dissipates 30 watts at 200 megahertz with a 3.3-volt power
supply.
The chip implements a 43-bit subset
of a defined 64-bit linear virtual address space
and provides addressing for 2 to the 34th physical addresses.
It can issue up to two instructions for each
5-nanosecond cycle between pairwise combinations of four
functional units--
an integer operation unit, a floating-point operations unit,
a load store unit, and a branch unit.
The chip contains 44 translation lookaside buffer entries,
32 data TLB entries, and 12 instruction TLB entries.
It contains and on-chip write buffer,
which has four 32-byte entries.
There are two primary caches, an 8k [? ICache ?]
and an 8k DCache.
And the bus interface is either 128- or 64-bit data buses
with a separate 34-bit address bus.
We can interface to either 5-volt CMOS or TTL,
or 100K ECL.
As I said earlier, one of our goals
was to make a chip that was fast enough to create a stir.
At 200 megahertz, we've done this.
Lots of things contributed to making
a chip that runs this fast.
There's not just one silver bullet
that you need to get success.
These are some of the items that we used.
As I discussed before, we have a CMOS process,
which is optimized for doing high-performance microprocessor
design.
It's got 3.3-volt power supplies,
105-angstrom gate oxides, half-micron L effectives,
and the three layers of metal, the third layer of which is
very thick.
It's got a high-performance architecture,
in which the bottlenecks for the implementation
have been removed, and a super pipeline micro architecture,
in which each of the stages are carefully
balanced so that we don't overload a particular stage.
It's a single chip implementation,
so there's no chip-to-chip delays.
And we did very careful logic, circuit, and layout design.
Most of the critical paths could be categorized as precharged,
and some are some non-precharged with very tricky circuits.
There's very little synthesis in the chip.
We synthesize some of the circuits
in some of the control sections where
they weren't in critical paths.
But in general, these sorts of speeds,
it's very hard to make synthesized circuits work.
We have a comprehensive set of CAD tools
to analyze both the functionality
and the speed of the chip.
And when all else fails, we use brute force.
There's 128 nanofarads of on-chip decoupling cap,
built out of thin oxide capacitance
and spread around the chip wherever we had space.
There is a 250,000-micron transistor in the clock driver.
We'll come back to that later.
That 250,000 microns is 10 inches.
This is a photograph of the EV4 chip.
The integer unit is across the top in the center.
The floating-point unit is across the bottom.
The caches are on the right and the left,
with the data cache on the right and the instruction
cache on the left.
The right buffer is in the upper right-hand corner.
In the center of the chip is the clock driver
that extends all the way between the two caches
about in the center of the chip.
And the dark areas on either side of it
are the decoupling cap associated with the clock.
One of the things I mentioned when
I talked about the goals of the chip
was that we needed to design considerable flexibility so
that we could support a wide variety of systems.
The pin bus supports a fair amount of flexibility.
We support cache sizes from 128 k-bytes to eight megabytes
or no cache at all.
The cache speeds can be between 3 and 16 CPU cycles.
You get to set this up when you power up the chip.
And so you can use either slow chips, slow RAM chips,
or fast RAM chips, depending on what you want.
The external interface runs synchronously
to a system clock, which is supplied by the CPU.
And you can also program how fast that runs when
you power the chip up.
The width of the data bus can be chosen
to be either 128 bits or 64 bits and to be either TTL or CMOS
levels or ECL levels.
We support longword ECC and longword parity.
And we have a simple diagnostic interface
via off-chip serial ROM that provides a mechanism
for loading [? the iCache ?] on power up
and also for doing some diagnostics.
For most operations, the CPU chip
accesses the cache directly in a combinatorial loop, simply
by presenting an address and waiting n CPU cycles
for control, tag, and data to appear,
where you get to program the value of n on power up.
This allows you to use SRAMs of almost any speed.
Obviously, if you use faster SRAMs,
you get better performance.
Simple accesses are done entirely by the CPU chip
without any intervention from the memory subsystem.
Read hits and write hits to unshared lines
are considered to be simple accesses.
More complex accesses defer to a state machine
in the external memory subsystem.
Now I'd like to talk a little bit more
about the clocking method that we use on EV3 and EV4.
This slide shows the waveform on the global clock, CLK,
and one type of latch that we use.
We use a wide variety of latches,
but they all share the characteristics
that they use a single wire clock.
This eliminated the dead time between phases
and allowed us to just route a single clock wire
in our thick metal three-layer.
Note that there's a race-through problem inherent in this type
of latching method.
When the clock rises, the B-latch is closing
and the A-latch is opening, allowing
new data to travel to the input of the B latch.
If the new data from the A-latch gets into the B-latch
before it closes, you're in trouble.
With the latches shown, the data from the A-latch
starts propagating when the rising clock hits the n
threshold.
And the B-latch closes when the clock
hits Vdd minus the p threshold.
As long as the clock edge is faster than the propagation
delay between the latches, all is well.
This requirement is not a new constraint,
because it's in line with our desire
to minimize the clock delay across the chip,
so we can just get the thing to run fast.
However, it does raise the stakes.
If we've chosen a clocking scheme without this transition
time constraint on the clock, and we
were unable to control the clock delay,
we'd have to slow down the cycle time.
That would be disappointing, but it wouldn't be disastrous.
With this sort of latch, if you're
unable to maintain snappy clock edges,
the chips are non-functional at any speed.
Consequently, considerable attention
was paid to the proper design and analysis
of the clock driver and the distribution grid.
The slide shows the distribution of clock load
among the major functional units.
All sections except for the bus interface unit
receive the clock directly.
The BIU operates from a single-level buffered version
of the main clock.
The total load on the clock node is 3,250 pF,
with the majority of the load occurring in the two
main functional units to the north and south of the clock
driver.
The clock driver and pre-driver represent about 50%
of the total effect of switching capacitance
for the chip, which has been determined by power measurement
to be 12,500 pF.
To manage the problem of the IdP associated with the chip power
pins, explicit decoupling is provided on chip.
This consists of thin oxide capacitance,
which is distributed over the entire surface of the chip
wherever we have space.
In the case of the clock driver, there's
a stripe above and below the driver
itself to supply the charge for the switching of the clock.
The totally decoupling cap extracted from layout
is 128,000 pF or 0.13 microfarads.
So the ratio of the decoupling cap to the switching cap
is about 10 to 1.
And the decoupling cap can supply all the charge
associated with a single CPU cycle with only a 10% hit
in the Vdd supply voltage.
The clock driver itself consists of a binary fanning tree,
which distributes the 200-megahertz signal
in a matched fashion to a row of 145 pre-driver circuits,
each five stages deep.
The signals are shorted at the output of the fanning tree
and in the final three stages of the pre-driver.
The inverter in the final stage, which actually drives the clock
node, contains a PMOS, which is 10 and 11/64 inches wide,
and an NMOS, which is 4 and 5/64 inches wide.
The driver switches its load in half a nanosecond.
And the peak switching current in the driver is about 43 amps.
Now, you can see why we need to have local decoupling cap.
You can't pull those electrons in through the inductance
in the pin wires.
The clock driver is located in the horizontal center
of the chip and drives into a grid structure with metal 3
clock lines running vertically in a regular pattern,
alternating with Vdd and Vss.
The horizontal lines are a higher resistance metal 2,
which are interspersed in a more irregular fashion.
Since the majority of the load on the clock
is above and below the clock driver,
it gets fed directly from the low-resistance vertical metal
3 lines.
There's about 150 microns of horizontal metal 2 shorting
the global clock node in the driver itself to minimize
the delay differences due to load imbalance
between adjacent metal 3 wires.
Both the location of the clock driver and the clock and power
busting pattern were chosen to minimize clocks to you
and ensure crisp edges at all points in the chip.
I mentioned that it was important
that the clock be properly distributed across the chip
to ensure that we had low skew and crisp edges at all
the latches.
We spent considerable time analyzing the grid,
and I'd like to show you the results of that analysis.
We extracted the entire clock node from the layout.
It contained 630,000 resistors and 630,000 capacitors,
and there were 63,000 transistors connected to it.
The network was then analyzed using a linear circuit
simulator derived from Carnegie Mellon's awesome circuit
simulation program.
The delay to each transistor was calculated,
and the transistors were split into buckets
based on the delay.
Each frame in the following sequence
represents a single 10-picosecond delay bucket.
Each transistor in the bucket is represented
by a dot at its physical location.
Now, if we run it again more slowly,
you can see the effect of the clock grid.
The wave starts at the clock generator
in the center of the chip and moves
fairly quickly in the north-south metal
3 lines to the floating point unit and the integer units
directly above and below the generator.
To get to the caches on the right and left,
or to the right buffer in the upper right,
the clock signal must go through the thinner
and sparser horizontal metal 2 lines.
So it takes longer for the clock waveform
to make it to those parts of the chip.
The maximum delay, up in the right buffer,
is about 300 picoseconds.
We use the clock cartoons to identify anomalies
in the clock grid.
We were especially concerned when
we saw the clock propagation moving inwards back
towards the clock generator, as occurred
in our first analysis of the grid, or in regions
where there were major differences
and delay between two pieces of circuitry
that were close together.
That sort of problem could result
in timing hazards in the associated latches,
and we wanted to get rid of those.
In general, these things were solved
by finding the piece of the layout that
was not properly connected and just hooking it up.
The program which generated the clock delay cartoon
was also used in the electromigration analysis
of the chip interconnect.
The circuit simulation program determined the current flowing
through each metal segment and each contact
and checked that that current was less
than the limit which was allowed by the electromigration rules.
Failing segments and contacts were reported as a drc tick
file, identifying the offending polygon and the required number
of contacts or metal width.
This level of verification was performed on every node
in the chip to ensure high reliability,
despite the aggressive clock rate.
The IO interface to the chip was designed
to allow direct connection to ordinary 5-volt logic,
even though the chip operates at 3.3 volts.
An additional constraint was a desire
to interface to 100k ECL logic for very
high-performance systems.
These goals were accomplished with unique input and output
circuits.
For inputs, an externally-supplied reference
voltage is defined.
For TTL operation, this is set to the TTL midpoint
of 1.4 volts, typically using a simple resistor divider.
For ECL, the reference voltage can
be supplied by the reference output of a normal 100k ECL
gate.
Because of the problem of noise coupling
onto this extended on-chip reference node,
local low-pass filters and compensation
were used at each receiver, using well resistors and thin
oxide capacitors.
Testing has shown that the chip can operate
with input signals as small as 100
millivolts relative to Vref, even at 200 megahertz.
The output driver represented a more complicated problem.
To generate signals with good TTL noise margin,
and also to interface to the ECL receivers,
it was highly desirable to be able to drive high levels
to the [? VED ?] rail.
To avoid having pins dedicated to a 5-volt power rail,
it was also desirable to use a floating well type scheme,
employing PMOS pull-up devices.
A unique circuit structure achieves these goals
without handicapping the switching
performance of the driver.
This schematic shows the circuit configuration
of the bidirectional 5-volt compatible output driver.
These three transistors represent the actual driver
for the pin.
You've got to worry about three different effects.
You've got to make sure that you keep
the voltage across the NMOS devices to less than 4 volts.
Otherwise, you'll have a gate oxide breakdown.
That's achieved by simply putting two of them
in series so that you get part of the drop across each one
of the NMOS devices.
Next, you've got to keep the PMOS device off,
even when the output goes above Vdd.
These transistors make sure that the output will follow the pin
if the driver is supposed to be off
and the output pin goes above Vdd.
Finally, you've got to make sure that the well of the PMOS
stays properly biased when the pin goes above Vdd.
And this set of transistors accomplishes
that under various conditions.
I want to close by summarizing the design history for the EV3
and EV4 chips.
EV3 was designed in our 1-micron process,
starting in June of 1989.
It contained the integer unit and baby caches
and was pin compatible with EV4.
It taped out around Halloween of 1990
and booted Ultrix and VMS in the ADU system in January of 1991.
The ADU is the Alpha Development Unit.
It's the system, the prototype system,
that we designed in our group, in collaboration
with DEC's System Research Center in California.
We use the ADU for debugging the chip,
and the software groups have used them
for software development.
We produced about 100 CPU modules,
which are in 50 systems running in various parts of the world.
As an aside, we also designed a non-product PC system
using the chip, just to show that the chip could interface
easily in a low-cost system.
All components except for the CPU chip
were purchased through Computer Shopper.
EV4 added a floating-point unit and real caches and was fabbed
in our 0.75-micron process.
It taped out on July 14 of 1991 and came out
of the manufacturing line on August 31.
It booted VMS and Ultrix on September 3, 1991.
The three days in there was because we
had Labor Day holiday, and even with the holiday in there,
we booted that quickly.
In closing, I'd like to offer my congratulations
to all the people who worked so hard to deliver this chip.
The team worked for a long time and overcame lots of obstacles
to get something that ran this fast.
And their efforts should certainly be appreciated.
[MUSIC PLAYING]