Article View: net.micro.68k
Article #1172Re: 68030 data cache vs. IO devices
From: Hunter Scales
Date: Fri, 10 Oct 1986 23:14
Date: Fri, 10 Oct 1986 23:14
57 lines
3028 bytes
3028 bytes
In article <1624@vax1.fluke.UUCP> witters@fluke.UUCP writes:
>> Problem #1: if the chip decides to cache the value read from an
>> I/O device status register, subsequent reads will not produce the
>> current contents of that register.
>>
>
>I've read the data sheet for the 68851 PMMU, and the PMMU in the 68030 is
>supposed to be a stripped down version of the 68851. The 68851's translation
>descriptor for a page has a cache inhibit bit which, when set, will cause the
>CLI* (Cache Load Inhibit) signal to be asserted when the page is accessed.
>This signal can be used to inhibit the loading of an external data cache. I
>assume that the PMMU in the 68030 does the same thing internally with it's
>data
>cache as the 68851 would do with an external data cache.
This is exactly correct.
>
>> Problem #2: the caches are apparently built to slurp in 16 bytes
>> around any referenced location, on the theory that adjacent words
>> may be required soon. (While this makes good sense for instructions,
>> I'm not at all sure that I buy it for data.) This is *extremely
>> dangerous* for I/O devices, as adjacent locations (1) may not exist,
>> or (2) may have some active response to being read ... e.g. clearing
>> an interrupt request.
>
>Well, I would guess that the cache load inhibit bit would prevent this if it is
>set. I assume that it is the cache management hardware in the 68030 which does
>the 'slurping', and not the CPU. There isn't an analog to this in the
>68020/68851 combination, so I can't speak with authority here. Anyone from
>Motorola care to comment?
Burst fetches are inhibited if the CI (cache inhibit) bit is set.
>
>Your second problem raises another question. What happens if one of the 16
>bytes crosses a page boundary? Does the slurping stop at the page boundary,
>or does the 68030 try to read from the next page? Without thinking about it
>deeply, it seems possible that this could cause problems if the next page isn't
>mapped, or is mapped to an I/O device.
>
The burst fetches are modulo(4) (long words). As long as your
page size is greater than 16 bytes, you will never cross a page boundary
on bursts.
>--
>
> John Witters
--
Motorola Semiconductor Inc. Hunter Scales
Austin, Texas {ihnp4,seismo,ctvax,gatech}!ut-sally!oakhill!hunter
(I am responsible for myself and my dog and no-one else)
Technical Details
Message-ID:
<791@oakhill.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!columbia!rutgers!im4u!oakhill!hunterReferences:
<1007@zog.cs.cmu.edu> <1624@vax1.fluke.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!columbia!rutgers!im4u!oakhill!hunter From: hunter@oakhill.UUCP (Hunter Scales) Newsgroups: net.micro.68k Subject: Re: 68030 data cache vs. IO devices Message-ID: <791@oakhill.UUCP> Date: Fri, 10-Oct-86 19:14:18 EDT Article-I.D.: oakhill.791 Posted: Fri Oct 10 19:14:18 1986 Date-Received: Sat, 11-Oct-86 21:17:36 EDT References: <1007@zog.cs.cmu.edu> <1624@vax1.fluke.UUCP> Reply-To: hunter@oakhill.UUCP (Hunter Scales) Distribution: net Organization: Motorola Inc. Austin, Tx Lines: 57