IEEE Solid-State Circuits Magazine - Summer 2016 - 22

Over the next three years, I spent every
summer and January break working at NBS.
can be useful to have the cart before the
horse, so the students can recognize
the value of the horse when they see it.
It was also in this class that I first
remember working on a technique
that I have honed my whole life: working hard to be lazy. Let me explain.
As part of my financial aid package at
MIT, I got a job in the Logo Lab, where
I had access to some of the machines
that people in the AI lab used. At that
time Macsyma, one of the first symbolic math programs, was available
on this machine, and I often used it to
work out some of my homework problems for this class. I did this since I
hated plug and chug problems since
I was prone to making silly mistakes.
Almost always the answer would turn
out to be very simple.
When this happened I knew, or at
least thought, that this result meant
there was probably a very simple
way to solve this problem that didn't
require much algebra, and I would
spend hours trying to find the simplest way to generate the answer.
Usually I did find a way to "fold" the
problem so the answer was obvious,
and I would write that solution as
my homework solution. For me this
was another puzzle to solve, just like
finding ways to take things apart,
where the more puzzles you solved,
the easier each new puzzle became.
While initially this exercise did take
considerable time, over time I became
quite good at finding simpler ways to
analyze complex circuits. This early
work allowed me to accomplish my
goal: appearing to be smart, while
actually being very accomplished at
being lazy.
While I continued doing design for
fun, my largest project was for my
digital design lab at MIT. One of my
suitemates at MIT, Greg Thompson,
was one of the originators of the first
first-person shooter games, Maze Wars,
which ran on Imlac graphics processors

s u m m E r 2 0 16

at NASA Ames. He brought the game to
MIT and suggested that we try to build
the complete game in hardware for our
lab project. This seemed like a good
idea to me and another suitemate,
George Woltman, so we talked with
the lab TAs about our plan. They told
us that they thought it was a bad idea,
since the project was way too complex,
but they wouldn't stop us from trying it. That was all the permission we
needed. We were sure we could get it
to work. I guess I was not the only one
to have excessive confidence.
The technology at the time was
pretty primitive. We had access to cards
with some TTL components on them,
which you plugged into a rack that you
then wired up. You needed to load data
through paper tape on a teletype (talk
about being unreliable), and the program had to be stored on UV erasable
PROM that held only 256 words of program memory. Greg built the main processing unit, George was in charge of the
microcode for that computer, and I built
the graphics processor. My first challenge was how to generate the display.
Looking around the lab, the only
graphic displays available were the
oscilloscopes used to display our
designs. So we chose to run them in
x, y mode, which would allow us to create a vector display. (We actually generated four different player displays by
creating a separate blanking signal for
each display and used the same x,y generation for all of them.) We decided to
build our machine early to make sure
the lab still had the parts we needed.
Again the good-luck fairy smiled on us,
and we actually got the project to work.
George even crammed his code so tight
that in his 256 instruction program he
was able to implement robots, and I
was able to add visible bullets!
By my junior year it was clear that
I wanted to learn more about ICs, but
at the time, MIT didn't do any research
in silicon ICs. So I ended up getting

IEEE SOLID-STATE CIRCUITS MAGAZINE

a research assistantship position at
Lincoln Labs and worked there for
my bachelor's and master's theses. I
started working on my master's for a
very simple reason: money. MIT paid
masters students, while undergrads
paid MIT. It was during this time
that I learned two important lessons
about presenting research:
■ The quality of a paper is often inversely proportional to its length.
■ You know you have given a bad
talk when you hear people talking about how smart you are. Conversely, you have given a great talk
when people say that it was a good
idea, but they could have done the
work themselves.
A colleague at Lincoln told me
the first point. His explanation was
simple. When you truly understand
what you are writing about, it doesn't
take that long to set up the problem,
explain the dependencies, and then
show the data that confirms your
results. However, when the results are
less clear, you spend more time showing all your data and explaining many
potential relationships. With some
exceptions, I have found this rule to be
surprisingly true. I really understood
the problem I was trying to solve for
my bachelor's thesis, and it was under
100 pages. My master's thesis was less
clear to me, and it clocked in at about
double the pages.
I heard the second piece of advice
from my older brother, who heard it
from his advisor. Many people think
you must be smarter than they are
if they can't understand your talk.
But like writing a short paper, if you
deeply understand the topic, you
should be able to present it in a way
that makes the results, well, seem
obvious. The best talks are the ones
that can present a new way to look at
a problem so the results seem simple.
Given this new vantage point, you
hope the audience now finds the topic
less daunting. This early advice also
rang true in my career.

Hello Silicon Valley
After graduating from MIT in 1978, I
moved out to Silicon Valley and got a

Table of Contents for the Digital Edition of IEEE Solid-State Circuits Magazine - Summer 2016