Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!amdahl!fai!ronc From: ronc@fai.UUCP (Ronald O. Christian) Newsgroups: net.arch Subject: Re: VERY LARGE main memories Message-ID: <334@fai.UUCP> Date: Wed, 3-Sep-86 14:29:32 EDT Article-I.D.: fai.334 Posted: Wed Sep 3 14:29:32 1986 Date-Received: Thu, 4-Sep-86 22:18:40 EDT References: <2017@sdcsvax.UUCP> <884@gilbbs.UUCP> <145@mn-at1.UUCP> Reply-To: ronc@fai.UUCP (Ronald O. Christian) Organization: Fujitsu America, Inc. Lines: 34 Keywords: memory size In article <145@mn-at1.UUCP> alan@mn-at1.UUCP (Alan Klietz) writes: >In article <884@gilbbs.UUCP>, mc68020@gilbbs.UUCP (Thomas J Keller) writes: >> >> [...] The primary >> impediment seems to be the delays caused by propagation delays in the >> decoding trees. Anyone care to enlight me (us)? >> > >If you use DRAMs you have access times on the order of 50-200ns. That is >enough time for fast ECL-type logic to do plenty of decoding. I wonder about this. I had a design problem awhile back involving 45ns ram used as a lookup table, where I couldn't decode the address fast enough. I found some ECL gates that would do the decoding faster, but then found to my chagrin that you lost so much time in the conversion from ECL back to TTL that the overall response ended up being slower. I've had the same problem in gate arrays, where the propagation delay through the on-chip conversion to ECL, the array itself, and the conversion back to TTL was greater than the prop delay through a straight TTL array of similar complexity. If you're going ECL for decoding, I think you really need to have ECL memories to gain anything. Then there's GaAs... So fast you can spend a lot of time converting to a different logic family. I like GaAs. Expensive, though. Ron -- -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) seismo!amdahl!fai!ronc -or- ihnp4!pesnta!fai!ronc Oliver's law of assumed responsibility: "If you are seen fixing it, you will be blamed for breaking it."