david@daisy.UUCP (David Schachter) (03/04/88)
In the discussion "16 & 32 bit vs 32 bit only instructions for RISC", the following recently appeared: >>Dedicating 64 pins purely to instruction fetch (assuming a Harvard >>architecture) is quite a lot of a rather scarce resource. Sure >>you wanna do this on a micro ? > >Sounds like it might be a good idea. Note that instruction-only-bus pins >are INPUT-only; thus their corresponding pads are much "faster" and simpler >than bidirectional bus pads. Which leads to the question: if pin limitations were not a factor, would it be a Good Idea to split the data bus into two busses: IN and OUT? -- David Schachter (daisy!david or well!davids) The above opinions don't exist. "But only after disconnecting the green wire."
oconnor@sungoddess.steinmetz (Dennis M. O'Connor) (03/08/88)
An article by david@daisy.UUCP (David Schachter) says:
] In the discussion "16 & 32 bit vs 32 bit only instructions for RISC", the
] following recently appeared:
]
] Which leads to the question: if pin limitations were not a factor, would
] it be a Good Idea to split the data bus into two busses: IN and OUT?
]
] -- David Schachter
] (daisy!david or well!davids)
It would be a Great Idea if pin limitations weren't a factor,
as would be n-word-wide fetches of everything, separate
address busses for instructions and operands, lots things.
But pin limitations will be a factor for a while. Until techniques
to bond to the middle of the chip exist, the number of pads on a chip
will place a lower bound on its size, and therefor an upper bound on
its yield, and a lower bound on its cost.
But, if I had a fast package for it, I'd use two data busses.
In fact, I'd use 2 32-bit address busses ( I & D ), 1 32-bit
instruction bus and 2 32-bit operand busses. That's 160 pins
so far, now add control/status signals, clocks and pwr/grnd.
Lets see, a 240 pin LCCC, with 25mil pin pitch ... that's
only 1.5 inches on a side, but 25mil pin pitch is a bear.
With an 8-mil pad pitch, the chip will be 500mils square : big.
Why separate In and Out : First, loads and stores in a pipelined
memory architecture naturally transfer data to/from the cpu in
different pipestages, so sharing a bus introduces a hazard you
either have to avoid or stall on. Second, trying to make sure that the
memory system's bus drivers are OFF after a load, before the CPU
starts driving out data for a store ( called "turning around the bus"
around here, i.e. reversing the flow of data on it ) in the gap
between cycles on a 40MHz bus (2-3ns) is TOUGH !!
--
Dennis O'Connor oconnor%sungod@steinmetz.UUCP
ARPA: OCONNORDM@ge-crd.arpa
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)bcase@Apple.COM (Brian Case) (03/09/88)
An article by david@daisy.UUCP (David Schachter) says: > Which leads to the question: if pin limitations were not a factor, would > it be a Good Idea to split the data bus into two busses: IN and OUT? Note that splitting I/O at the processor chip boundaryis only going to be a win if the memory has separate I/O; otherwise, you'll still have to turn a bus around somewhere. Note that some of the fastest SRAMs from people like Cypress and Performance have separate I/O.