Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 UW 5/3/83; site uw-june
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!houxm!vax135!cornell!uw-beaver!uw-june!trow
From: trow@uw-june (Jay Trow)
Newsgroups: net.arch
Subject: Re: 68020 Performance Revisited Again
Message-ID: <1963@uw-june>
Date: Thu, 8-Nov-84 01:42:31 EST
Article-I.D.: uw-june.1963
Posted: Thu Nov  8 01:42:31 1984
Date-Received: Fri, 9-Nov-84 08:32:51 EST
References: <4108@decwrl.UUCP>
Reply-To: Deutsch@Xerox.arpa
Organization: U of Washington Computer Science
Lines: 22


Forwarded from 68000Interest^.wbst@Xerox.arpa

----------------------------------------------------------------

From: deutsch.pa
Date:  7-Nov-84 10:15:07 PST
Subject: Re: 68020 Performance Revisited Again

I am sorry that I didn't make my argument about off-chip cache performance
sufficiently clear.  ONLY THE CACHE need respond within the 120 ns window.
Since the cache is assumed to use virtual addresses, the MMU and virtual
address translation machinery only comes into play in the case of a cache
miss.  Of course, if these functions are slower, the overall system
performance will be slowed down, but only proportionately to the
frequency of cache misses.  A custom-design cache chip with a 100 ns
designed response time should be well within the capabilities of
current technology.

----------------------------------------------------------------