Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!cornell!batcomputer!itsgw!imagine!pawl23.pawl.rpi.edu!jesup
From: jesup@pawl23.pawl.rpi.edu (Randell E. Jesup)
Newsgroups: comp.arch
Subject: Re: RPM-40 microprocessor @ 40 MHz; dat
Message-ID: <476@imagine.PAWL.RPI.EDU>
Date: 5 Mar 88 08:09:10 GMT
References: <9758@steinmetz.steinmetz.UUCP> <9800@steinmetz.steinmetz.UUCP>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: beowulf!lunge!jesup@steinmetz.UUCP
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 43

In article <9800@steinmetz.steinmetz.UUCP> oconnor%sungod@steinmetz.UUCP writes:
>An article by bcase@apple.UUCP (Brian Case) says:
>] I still agree that the ALU should govern cycle time (but I would always
>] include bypassing; in my experience, there just isn't enough stuff to move
>] around to spearate the computations from the uses with useful work a
>] significant fraction of the time), but I now know that a much more
>] probable cycle time determiner is cache cycle time.  This can be either
>] the instruction cache, or the TLB, or whatever.  I suspect that omitting
>] bypassing is a bad choice, but like you say, there isn't much "proof."

	Another point: even without bypassing, if you're using the ALU for
address computation you can store the results of a ALU op in the next
instruction.  This removes a lot of whatever loss you have in not having
bypassing, since <modify;store> and <load;modify;store> are fairly
frequent operations.  Once again, you must look at your assumptions with
skepticism in RISC design: calculate what it will cost you to implement
a feature, then how much you gain.  Also, remember that other peoples 
figures/assumptions may not match yours, especially if they are focusing
on a specific part of performance (like integer-only, or FP-only, etc).

>Smaller caches, like the RPM40 TIB cache, are faster. And can
>be just as effective. But I'm not sure the details of the TIB
>have been released. I'll expand on it if it has been. What happened
>with RPM40 was : whenever anything was too slow to make 40MHz,
>additional design effort was thrown at it until it was fast enough.
>This means we have several near-critical paths. This would have been
>impossible without a good process model and simulation tools, of course.
>Did I ever mention that the ALU was laid out about a half-dozen times
>so it would make speed ? 

	Dennis, I think the title of the ISSCC talk was "40 Mhz CMOS CPU with
instruction cache", so I think it's ok.  Not like it's a patentable idea,
anyway. :-)

	There were quite a few go-rounds on some of the paths, if I remember.
But running at 40 Mhz in wirewrap shows we designed plenty conservatively.
I wonder how fast we could crank it up in the high speed board at room temp?

     //	Randell Jesup			      Lunge Software Development
    //	Dedicated Amiga Programmer            13 Frear Ave, Troy, NY 12180
 \\//	beowulf!lunge!jesup@steinmetz.UUCP    (518) 272-2942
  \/    (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup

(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)