Path: utzoo!attcan!uunet!lll-winken!ames!oliveb!apple!voder!pyramid!prls!philabs!linus!alliant!craig
From: craig@Alliant.COM (Craig Maiman)
Newsgroups: comp.arch
Subject: Re: In defense of the VAX
Message-ID: <3004@alliant.Alliant.COM>
Date: 24 Feb 89 15:35:53 GMT
References: <4592@tekgvs.LABS.TEK.COM> <cXvqKRy00Wo=0TV282@andrew.cmu.edu> <638@m3.mfci.UUCP> <11037@tekecs.TEK.COM> <653@m3.mfci.UUCP> <2066@pembina.UUCP> <660@m3.mfci.UUCP>
Reply-To: craig@alliant.Alliant.COM (Craig Maiman)
Distribution: na
Organization: Alliant Computer Systems, Littleton, MA
Lines: 22


I was on the VAX 8600 design team and I can tell you several reasons
why the machine was late.  I joined in the second half of that project,
so I wasn't there when the first delays occured, but was told about the
initial delays.  At first the machine was register based but it was decided
to go with latches (A wise move) => delay #1.  Some time later after design
was well on the way they realized that instruction decode and address
translation was not going to fit in one cycle, so add a pipe stage!
=> delay #2.  Bad management with subsequent changes of the guard =>
delay #3.  I joined during delay #3 and worked on the IBOX team.  I discovered
that the two designers of the IBOX didn't talk much so their logic didn't
talk much either (timing wise).  My job -> fix it => delay #4.  This
was bad "timing" because the chips were ready to go to fab and the timing
analysis was just starting along with CPU gate level simulation.  This
lead to many revs of chips => delay #5.  As you might imagine debug was
around the clock and took longer than it should have.

I would definitely agree that the VAX architecture was ill-suited for
a pipelined approach.  But it was well suited for its time and
hindsight is always 20/20

						Craig Maiman