Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ulowell!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga.tech Subject: Re: Amiga 2500UX Availability & Technical Stuff + Bridgeboard? Message-ID: <6047@cbmvax.UUCP> Date: 22 Feb 89 18:21:45 GMT References: <0130z74c1z1010p0ANE@amdahl.uts.amdahl.com> Distribution: usa Organization: Commodore Technology, West Chester, PA Lines: 86 in article <0130z74c1z1010p0ANE@amdahl.uts.amdahl.com>, shs@uts.amdahl.com (Steve Schoettler) says: > In article <6030@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>in article <839@amc.UUCP>, jhall@amc.UUCP (John Hall) says: >> >>> 2. Will there be a faster A2620 style card available? >>> 14Mhz seems rediculous. We are currently working on a >>> 33Mhz 68020 emulator, probably extendable to 60Mhz! >>The CPU speed is the least of the issues, really. Priced 60ns DRAM lately? >>It doesn't make sense to build a faster unit until you can give it something >>to talk to. If enough folks are willing to pay 2x-3x what the A2620 costs >>now, maybe we can talk.... > 60ns RAM is not really necessary. 60ns is just about right for a full speed 68020. A 25MHz 68020 runs a 120ns cycle. Take 60ns for RAS access, 40ns for RAS precharge, and you have 20ns left over for decoding and refresh arbitration. Note that a 25MHz 68030 runs an 80ns cycle. But anyway, let's assume we've got a 25MHz A2620, which will have an extra wait state for the MMU. That's now a 160ns cycle. With 80ns DRAMs, you get 80ns for RAS access, 60ns for RAS precharge. Again, that leaves just 20ns for decoding and refresh arbitration, which is currently about 1/2 the time it actually takes on the A2620. Assuming I could knock 10ns off the select/arbitration time, I'd still need 70ns DRAMs for a zero wait state system (excluding the MMU wait state, of course). You could get similar performance, most of the time, with 80ns or 100ns going to a RAM bank interleave (lets you hide the precharge time), but that doubles the minimum number of devices you need for a complete system, and adds quite a bit more RAM support logic. No problem to do, and there are even better "clever" memory designs than this, but don't expect the whole thing to fit on an A2620 board without going to much higher integration than PALs to build the thing. > There are 20MHz 386 boards that run nearly full speed with 120ns DRAM's. > This may not be a fair comparison since I don't know how many cycles/memory > reference a 386 does, but... The 386 boards have two advantages. First of all, they almost all use either a bank interleave or a page mode/static column memory design. Using static column memory, for example, I could build a 25MHz '030 system that runs most of the time without wait states using 80ns or possibly even 100ns DRAM. The complexity of the design goes way up, though. And that takes room. The second thing the '386 benefits from, memory speed wise, is a special trick it does to ease memory timing. Rather than working on caches, the Intel folks decided that a deep pipeline was the speedup they wanted on the '386 (Moto went the other way, obviously, but no matter -- they converge next generation). So once the pipeline is full, the '386 drops into a mode that lets it run a slower cycle while still keeping the pipeline full. This is undoubtedly why '386s take about 80%-90% of the bus bandwidth -- they reorder their memory accesses via the pipeline, resulting in fewer cycles with no memory access, and a slightly relaxed timing on each access. > Suppose you could get a 90% hit rate with a fast 128K SRAM cache, then: I have no problem with external caches. The A2620 would have been really nice with a 64K or 128K logical bus cache. Any fool can tell you that. Where would I put it? Add the cache, and you loose all 32 bit memory. Plain and simple. Also given that the current operating system doesn't properly support data caches, and would likely run into trouble with large instruction caches, the choice of a decent amount of 32 bit memory over a large external cache was the only choice. > This also would cut bus traffic by a factor of about 10 (minus protocol/shared > memory overhead), so if you want to run multiprocessors, this is the > only way to go. No kidding. Common knowledge. Though without bus snooping, you loose a great deal of the benefit of caching in a multiple CPU system. > Of course, you have the added development effort of designing a cache > controller and the extra cost of those chips, but cache controllers > are well understood these days, and general purpose controllers are starting > to appear on the market. Adding a cache would have been no more trouble than adding the 32 bit memory. Considering all the support chips available today, it would have likely been simpler. Possibly more expensive, but likely simpler. > Steve -- "The cache guy" -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession