sean@ms.uky.edu (Sean Casey) (02/02/88)
The problem that people have brought up is that a DMA device
will screw up a system running a data cache. Since the 68030
has an onboard data cache, enabling it would screw up things for
an Amiga, which has several DMA devices.
It seems to me that the chip designers would have considered this. *I*
would have considered it. Surely the onboard MMU can be told that certain
pages of memory are not to be cached. Could someone who has the specs
for the processor check this out?
--
-- Sean Casey sean@ms.uky.edu, sean@ukma.bitnet
-- (the Empire guy) {rutgers,uunet,cbosgd}!ukma!sean
-- University of Kentucky in Lexington Kentucky, USA
-- "If something can go will, it wrong."haitex@pnet01.cts.com (Wade Bickel) (02/03/88)
sean@ms.uky.edu (Sean Casey) writes: > >The problem that people have brought up is that a DMA device >will screw up a system running a data cache. Since the 68030 >has an onboard data cache, enabling it would screw up things for >an Amiga, which has several DMA devices. > >It seems to me that the chip designers would have considered this. *I* >would have considered it. Surely the onboard MMU can be told that certain >pages of memory are not to be cached. Could someone who has the specs >for the processor check this out? > Ahh, It was my understanding the cach is internal to the 69030. Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
mph@rover.UUCP (Mark Huth) (02/06/88)
In article <8179@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: > >The problem that people have brought up is that a DMA device >will screw up a system running a data cache. Since the 68030 >has an onboard data cache, enabling it would screw up things for >an Amiga, which has several DMA devices. > >It seems to me that the chip designers would have considered this. *I* >would have considered it. Surely the onboard MMU can be told that certain >pages of memory are not to be cached. Could someone who has the specs >for the processor check this out? I've got the specs, and the chip designers did think of this problem. The MMU is basically a subset of the 68851 MMU chip. One of the fields in the translation structure is a cache inhibit bit. The value of this bit is output to a cache inhibit output to allow the MMU to inhibit external caches. The internal caches are also inhibitted by this field. Sooo.. the exec should set up the MMU translation tables to inhibit caching of any memory that might be the target of writes by other bus masters. Additionally, there is a cache inhibit input to the 68030. This allows external hardware to inhibit caching on a cycle by cycle basis. This all leads to the conclusion that the 68030 will work in a multi-master system. Now whether it will really work in the Amiga remains to be seen. Mark Huth
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (02/07/88)
In article <8179@g.ms.uky.edu>, Sean Casey (sean@ms.uky.edu) writes: > The problem that people have brought up is that a DMA device > will screw up a system running a data cache. Since the 68030 > has an onboard data cache, enabling it would screw up things for > an Amiga, which has several DMA devices. > > It seems to me that the chip designers would have considered this. *I* > would have considered it. Surely the onboard MMU can be told that certain > pages of memory are not to be cached. Could someone who has the specs > for the processor check this out? The 68030 does indeed have a descriptor for each page that indicates whether or not the page is cacheable (I/O devices, for instance, should not be cached!). In addition, there is a line which allows external hardware to specify, on a cycle-by-cycle basis, whether data from a given access should be cached. This is not the whole picture, though! If disk I/O is requested, there is no reason (in principle) that the buffer cannot simply be malloc-ed and the address passed to the DMA controller. Unfortunately, this would then require passing the information to the operating system that its page descriptor tables need to be updated. If you have only one DMA device, you can special-case your way around the problem. A general solution requires more thought, however, to avoid losing in system overhead what you gain from DMA. When you have a processor with the power of the 68030, the most effective solution is to hide the I/O devices behind a dual-ported RAM, DMA into the dual-ported RAM, and then move the data to its intended recipient with the CPU. Steve Rice ----------------------------------------------------------------------------- * Every knee shall bow, and every tongue confess that Jesus Christ is Lord! * new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever