Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!zaphod.mps.ohio-state.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: 64bits: Area Overhead and Opportunity Costs Message-ID: <46046@mips.mips.COM> Date: 20 Feb 91 21:50:19 GMT References: <7967@exodus.Eng.Sun.COM> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 48 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: >>I read an article today in "The Microprocessor Report" that said the >>increase from 32 to 64 bits added approximately 10-15% to the size of >>the chip. This is quite surprising. You'd think that going from 32 >At first blush, the projected 15% area overhead for increasing the datapath >width from 32bits to 64bits DOES sound very low. However, consider the ... >This back of the envelope calculation says area would increase by 17% >by pasting a 64-bit IU core onto a generic design. Obviously the exact >mileage will vary somewhat. >It also suggests, for a fixed manufacturable die size with all other things >being equal, that the quantitative cost to the customer for going to 64bit >addressing in advance of truly needing it is analogous to not providing 1/2 >the capacity of on-chip cache that they might have had otherwise. A common >rule of thumb states that doubling the cache size will half the overall cache >miss penalty. This is a pretty good estimate. I have some slightly better numbers, although gathered informally (using a ruler on a chip plot, and rounding everything). I also split it up a little differently, and my earlier estimates (which is where some of the published numbers come from, i.e., some offhand comments) were actually a little high. Take all of the following within +/- 2%. The integer data path (+ some of its control; I wasn't too fussy) are about 14%, and the MMU/CP0 chunk is about 5% (it has to be wider, also). *** Altogether, I expect this all means that the die space cost was around 7-8% to get 64-bit integer data path and addressing. *** Now, the caches together are about 14% also, so maybe we could have doubled one of the caches, which would have been nice. On the other hand, I think there would have been some awkward layout issues, i.e., it might have been possible, but would have been hard, especially looking forward to a design that one can rapidly expand the cache sizes without re-laying-out everything in sight. (Note that caches like certain shapes more than others, and are nontrivial to squeeze into weird-shaped holes :-) -- -john mashey DISCLAIMER: UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086