apratt@atari.UUCP (Allan Pratt) (09/20/90)
Okay, for you chipheads out there, here's the scoop: The 68030 design bug I mentioned is in the cache logic. I/O space must be non-cacheable, so there's an INPUT to the 68030 called "CIIN" for Cache Inhibit INput. That line is checked on all reads, but it is NOT checked on writes. There is a bit in the cache control register called "write allocate:" when set, some writes to memory create an entry in the cache. If you write to I/O space with the "write allocate" bit on, the write can cause a cache entry to be created, even though the memory in question is non-cacheable. A subsequent read from the same address hits the cache before the CIIN is checked, so you get stale data. This only happens when you do a longword write at a longword boundary in I/O space, then read back any part of that longword before the cache line is re-used. You will read what you wrote, instead of reading what the device puts in its register. If it's a read/write register that the device doesn't change, you won't notice, but if it's the kind of register that means one thing when written and another when read, or if the device changes the value in the register, you will get bitten. To fix this problem, we use the MMU to map all addresses to themselves, but we set the "cache inhibit" bits for I/O space. The MMU's "cache inhibit" bit *does* get checked on writes, not just reads. This does not affect performance (much) because the MMU has a cache of its own, to remember recently-used address translations. Almost the whole table used by TOS fits in this cache, so the MMU won't be walking through memory very much translating addresses. We've timed it, and it just doesn't hurt that much: maybe 1%. The write-allocate bit is used by TOS so you can access the same memory in user mode or super mode and it won't confuse the cache. If you don't set the write-allocate bit, you could write something as supervisor, write it again as user, then read it as super and get the value of the first write, not the second one. This is a side-effect of the write-allocate bit, not its primary purpose. It's hard to find, but all this stuff is in the 68030 manual: the section in Chapter 6 (the cache) called "Write Allocate" is on point, as is the whole MMU chapter. Don't get clever with the MMU, though, because we're likely to want to use it in the future. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
buggs@cup.portal.com (William Edward JuneJr) (09/23/90)
Allen@atari, I don't understand the RAM situation in the TT. ST Report says that to run the TT @ 32 MHz you'd need 50nsec DRAMS. There isn't a cache, it's on the '030, right? Then there's slow RAM or some such. Could you please explain it in laymens<DAs like me *8^)> terms? Sure would be VERY 'preciated, thanks! Ed <gee, just bought a 20Mhz '386 to run UN*X too!> June
daveh@cbmvax.commodore.com (Dave Haynie) (09/25/90)
In article <34208@cup.portal.com> buggs@cup.portal.com (William Edward JuneJr) writes: > >Allen@atari, >I don't understand the RAM situation in the TT. ST Report says that to run > the TT @ 32 MHz you'd need 50nsec DRAMS. To run any 32 MHz 68030 at 0 wait states, you need a memory chip that can CYCLE in about 60ns. Even a 50ns DRAM isn't fast enough for a 32MHz 68030; you would need something on the order of 20-30ns SRAM. So, like most 68030 systems going above 12-16MHz or so, they add wait states. The number of clocks per memory access, more than the clock speed, will give you a clue as to the effective speed of a TT. >There isn't a cache, it's on the '030, right? There are separate, 256 byte, direct mapped caches on the 68030, one each for instructions and data. >Ed <gee, just bought a 20Mhz '386 to run UN*X too!> June -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM