Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!think!nike!oliveb!glacier!Shasta!simoni
From: simoni@Shasta.STANFORD.EDU (Richard Simoni)
Newsgroups: net.arch
Subject: Re: MC68030 Cache Organization
Message-ID: <882@Shasta.STANFORD.EDU>
Date: Wed, 1-Oct-86 20:09:24 EDT
Article-I.D.: Shasta.882
Posted: Wed Oct  1 20:09:24 1986
Date-Received: Fri, 3-Oct-86 11:17:22 EDT
References: <5100146@ccvaxa>
Reply-To: simoni@Shasta.UUCP (Richard Simoni)
Organization: Stanford University
Lines: 28

In article <5100146@ccvaxa> aglew@ccvaxa.UUCP writes:
>
>Motorola 68030 Cache Organization
>---------------------------------
>Oh, another thing: TLB address translation is done in parallel with
>cache access. Does this mean that the cache is virtual?

This doesn't necessarily follow.  Address translation is often done in
parallel with cache access by using only the low-order bits of the virtual
address (i.e., the bits that indicate the offset within the page) to address
the cache.  This is possible because these offset bits do not change in
the virtual-to-physical mapping.  When the cache access is complete, the
tag (which is a physical page number) is compared with the result of the
address translation (which happened in parallel with the cache access) to
see if a hit occurred in the cache.

The problem with this scheme is that it can be difficult to build a large
cache since the page size limits the number of bits that can be used to
address the cache.  The size of the cache can be increased by making the
cache set-associative and/or by increasing the page size (thereby
increasing the number of bits that can address the cache).  Of course, an
on-chip cache (as in the 68030 case) will not be very large, anyway.

Rich Simoni
Center for Integrated Systems
Stanford University
simoni@sonoma.stanford.edu
...!decwrl!glacier!shasta!simoni