Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!sei!ajpo!carters
From: carters@ajpo.sei.cmu.edu (Scott Carter)
Newsgroups: comp.arch
Subject: Re: 64bits: Area Overhead and Opportunity Costs
Summary: Cycle time effect rather than area cost
Message-ID: <757@ajpo.sei.cmu.edu>
Date: 19 Feb 91 23:59:02 GMT
References: <7967@exodus.Eng.Sun.COM>
Reply-To: carter%csvax.decnet@mdcgwy.mdc.com
Organization: McDonnell Douglas Electronic Systems Company
Lines: 43

In article <7967@exodus.Eng.Sun.COM> rtrauben@cortex.Eng.Sun.COM (Richard Trauben) writes:
>In article <1991Feb12.225634.13757@m.cs.uiuc.edu> (Don Gillies) writes:
>>[ 15% chip size increase for the R4000 to fully support 64-bit integers ]
>[reasonable assuming only 1/6 of the chip is integer datapath, and that
>integer datapath roughly doubles in size]

Yeah, it's not so much the size [hmm, I'd still kill for an additional 10% size
budget], but I worry a bit about cycle time effects:

ALU carry path only increases by one gate, but in a cache-superpipelined(tm)
design  like the R4000 I fear this may often be "the" critical path.

Datapath mux width doubles, which increases the fanout on all the controls
which drive said muxes.  With MIPSCo's super designers, I don't doubt that
they'll be able to put mega-drivers on all the appropriate points, but for
architectures which need to be implementable in a less optimized design
environment (e.g. our military/space designs which cannot afford full
custom design on the random logic) I worry about this.  Probably the right
answer is design tools which can better handle the highly variable fanout
problem at a higher level.

Also ...
>Let 1/3 of the area budget be on-chip cache, 1/3 floating point unit and
>1/3 be integer unit. A move to 64bits will have virtually no impact on
>the fp engine. While the area for tags double, large data block caches 
>(i.e. 32-64bytes/tag) make this increase in tag ram area neglectable.
Tag size only doubles if you have virtual-address caches, otherwise tag size
depends on physical address size (I doubt the R4000 has a 64-bit physical
address :) 
Still, I worry about this for those design points where you want/need a
virtual address cache, where the design point would otherwise be a shorter
line (a branch target cache would be an excellent example, if someone starts
wanting 64-bit instruction addresses for some reason (e.g. shared library 
tricks) - small on-chip caches in lower density processes like GaAs 
constitue a less contrived example).

>-Richard Trauben

Scott Carter - McDonnell Douglas Electronic Systems Company
carter%csvax.decnet@mdcgwy.mdc.com (preferred and faster) - or -
carters@ajpo.sei.cmu.edu		 (714)-896-3097
The opinions expressed herein are solely those of the author, and are not
necessarily those of McDonnell Douglas.