Physical Behavior of an Address Bus

[cjs]

Several CPUs...have separate I/O busses ( which generally is an address and / or data bus designed to talk to peripheral chips rather than memory. )

Which ones would these be?

The popular example of something like this is the 8080 and successors, which have separate "memory" and "I/O" address spaces, but this is really just a programmer-facing thing because of the separate instructions used to access these; it makes perfect sense to think of the CPU as having a 17th address line that, rather that coming directly out, just goes through a couple of gates to produce the /MEM and /IO "enable" signals.

(In particular, there's nothing stopping you from putting memory in the "I/O space," and it's common on Z80 systems to put I/O into the "memory space.")

 

[Eudimorphodon]

Which ones would these be?

FWIW, there are some "CPUs" which tread the line between mere CPUs and SOCs by including features like integrated DRAM controllers, and thus with these devices you could argue the machine has "two separate busses" because it'll have both a "normal" bus that you'd decode to place external peripherals on and a separate set of address and data lines dedicated to driving RAM. This describes most modern Intel CPUs, although in this case we're also dealing with the fact that the "external bus" isn't an old fashioned parallel bus, it's PCIe lanes. But an older school example I can think of is the M6117D SOC that's in those "Pocket 386s" people are buying off AliExpress and the like. That chip has a "normal" bus that has all the pins of a 16 bit ISA slot, and it *also* has a completely separate set of (multiplexed) DRAM address lines, RAS/CAS signals, and "local bus speed" data lines for driving the main memory bank. (And of course it also has a programmable memory mapping unit inside that dictates whether a given address is going to be routed to the expansion bus or the DRAM controller.)

Strictly speaking, though, from a logical standpoint the CPU *itself* inside the package has a unified data/address bus. It's just decoded into these separate lanes before it exits the package. You could also say a similar thing happens with microcontrollers that have integrated ROM and RAM but *also* have the option to choose between using the package pins as either GPIO or to implement an external expansion bus; there will be a set of multiplexers in there that switch between the pins terminating on a set of I/O registers vs. the hidden internal bus.

 

[jlang]

Which ones would these be?

The popular example of something like this is the 8080 and successors, which have separate "memory" and "I/O" address spaces, but this is really just a programmer-facing thing because of the separate instructions used to access these; it makes perfect sense to think of the CPU as having a 17th address line that, rather that coming directly out, just goes through a couple of gates to produce the /MEM and /IO "enable" signals.

(In particular, there's nothing stopping you from putting memory in the "I/O space," and it's common on Z80 systems to put I/O into the "memory space.")

I would think the IBM 360 channel (bus and tag) would qualify as separate I/O address and data lines.
I expect there were more but I have CRS.

 

[Svenska]

Which ones would these be?

Depends on where you want to draw the line. If you want to see a 17-bit bus on the Z80, you will see a 17-bit bus. If you want to see two 16-bit busses multiplexed on the same pins, you will see two 16-bit multiplexed busses. It's a matter of perspective.

Do the software-controllable pins on 8085 or 6510 chips suffice? They use separate pins and different instructions.

AVR microcontrollers strongly expose the existance of independent instruction and data busses with their respective address spaces to the programmer; even externally connected RAM is not executable on those. I think the 8051 line of chips works similarly.

The TMS320C55x line datasheet lists twelve busses (three 16-bit data-read data busses, three 24-bit data-read address busses, one 32-bit program-read data bus, one 24-bit program-read address bus, two 16-bit data-write data busses and two 24-bit data-write address busses). I don't think these are exposed on the chip package level, though. But it's a strong hint that they use more than one, at least.

 

[jlang]

The AVR is Harvard architecture. Program address space is separate from RAM and IO space.
The prime advantage is the CPU can overlap instruction fetch with instruction execution.

 

[segaloco]

Does the PDP-11/45 et. al. separate I+D space count? Admittedly I don't know how that works other than it is a thing, whether it's just segmentation to other parts of memory map, a separate buses situation, etc. One of these days I need to get down and dirty with PDP-11 memory protection, I've only learned enough to stumble through old UNIX sources.

 

[cjs]

Depends on where you want to draw the line. If you want to see a 17-bit bus on the Z80, you will see a 17-bit bus. If you want to see two 16-bit busses multiplexed on the same pins, you will see two 16-bit multiplexed busses.

Oh, wait! I see 257 multiplexed 8-bit address buses! (Though I have never been kissed by any of them.)

Does the PDP-11/45 et. al. separate I+D space count? Admittedly I don't know how that works other than it is a thing, whether it's just segmentation to other parts of memory map, a separate buses situation, etc. One of these days I need to get down and dirty with PDP-11 memory protection, I've only learned enough to stumble through old UNIX sources.

Not as separate buses, no.

The PDP-11 has one large address space, larger in fact than the machine word size. It's a 16-bit machine, but the Unibus etc. supports anywhere from 18- to 22-bit (IIRC) addresses. The decoding hardware takes care of mapping the 16-bit CPU addresses to the larger "physical" address space. You already know the principles of how this is done; it's no different from bank switching in a microcomputer.

The "split I+D" is a mechanism in the CPU to give an external indication of whether it's accessing "program" or "data" content. For example, when it's fetching an instruction, it will indicate "I", and when that instruction loads data from memory, it will indicate "D." (It's actually rather more sophisticated than that, but that's the gist of it.) The external address decoding hardware can then chose to direct those two accesses to different "banks" of memory.