Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: 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

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)