It has become clear from recent simulations that unless the amount of cached data per processor is increased substantially, we will not be able to support more than three or four processors on a single M-Bus. One way to get more data is to put however many cache chips are required per processor. This is unacceptable because it requires too much board area per processor and also increases the number of M-Bus loads to the point where bus timing requirements are difficult to meet. A more workable solution is two-level caches: the first level cache would be a custom chip with about the same amount of data as an old cache. The second level cache would consist of a custom chip and several off-the-shelf memory chips; it would be slower than the first level cache but contain much more data.

There is quite a variety of two-level schemes possible but most of them are either too hard to implement, involve throwing away too much work already completed, or do not provide reasonable intermediate implementations. The one we've settled on seems to have none of these disadvantages while providing all of the performance advantages we're after.

The two-level cache consists of three components: the first-level cache VC (for virtual cache), the second level cache RC (for real cache), and 8-16K words of memory Mem; VC and RC are both custom chips, while Mem consists of four or eight 8Kx8 off-the-shelf memory chips.

It turns

The VC's connected to a processor sit on an internal bus called the MI-Bus (for MBus, Internal) whose protocol is a strict superset of the M-Bus. VC is virtually identical to the old cache: its front-end connects to the processor and traffics in reads and writes to virtual addresses; its back-end connects to the MI-Bus and traffics in real addresses using the usual M-Bus transactions. VC's are designed so it is also possible to plug them directly to the M-Bus and have them work (indeed this is essential since it allows Dragons to be brought up without putting RC in the critical path).

The front-end of RC is connected to the MI-Bus, and its back end to the main M-Bus. Mem connects directly to RC from the side. We will have to revisit this decision if pin count becomes a problem for RC; Mem may then have to be moved to the MI-Bus. There is only one RC per MI-Bus and the arbiter for the MI-Bus sits inside RC. The arbiter for the M-Bus stays the same.

We need to get the following two statistics:

(a) How often do processor writes result in VC misses? This is needed to verify that the three cycles of latency added when a write misses in VC are not a performance problem.

(b) How often does a processor write into a clean quad in VC? This is needed to verify that the spurious WS generated by VC in communicating to RC that a quad has been written into is not a performance problem.

How is the processor number initialized during reset so that minimal systems can be booted without the baseboard?

Should there be programmable page size? Over what range? Could implement it by running enable and enable' lines down through the low order bits of page so that the cells can drive the page or block match line low.

Why not a standard component implementation?

when the m controller sees its own command it must return bus fault to the processor and release the bus.

how can we have two virtual addresses for a single real address at the same time in one cache?

This section describes the reasoning behind the cache pin assignment shown in Figure 2. The initial assumption is that the control logic is all at the top of the array and that the data buses run across the top of the chip and then narrow down the two sides, the M bus on the right and the P bus on the left, meeting in the middle of the bottom of the chip. The initial pin count constraints are as follows:

This requires a total of 123 pins out of the 144 available. The power pins are the obvious place to use some of the remaining 21 pins. One would like to minimize the internal wiring length from the closest power pads to any point on the chip. The added power pins should also be chosen from those with the lowest inductance in the package. The initial power pin count was chosen simply to use up all the low inductance pins in the package. They were then arbitrarily divided up as follows:

The pad power pins were assigned to the lowest inductance pins. The logic power pins were assigned to the next lowest inductance pins. The arrays in the logic are likely to use quite a bit of current during their precharge and discharge cycles. Lets add 2 pins to each of the logic supplies leaving 17 pins. The M bus has about between 5 and 20 times as much capacitance as the P bus but it runs at half the rate so it should get between 2 and 10 times more pins. Arbitrarily chosing 2 as the multiplier and 8 pins for the M bus means 4 additional pins for the P bus leaving 5 pins uncommited. They will be left uncommited so that if any extra functionality is required in the controller there are spare pins to implement them, e.g. a mechanism for determining when a cache flush or launder process is finished may require a pin or so. The M bus has about 39 pins that all swing at the same time so 39/8 means about every 10 pins there should be a PadVdd/PadGnd pair. They should also be constrained to be on the inner row of pins in the package. For the M bus this means pins 60, 66, 69, 77, 81, 85, 96 and 102 are the obvious choices. The P bus has 37 pins so every 9 pins should have a power or ground. The possible pins in the range of 20 through 53 are 24, 30, 41, 45, and 49. Eliminating 49 leaves 4 pins.