🚀 go-pugleaf

In article <418@bnr-fos.UUCP> schow@bnr-public.UUCP (Stanley Chow) writes:
>Outside of a chip, I would have seriouse doubts about a very wide bus
>unless you have lot's of money. A 128 bit bus with 32 bit address comes
>to 160 pins before control line, add in power and ground, double it for
>I & D, and we are looking at a packaging problem. Come to think of it,
>ground bounce will probably make the packaging look easy.
...
>Actually, this question on bandwidth is my followup on the recent 
>discussion. I am fustrated by bandwidth and latency at very turn; yet
>all the people on the net seem to think bandwidth and/or latency is not
>a problem. Is this because everyone know something I don't? Do I have
>a particularly difficult problem?

	Well, my opinions on this are pretty well known here, I think.

	To restate: I agree bandwidth could well become a problem.  Bandwidth
problems come in several flavors: packaging is a big one, ram speed gets in
there also (especially if you don't want to pay astronomical prices for
it).  I won't even go into bus bandwidth.

	The traditional ways to improve bandwidth are running out of steam,
or at least starting to.  It's getting harder to keep adding pins to these
(very large) packages, while still running them at reasonable rates.  Also,
the signals are getting fast enough that capacitive pad loads from static
protection (combined with fan-out) are limiting the speed at which you can
run the lines.

	However, there are interesting non-traditional solutions to these
peoblems that may save our bacon.

	Ram speed is also an issue: you can get 50Mhz '030's, but the ram
to keep up with it is EXPENSIVE.  Processor speed has been increasing
faster than ram access time has been decreasing (for both CISC and RISC).

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup