Path: utzoo!censor!geac!jtsv16!uunet!zephyr.ens.tek.com!tektronix!sequent!mntgfx!mbutts
From: mbutts@mentor.com (Mike Butts)
Newsgroups: comp.arch
Subject: Re: fast DRAMs and caches
Message-ID: <1989Aug30.185926.1410@mentor.com>
Date: 30 Aug 89 18:59:26 GMT
Organization: engr
Lines: 23

From article <27013@amdcad.AMD.COM>, by phil@diablo.amd.com (Phil Ngai):
> In article <1989Aug25.225511.828@mentor.com> mbutts@mentor.com (Mike Butts) writes:
> |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. 
> 
> We started this discussion by talking about fast DRAMs which
> approached the speed of rather fast SRAMs. So if this same high speed
> DRAM technology were applied to VRAMs, then your "full RAM cycle
> branch" would be comparable to a cache also. 

Only assuming the time to access the VRAM via the serial port and shift out the
first result is comparable to an SRAM access time.

I haven't received any data on the original question: How do the cycle times
compare to the access times on these new fast RAMs?
-- 
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.