Article View: comp.arch
Article #2070Re: fast DRAMs and caches
From: Mike Butts
Date: Wed, 30 Aug 1989 18:59
Date: Wed, 30 Aug 1989 18:59
23 lines
1623 bytes
1623 bytes
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.
Technical Details
Message-ID:
<1989Aug30.185926.1410@mentor.com>Path:
arc1-ca.pugleaf.net!utzoo!censor!geac!jtsv16!uunet!zephyr.ens.tek.com!tektronix!sequent!mntgfx!mbuttsShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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