Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!panda!genrad!decvax!mcnc!duke!srt
From: srt@duke.UUCP (Stephen R. Tate)
Newsgroups: net.arch
Subject: Re: VERY LARGE main memories
Message-ID: <8513@duke.duke.UUCP>
Date: Thu, 4-Sep-86 15:59:07 EDT
Article-I.D.: duke.8513
Posted: Thu Sep  4 15:59:07 1986
Date-Received: Fri, 5-Sep-86 21:15:49 EDT
References: <2017@sdcsvax.UUCP> <884@gilbbs.UUCP> <289@petrus.UUCP>
Organization: Duke University CS Dept.; Durham, NC
Lines: 23
Summary: Decoding trees?  Growing as the log of memory size????

In article <289@petrus.UUCP>, hammond@petrus.UUCP (Rich A. Hammond) writes:
> > 
> tom keller writes:
> > The primary
> > impediment seems to be the delays caused by propagation delays in the
> > decoding trees.   Anyone care to enlight me (us)?
> 
> Well, the Cray 2 supports 256M Word (where word = 64 bits) i.e. 2 Gb,
> so it is not impossible.  The decoding trees grow as the log of the
> size of memory, so it isn't bad.

That's an over-complicated (or over-generalized) treatment of address
decoding.  The key phrase you use is "decoding trees", where decoding
does not have to be done by trees at all.  *Regardless* off the memory
size, decoding the unique address of a bank of memory (bank, row, or
word, actually) need never be more than 2 gates deep.  Meaning propogation
delays of only around 30ns using regular old slow silicon TTL.
And this is completely independent of memory size.  (within reason...
propogation delays for 40 input AND gates might be a bit higher....  But
who's going to have 40 bit bank addresses?)

-- 
Steve Tate			..!{ihnp4,decvax}!duke!srt