Subject: Re: Cyberstorm (and Amiga cache)
To: Jeffrey William Davis <email@example.com>
From: Jukka Marin <firstname.lastname@example.org>
Date: 03/30/1996 17:28:52
> You seem to be a 'worst-case' kind of guy. :-)
You kind of have to take the worst case into account when you design
hardware that is expected to work all the time for years to come.
> First of all, you are
> starting your example with 80 and 70ns speeds.
Simply because I haven't got a DRAM databook with 60 ns chip data in it.
Sorry for this.
> Second, you are not taking
> advantage of the 'extra' time surrounding the actual memory cycle! Going
> from the "what's the worst possible memory design" aspect, things aren't
> going to add up.
Yes, the access time does overlap with some of the CPU delays, but if the
DRAM cycle time is, say, 100 ns (for your 60 ns chips), how are you going
to be able to access the chips once every 50 ns (or even 25 ns for burst
cycles)? If you can do that, you must know something completely unknown
to the whole computer industry. ;) They're building 128-bit-wide (and wider)
data busses out there to keep up with the CPU speed.
> Have you ever designed a DRAM controller/interface???
No, never, but I know that you have to design by the worst-case data to
get some reliable hardware. Sure, your numbers look much better if your
68040 is one bus clock slower than mine, but..
> Sometime when I have more time, I will put together some ASCII timing
> diagrams of how all the pieces fit together. There are many areas where
> you take advantage of timing overlaps with the bus address phase, allowing
> DRAM cycles to 'complete' after the CPU bus cycle, and /CAS timing issues.
Please explain how you can make a 100 ns DRAM cycle complete in less than
50 ns (or 25 ns)?
> How and when data/address information is latched by the RAM board, and a
> few dozen other issues (like memory layout for /RAS).
You may be able to use some tricks for _one_ bus cycle, but the CPU is
capable of addressing the memory every 25 ns (during burst cycles, which
_do_ run faster on the DRAMs, yes).
> There is a good reason why they chose "access time from /RAS" to represent
> the DRAM speed. I have learned that for simplicity, the ns rating of the
> DRAM is quite representative of the performance you achieve, not the
> 'fastest performance' limit.
Still, 60 ns > 25 ns.
Well, this is all quite irrelevant now that the 68040 chip isn't considered
that fast any more. With or without an external L2 cache, it's pretty slow
when compared to some unnamed CPU's out there. :-(
Don't take me wrong, I'm looking forward to the day when I can put the first
68k family CPU in the projects I work on. I love this CPU family. It's just
that if I want the fastest machine, it isn't run by a 68k CPU any more. :-I