jason@cbmami.UUCP (Jason Goldberg) (03/12/91)
What options do most 68030 users normally use. I have an A2630 and typically run with INST CACHE ON, and DATA CACHE OFF, is it pretty safe to run with both CACHE's on? Is this the same situation with the GVP boards? Also, with the GVP cards is there any reason not to have the BURST mode on for both the DATA and INST? Thanks, -Jason- --------------------------------------------------------------------------- Jason Goldberg UUCP: ucsd!serene!cbmami!jason Del Mar, CA
daveh@cbmvax.commodore.com (Dave Haynie) (03/15/91)
In article <18cfc42d.ARN0f05@cbmami.UUCP> jason@cbmami.UUCP writes: >What options do most 68030 users normally use. I have an A2630 and >typically run with INST CACHE ON, and DATA CACHE OFF, is it pretty safe to >run with both CACHE's on? Is this the same situation with the GVP boards? Assuming the board was designed with proper cache support, you should never have any problem turning on both caches and both cache burst enables on any 68030 system. The one thing to watch for is a _potential_ problem with caches and DMA devices. The small 68030 caches make the chances of a real problem minimal, but it is technically possible for the 68030 to access stale data in either cache after a DMA transfer. The A2091 software will actually flush the cache after an I/O operation completes, but in general, this isn't anything to greatly worry about. Whether or not it supports burst, all 68030 memory systems are required to work properly when burst is enabled. Testing in our software department has indicated that the burst mode helps out for the I-Cache, but doesn't for the D-Cache. Your mileage may, of course, vary, but keep in mind that typical small benchmark programs are not represenative of actual AmigaOS code/data behavior. >Jason Goldberg UUCP: ucsd!serene!cbmami!jason -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
tsarna@polar.bowdoin.edu (Tyler Sarna) (03/15/91)
In article <19871@cbmvax.commodore.com> of comp.sys.amiga.hardware, Dave Haynie <daveh@cbmvax.commodore.com> wrote: > stale data in either cache after a DMA transfer. The A2091 software will > actually flush the cache after an I/O operation completes, but in general, Perfect timing, Dave! Someone just asked me how to flush the cache(s), and I don't have the foggiest. Is there an easy way to make it compatible with all 680x0, or would a program have to determine CPU type? If the latter, would it be the same code for 020/030 or not? Thanks for your help! ------///------------------------------------------------------------ /// Tyler "Ty" Sarna E-Mail: tsarna@polar.bowdoin.edu \\\/// "Welcome to the Late Show/Starring Null and Void" - Men@Work --\XX/---------------------------------------------------------------
daveh@cbmvax.commodore.com (Dave Haynie) (03/19/91)
In article <47678@nigel.ee.udel.edu> tsarna@polar.bowdoin.edu (Tyler Sarna) writes: >In article <19871@cbmvax.commodore.com> of comp.sys.amiga.hardware, >Dave Haynie <daveh@cbmvax.commodore.com> wrote: >> stale data in either cache after a DMA transfer. The A2091 software will >> actually flush the cache after an I/O operation completes, but in general, >Perfect timing, Dave! Someone just asked me how to flush the >cache(s), and I don't have the foggiest. The only way to do this, under 1.3, is to actually run the "movec dn, cacr" instruction. You'd have to read the cacr, set the "clear cache" bits for I and D caches, and then write it back. This will clear the caches properly for 68020 and 68030, but not for 68040 or any external cache that might need clearing. And it will break on a 68000, for example, which doesn't know about movec to cacr. Under 2.0, there's a system call to be used for cache clearing, which can be called for any system, and would even work with external caches (any external cache added to the system would vector in a call for its own cache hardware as well as any on-chip cache). > /// Tyler "Ty" Sarna E-Mail: tsarna@polar.bowdoin.edu -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
markv@kuhub.cc.ukans.edu (03/26/91)
>>> stale data in either cache after a DMA transfer. The A2091 software will >>> actually flush the cache after an I/O operation completes, but in general, > >>Perfect timing, Dave! Someone just asked me how to flush the >>cache(s), and I don't have the foggiest. > > ...This will clear the caches properly for 68020 and 68030, but not > for 68040 or any external cache that might need...Under 2.0, there's > a system call to be used for cache clearing, which can be called for > any system, and would even work with external caches... A query and a request? One thing I havn't seen mentioned is the 68040's MMU's ability to monitor the bus, and update its caches on accesses to cached RAM, and to inhibit RAM and supply a valued for a cached address that hasn't been "written thru". This would eliminate the cache coherency problem and avoid the severe performance hit your going to take if you have to flush 4K of cache on *every* DMA I/O (unless there's some more intellegence in the process). My questions are, does the 3000's CPU slot have the signals available that would let it do this for motherboard RAM, or would it be restricted do any "on-board" RAM. Second, I don't think anyone doubts that Commodore is working on some kind of 040 board/machine and it sure would be nice if this feature is supported... Otherwise, what about a few more OS extensions that expliot the PMMU to inhibit cacheing of regions used for DMA buffers (this of course is in the direction of my dream of OS support for the MMU in general, maybe some flags like MEMF_NOCACHE and MEMF_NOPAGE, locking blocks, etc). > -- > Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "What works for me might work for you" -Jimmy Buffett -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
daveh@cbmvax.commodore.com (Dave Haynie) (03/27/91)
In article <1991Mar26.095729.29291@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >A query and a request? One thing I havn't seen mentioned is the >68040's MMU's ability to monitor the bus, and update its caches on >accesses to cached RAM, and to inhibit RAM and supply a valued for a >cached address that hasn't been "written thru". This would eliminate >the cache coherency problem and avoid the severe performance hit your >going to take if you have to flush 4K of cache on *every* DMA I/O >(unless there's some more intellegence in the process). >My questions are, does the 3000's CPU slot have the signals available >that would let it do this for motherboard RAM, or would it be >restricted do any "on-board" RAM. It's probably possible. The A3000's Coprocessor slot supports a signal that allows a Coprocessor device to intercept an address intended for either onboard Fast RAM or for expansion space. So, in theory, a 68040 or other bus snooping device could monitor system addresses and respond with its own data, rather than the data in that particular location. Extra logic would be required on the Coprocessor card, of course; I'm not implying that the A3000 Coprocessor slot implements the 68040 bus snooping protocol, only that it's possible to map some bus snooping protocol onto the signals there, with extra logic. The main intention of that signal (called WAIT*) is to allow "bus-attached" cache devices. In most cache systems, the cache kind of sits between the processor and the rest of the world. You can add a cache to the Coprocessor slot on the A3000, however, obviously without inserting it between the on-board CPU and the rest of the motherboard. This is done by using the WAIT* signal. The CPU sends out its address, which is examined by the cache device, holding WAIT* true. If the address isn't cached, the device releases WAIT* and the normal memory device responds. If it is, the cache supplies the data and terminates the cycle. >Otherwise, what about a few more OS extensions that expliot the PMMU >to inhibit cacheing of regions used for DMA buffers (this of course is >in the direction of my dream of OS support for the MMU in general, >maybe some flags like MEMF_NOCACHE and MEMF_NOPAGE, locking blocks, etc). Good ideas they are. The current OS suggests a cache flush after a DMA operation, which works, but if you guarantee a specific chunk of memory would be uncachable during such a transfer, you'd be more efficient. Of course, the bus-attached cache I described above doesn't need to be cleared after a DMA, since it monitors all bus activity, and can cache DMAC cycles just as easily as CPU cycles if you let it. >Mark Gooderum Only... \ Good Cheer !!! -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
daveh@cbmvax.commodore.com (Dave Haynie) (03/30/91)
In article <4517.27EAC576@voice> Thomas.Dorn@p3.f42.n310.z2.at (Thomas Dorn) writes: >From: daveh@cbmvax.commodore.com (Dave Haynie) > DH> Assuming the board was designed with proper cache support, you should > DH> never have any problem turning on both caches and both cache burst > DH> enables on any 68030 system. >If you have a Framebuffer in your Amiga 3000, and this buffer is only >Zorro II compatible, there are great problems, if you don't switch off >the Data-Cache! My comment above is referring only to the 68030 board itself. Any 68030 board and 68030 memory device should support cache and burst, even if burst isn't actually used by the memory subsystem (like A2630). There is a basic problem with cache support and Zorro II. The Zorro II bus was designed long before any hard thought was given to cache support of any kind. We have adopted a convention for Zorro II that splits up the available Zorro II address space into I/O (uncached) and Memory (cached) regions. The 8 Meg chunk starting at $00200000 is Memory, the 512K at $00e80000 and (A3000 only) 1.5 Meg at $00a00000 are I/O. Things like FrameBuffers, BridgeCards, and perhaps another goody or two break under this model -- they're I/O devices that don't neatly fit in the 512K I/O space. The simple solution to use them is to turn off the data cache. Perhaps a better solution would be an A3000-MMU-Setup update of a program I wrote called CacheCard, which allows the caching of individual cards to be controlled by the MMU tables (aways present in current A3000s). In Zorro II, there's an autoconfig bit that says "Prefers the 8M space", a hint to the OS that the card in question wants to be located in the 8M space, rather than being placed in I/O space somewhere. While I don't know the original need for this bit, the Zorro III convention uses it to allow a board to state that it's either basically a memory board (cachable) or basically an I/O board (uncachable). If that same convention were applicable to Zorro II, a CacheCard replacement could be automatic; reading the expansion database and marking any I/O device as uncachable, rather than going the CacheCard route, where every uncachable card must be explicitly listed. >Greetings from Vienna (cbmvie) I had a blast in Vienna! One of these days, I'll have to write up my expense report for it .... > UUCP: ...!tuvie!edvvie!voice!42.3!Thomas.Dorn -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.