Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses & multiprocessor cache request
Message-ID: <2134@crdos1.crd.ge.COM>
Date: 23 Feb 90 14:06:22 GMT
References: <7971@pt.cs.cmu.edu> <1400@uvm-gen.UUCP>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 29

In article <1400@uvm-gen.UUCP> pegram@uvm-gen.UUCP (pegram r) writes:

| I can possibly see the small system of the future operating that way, but
| for really small systems, make the MMU optional, and slow the chip
| slightly by multiplexing the data and address lines.  That requires no
| more lines than are used currently and lets the external latches
| handle the drive problems.

  I really doubt that future systems will operate without an MMU,
because the low end chips will have one on chip and the fastest RISC
will run an O/S which needs one. I don't think multiplexing lines is 
going to be common because of market demand for power.

  Has anyone looked into an inline CPU package? Consider an extended
SIPP concept, with the package being as long as needed, or even being
several chips on a substrate. At 10 stations per inch, two sides, two
levels, this gives 40 connections/inch. Obviously this could be pushed
to at least double this, but by having a great long chip the congestion
of traces at the CPU would be less, address and data could be fed
separated, and power and gnd lines could be run between signal traces to
lower crosstalk.

  The thought of a 3-4 inch long CPU is unconventional, but doesn't use
more area than a square, and by clever parts placement could keep lead
length *between actual gates* low by allowing more support chips to be
close to the CPU.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
            "Stupidity, like virtue, is its own reward" -me