Why should 2 CPUs ever share the same bus?

Question

The complexity of the Sega Saturn's technically impressive hardware played a large factor in its downfall. It seems to me that one of the largest things that was difficult to work with was that the 2 Hitachi SH-2 processors shared the same bus and were unable to to access system memory at the same time. Nowadays multiple processors can access system memory and cache at the same time with multi threading. Why was the Sega Saturn's main processor architecture designed in this way?

Answer 1

It seems to me that one of the largest things that was difficult to work with was that the 2 Hitachi SH-2 processors shared the same bus and were unable to to access system memory at the same time. Nowadays multiple processors can access system memory and cache at the same time with multi threading.

Todays multi-core CPUs suffer the same problem as all future systems will. One bus interface can do only one transfer at a time. It's just that caches with speculative reads and burst transmissions cover up for most collisions. The same was true already for the SH2 CPUs, as each operated a local 4K cache.

Why was the Sega Saturn's main processor architecture designed in this way?

The same reason why all multi-core CPUs today are designed that way: to improve performance. On the Saturn it was especially to allow as flexible as possible interactions of parallel units to deliver superior performance as a whole system.

Looking close, there are way more components accessing the busses than just the CPU cores. To start with, the Saturn had three busses: A, B and C, all coordinated by the SCU (system controller).

The A Bus connected the SCU with all expansion. For a basic console this means the expansion slot and the CD-ROM board. Access is arbitrated by the SCU between SCU access, access from the SH1 CPU on the CD-ROM board and whatever was plugged into the cartridge slot - yes, cartridges could have CPUs (or alike) accessing the whole system.

The B-Bus connected the SCU with both VDP and the sound system (with its own 68K CPU).

And and finally the C-BUS connected the pair of SH-2 CPUs with the SCU and the System Management Controller, a 4(!) bit CPU handling system reset and backup RAM.

Next, the SCU wasn't just some bus switch, but got its own program running on a DSP, plus three independent working DMA engines.

To add complexity, each SH-2 SPU also included two independent DMA channels, so there were up to 10 different entities accessing the C-Bus - 11 if you count the SMC.

Within this complex system of independent programmable components, adding a second CPU core was an easy and cheap way to add more computing power. All components where like players in an orchestra and needed a good training, AKA programming. Due the sheer power (at that time) one could get nice results from the main CPUs with default drivers for SCU and VDP1/2, but nothing exceptional. It has been said that real great Saturn games only came from Japan and Europe (mostly Britain), as they got down to work the SCU in assembly language, while US companies preferred to use C.

Edit: For more detailed information, a look at the Sega-Retro-Wiki might be a good start. These guys collect everything about Sega in general, including a huge amount of real detailed information about the gaming consoles.

The Saturn Service Manual has a nice system overview on page 12.

Answer 2

If two devices will need to share information, there will need to be some kind of shared bus via which they can do so. The easiest way to accomplish that is to have two devices sit on the same bus and take turns using it. While it's possible to use more complicated arrangements, they are only practical if one is willing to either use a lot of discrete chips, or put a lot of stuff into a single chip. Nowadays it's not uncommon for chips to have many hundreds of pins, but historically even a chip with 64 pins was considered "large". If one wants to have two processors share 65,536 words of memory on a 16-bit data bus and also have each be able to its own private 16-bit memory subsystem, that will require switching 16 address bits, 16 data bits, and some control wires. Since each of those wires will need to be present in each private bus as well as the shared bus, that's over 100 signals that need to be managed by the bus-switching logic. Nowadays it would be practical to have a single hundreds-of-pins chip to manage such things, but if one confines oneself to chips with no more than 40 pins each and divides things up to minimize duplication, one would end up needing quite a few such chips. If all the shared memory were DRAM, one might be able to have two 40-pin chips each take care of 8 data bits and 4 address bits (multiplexing them to 2) and then have another 40-pin chip take care of the remaining address bits along with some other functions, but that's a lot of extra circuitry for what's presumably supposed to be an inexpensive system.

Answer 3

There was some speculation (by competitors?) that the second SH processor was added by request of the marketing department, and not because engineering found it to be useful in typical game code. It's addition might have been justified by the use of synthetic (and unrealistic?) benchmark numbers for marketing the system.

Current MT/MP systems have similar issues, but use wider bus widths, higher transfer speeds and multiple levels of much larger caches and buffers to better hide the issues in some current typical application methodologies.