Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!prls!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: comp.arch,comp.sys.nsc.32k,comp.sys.intel,comp.sys.m68k Subject: Re: Question: on-chip or off-chip MMU? Message-ID: <348@winchester.UUCP> Date: Mon, 27-Apr-87 03:32:10 EDT Article-I.D.: winchest.348 Posted: Mon Apr 27 03:32:10 1987 Date-Received: Tue, 28-Apr-87 01:32:17 EDT References: <5635@shemp.UCLA.EDU> <441@prairie.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 72 Xref: mnetor comp.arch:1108 comp.sys.nsc.32k:120 comp.sys.intel:206 comp.sys.m68k:417 In article <441@prairie.UUCP> dan@prairie.UUCP (Daniel M. Frank) writes: >In article <5635@shemp.UCLA.EDU> fan@CS.UCLA.EDU (Roy Fan) writes: .... >> What are the important deciding factors in designing a MMU >>on-chip or off-chip? .... >> Question 2 : if there is enough space on the chip, would >>everybody put the MMU on-chip? > > I suppose so. If there was enough space (and they could cool it!), >they'd try to put EVERYTHING on the chip. > >> Question 3 : if there is only enough room for either a cache >>or a MMU, which one will prevail? > > My knee-jerk response is: it is so hard to really integrate an external >MMU with a pipelined processor, that you'll win by putting the MMU and a >small cache on chip, and putting a larger cache off-chip. I hear the two >level cache worked out pretty well in the Microvax. As usual, it really depends on what you think you're building. Almost any cache of any reasonable size is better than having no cache at all, if you're careful. For cache verus MMU: 1) If you're building controller chips that can easily get along without an MMU, then you might as well put a small I-cache on board, if nothing else. Even small I-caches work. [68020] 2) If you're building a "system" chip, then you're awfully tempted to put the MMU on-chip, assuming there's enough space to make it "big enough" to get adequate hit rates for the applications you intend to run. Note that the hit rates of small TLBs are much better than those of small caches. 2a) To minimize baord space, you might put the MMU on-chip, and build special cache-rams, or else build special MMU/cache chips [Clipper; 78000?] In this case, the tradeoff is to accept a cap on performance if you can't beef up the caches when you want to. 2b) To go for all-out performance, at some cost in board space, put the MMU on-chip, use ordinary SRAMs, and also put the cache control on-chip [MIPS R2000]. Here, the tradeoff is that the minimum board space is slightly larger than 1) or 2A), but you have more high-end left by adding more SRAMs. It is clear that on-chip caches, by themselves, simply CANNOT be made large enough in current technologies to get into the higher performance regions. [The following is a generalization. All generalizations are false:] ASSUMING YOU WANT TO RUN SUBSTANTIVE PROGRAMS, AND NOT CROAK RUNNING MULTI-USER UNIX: [all this for integer operations; FP has different ratios]: 2-3 Mips [VAX 11/780, 4.3BSD == 1] seems to be about the limit for systems with 1K or less cache. Examples: good 16.7MHz 68020 = 2 Mips [Sun3/160] : good 20MHz 68030 = 3 Mips [wild guess; I really don't understand how the data cache is really going to behave] : cacheless 386 = 2 Mips Possible exception: newest IBM RT PC, which might be 3-4Mips 3-5 Mips: Examples: : good 25MHz 68020 [with 64K cache, 64-bit buses, in Sun3/260] = 4 Mips : good 386 with 64K cache = 4 Mips [?] : Clipper with 4K+4K caches = ? Mips [can't tell from the published numbers] guess about 3-3.5 if kernel-intensive ones included : good 68030, 25MHz [whenever, not announced at this speed] guess = 5Mips by comparing with 4Mips, no-wait-state Sun3/260 : R2000 with 24K cache = 5 Mips; with only 16K, was more like 4 Mips I.e., some performance levels REQUIRE external caches. A whimsical way to put it is that a fast CPU is just a way for fast SRAMs to reach self-actualization, i.e., max performance. :-) -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086