💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › FAQs.and.INFO › Accelerators … captured on 2024-12-17 at 12:40:14.
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Newsgroups: comp.sys.apple2 Subject: Re: IIgs Zip accelerator SRAM speeds From: dempson@actrix.gen.nz (David Empson) Date: Wed, 27 Aug 1997 23:03:43 +1200 Message-ID: <19970827230343817275@dempson.actrix.gen.nz> References: <5tsopj$gt5@gandalf.Advent.COM> Organization: Empsoft X-Newsreader: MacSOUP 2.2.1 NNTP-Posting-Host: dempson.actrix.gen.nz Lines: 113 Path: news1.icaen!news.uiowa.edu!news1.chicago.cic.net!iagnet.net!infeed1.internetmci.com!newsfeed.internetmci.com!202.14.100.1!status.gen.nz!news.iprolink.co.nz!news.actrix.gen.nz!dempson Stephen McGrogan <smcgroga@gandalf.Advent.COM> wrote: > My question is, if 65ns SRAMs work at 7-8 mhz (28-32mhz oscillators), > why do I need 15ns SRAMs to run at 12-15mhz (48-60mhz oscillator)? > What is the actual relationship between the SRAM speed and the > oscillator clock speed? I don't think anyone has ever described a clear relationship between the clock frequency and required cache RAM speed. The following is my current theory on how it might work. I make no claims that this theory is correct! In general, the speed of the TAG RAMs is more important than the speed of the DATA RAMs. The DATA RAMs need to be fast enough to complete an access in about half to three quarters of a CPU cycle, thus the required speed is somewhere between (2 / F) and (3 / F) where F is the oscillator frequency. The TAG RAM may need to be faster than this. I don't know exactly how the ZIP implements its tag mechanism, but it needs at least two pieces of information for each DATA byte: 1. Is this byte valid? 2. Which bank does this byte come from? The first item could be implemented by reserving an illegal bank number (e.g. $EF). If the ZIP has less than 64K of cache, it also needs to know the top one or two bits of the address within the bank. This means that it needs more than one byte associated with each data location. This could be handled by sharing tag locations between two data bytes, but this would mean the tag RAM has to be read twice. I suspect that the ASIC has a small amount of RAM internally, which is used to hold the extra tag information if there is less than 64K of cache. It would need 32768 bits (two bits for each location in a 16K cache), which is only 4096 bytes - not too large to fit inside an ASIC. Given these assumptions, the ASIC could handle the cache by simultaneously reading the TAG and DATA locations, and deciding whether a main memory read is required as soon as the TAG information is available. The DATA information might not be needed as quickly. The ASIC has to wait until the CPU has generated the address (about a quarter of the way through the cycle) before it can address the cache. It can use the VPA and VDA signals to identify when the address is ready. The decision about whether the right location is in the cache is probably synchronized to the oscillator (4 times the CPU cycle), so I expect the TAG RAM would have to be able to complete an access within half a cycle (assuming the decision about using the cache is made at the 3/4 point in the CPU cycle). For a cache hit, the DATA RAM is already outputting the appropriate value, and it will be ready by the end of the cycle. For a cache miss, the ZIP needs to synchronize with the clock speed of the main computer. This is the really tricky bit that I haven't thought through yet. If the ZIP wants to improve the average synchronization time, it could require the TAG RAM to be twice as fast as the DATA RAM, but this doesn't appear to be the case (from observation of shipped ZIPs at speeds from 7 MHz to 9 MHz). Now for the explanation of why you need faster TAG RAM at higher speeds: there are probably delays introduced by discrete logic and/or the ASIC itself, which use up a constant amount of time. At lower frequencies this isn't significant, but as the clock frequency increases you need substantially faster TAG RAM to compensate for this fixed delay. Another factor is that the TAG information is probably needed earlier in the cycle than the DATA. Assuming my theories are correct, the required speed range of the DATA RAM is somewhere between the following limits: CPU Oscillator ------- DATA RAM speed ---------- Freq. Freq. (F) min (2/F) max (3/F) est (2.5/F) 7 MHz 28 MHz 71 ns 107 ns 89 ns 8 MHz 32 MHz 62 ns 93 ns 78 ns 9 MHz 36 MHz 55 ns 83 ns 69 ns 10 MHz 40 MHz 50 ns 75 ns 62 ns 12 MHz 48 MHz 41 ns 62 ns 52 ns 14 MHz 56 MHz 35 ns 53 ns 44 ns 16 MHz 64 MHz 31 ns 46 ns 39 ns From observation of the RAM speed supplied in new ZIPs, it looks like the required DATA RAM speed is around (2.5 / F). The slowest RAM I've seen was 70 ns in a 9 MHz ZIP. The TAG RAM speed might be a different ratio with a constant offset, e.g. (3/F - 30 ns). This means that you would need 16 ns TAG RAM at 16 MHz, for example, but still only need 63 ns at 8 MHz. One final issue to consider: REMcorp could be testing and hand-picking RAMs that actually run a little faster than their printed speeds, so your "65 ns" RAM might be 61 ns, for example. > The FAQ also indicated that one of the interface chips needed > replacement for higher clock speeds. I bought the new chip, but, > strangely, it has a slower response characteristic, according its > specs, than the version that is already installed. Yes, that is right. I think the issue is more related to the power consumption, voltage levels or driving/loading characteristics, rather than the speed. (The 74F00 part is significantly faster than would be needed on the fastest possible ZIP GS, and the 74HC00 is fast enough.) -- David Empson dempson@actrix.gen.nz Snail mail: P.O. Box 27-103, Wellington, New Zealand