A Look at the Xbox 360 CPU Design

  • Article

Jeffery Brown has posted his paper on the Xbox 360 CPU Design from the Fall Processor Forum over on IBM's DeveloperWorks.  Since I have my degree in hardware design, I always find these types of things interesting.  While this paper is at a relatively high level, I still found several of the details fun to read about.

Especially interesting was the section on testing, debugging, and design validation.  I clearly remember the day in ECE 323 (Hardware Design and Organization) when we discovered the benefits of adding test pins to our circuit design -- the final project for that class was to design a processor which executed some simple set of instructions and circuitry to host it.  In order to grade the project, we gave our professor the byes for each opcode, and he ran a program on the board.  If our design executed the program correctly we passed -- I believe that he had several different programs to step down to if you wouldn't work on the first one.

Needless to say, debugging a microcode programmed CPU design was no easy task -- and since we hadn't designed testing into the chip from the start, we were basically left hooking the oscilloscope up to various wires on the circuit board (wait -- which ones are the address bus again?), and executing repetitive code until we could narrow down the problems.  Obviously this was not the most productive use of our time, and the semester was quickly drawing to a close.

After a late night of debugging the circuit, I finally hooked up some test pins.  Basically there were two sets of debug pins -- input and output.  The output pins went to a set of multiplexers, which switched over the various interesting parts of the circuit, while the input pins controlled the multiplexers.  Finally there were one pair of input pins in particular which greatly aided debugging.  The first enabled single step mode -- basically set a flip flop, which caused the processor to only execute an instruction if the step flip flop was also enabled.  The second pin just set that step flip flop.  So the logic looked like:

ip = ip + ( (singleStep & doStep) | (!singleStep) )

This worked well since our opcode design was that each opcode fit into a single byte, so we only ever had to increment by one.  Once that was done, all that was left was to create a second debug circuit, which contained:

  • a seven segment display, with a decoder hooked up to the output debug pins
  • a set of toggles to select what the display was showing
  • a toggle switch to set debug mode
  • and a button to take one more step

Adding that basic debug support took a few hours that night, but the hours of time it saved us made it easily worth it.  And from that point on, the leson was learned.  Circuit design always included test and debug support from day one.

My other memory from that evening was getting back to the dorm after missing dinner due to getting this up and running.  I was starving, and was looking forward to microwaving up some Ramen (since most of the pizza places were also closed by that point).  My dorm room was right at the corner of the hallway, and as I rounded the corner my girlfriend at the time was coming around the other corner holding a bag with a Big Mac and super sized fries from the 24 hour McDonald's drive through in town.  Not that there's anything wrong with a Ramen dinner, but was that ever a sight for sore eyes! :-)

Updated 10:31 AM - fixed xbox link