🚀 go-pugleaf

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