🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.arch
Article #2754

Re: VERY LARGE main memories

#2754
From: Philip Freidin
Date: Sat, 06 Sep 1986 16:16
30 lines
2299 bytes
In article <8513@duke.duke.UUCP>, srt@duke.UUCP (Stephen R. Tate) writes:
> 
> 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

Unfortunately, at this point I would like to apply some reality to the
discussion. Rather than talk about your 40 bit address memories, lets
look at something trivial: 64kw. this needs 16 bits of address. With
your 2 level decode (one of inverters, and the second of and gates to
do word select) you have 32 address select lines coming into the second
level, address and address complement. each of these must drive 32k and
gates!  I dont know of any logic familly with a drive capability to support
that type of load. Your typical ttl has a drive capability of from 10 to 20
loads.  Also, another fly in your fast decode ointment is that the way and
gates are implemented in many logic families precludes building a 16 input
and gate as a single level. Cmos is limited to about 4 levels, and TTL and
ECL have similar limits. To build bigger and gates, you end up with a tree
structure inside your and gate.

--Philip Freidin
Technical Details
Message-ID: <12930@amdcad.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!ll-xn!cit-vax!amdahl!amdcad!philip
References: <2017@sdcsvax.UUCP> <884@gilbbs.UUCP> <289@petrus.UUCP> <8513@duke.duke.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!ll-xn!cit-vax!amdahl!amdcad!philip
From: philip@amdcad.UUCP (Philip Freidin)
Newsgroups: net.arch
Subject: Re: VERY LARGE main memories
Message-ID: <12930@amdcad.UUCP>
Date: Sat, 6-Sep-86 12:16:50 EDT
Article-I.D.: amdcad.12930
Posted: Sat Sep  6 12:16:50 1986
Date-Received: Sat, 6-Sep-86 20:36:45 EDT
References: <2017@sdcsvax.UUCP> <884@gilbbs.UUCP> <289@petrus.UUCP> <8513@duke.duke.UUCP>
Organization: AMDCAD, Sunnyvale, CA
Lines: 30
Summary: You cant throw away decoding trees because....