Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tektronix!sequent!mntgfx!mbutts
From: mbutts@mentor.com (Mike Butts)
Newsgroups: comp.arch
Subject: Re: Fast DRAMs and caches (was Re: cache speed)
Message-ID: <1989Aug25.225511.828@mentor.com>
Date: 25 Aug 89 22:55:11 GMT
References: <26964@amdcad.AMD.COM>
Organization: engr
Lines: 24

From article <26964@amdcad.AMD.COM>, by tim@cayman.amd.com (Tim Olson):
> In article <1989Aug24.215104.156@mentor.com> mbutts@mentor.com (Mike Butts) writes:
> | Another point about caches is that many fast RISC systems, such as Apollo's
> | DN10000 and the forthcoming Fujitsu SPARC-H, use separate instruction and data
> | caches to accomplish two memory operations in one cycle (so-called "Harvard
> | architecture").  You can't do that without caches unless you want to keep two
> | copies of main memory.
> 
> Check out VRAMs (Video-DRAMs).  They have two ports to the same memory
> -- a standard, random-access port, and a serial port that can be used
> to read sequential data concurrently with random accesses on the other
> port.

I take it you are proposing using the VRAM serial port for instruction fetches.
That would work out fine for linear code sequences, but would cost you a full
RAM cycle to do a branch.  Delayed branch architectures could mitigate that
cost somewhat, but it would still cost you.  It's cheaper than a cache, but not
as fast as a good one.  Has anyone tried using VRAMs like that in a real
system?
-- 
Michael Butts, Research Engineer       KC7IT           503-626-1302
Mentor Graphics Corp., 8500 SW Creekside Place, Beaverton, OR 97005
...!{sequent,tessi,apollo}!mntgfx!mbutts  OR  mbutts@pdx.MENTOR.COM
Opinions are my own, not necessarily those of Mentor Graphics Corp.