These four lines encode the M bus command. The M bus command specifies the action in progress during the current bus cycle; it may be asserted either by the master or by a slave. The commands currently defined are discussed later in Section 3.2.

The interpretation of these 32 lines depends on MCmdAB[0..4). For most commands the MDataAB lines simply represent the 32-bit address or data corresponding to a read or write; for other commands the interpretation is more complicated. The detailed interpretation appears in Section 3.2. As with MCmdAB, these lines also may be asserted either by master or slave.

This line carries the parity bit for MDataAB[0..32). The parity computed is odd and is valid only during data transport cycles.

This line is used by the caches to maintain consistency for multiple copies of read/write data. When a cache puts out a read or write request on the bus, other caches match the address on the bus with addresses for which they have values stored. Whenever a cache finds a match it pulls nMShared low, signaling that the datum is shared. Note that this signal is asserted when low.

This line is used to prevent memory from responding to a ReadQuad and have a cache respond instead. Logically speaking nMAbort is not necessary, since nMShared can also be used to get the memory to abort. However, this would require the implementation to keep an additional state bit for each cache entry, which is expensive. It would also require more bandwidth from the RAM in the cache. Note that this signal also is asserted when low.

This line is used to signal a bus error. The only bus error currently defined is bus parity error. Note that this signal is asserted when low. Normally, a pullup resistor ensures it is not asserted.

These lines are used by the caches to request bus mastership. There is a dedicated line for each cache, so the lines are not bussed. Instead, they run radially, converging at the bus arbiter.

These lines are used by the arbiter to signal which of the caches gets the bus next. Like the request lines, these lines are also dedicated and therefore not bussed. There is a possibility that they will be replaced by 4 encoded grant lines that supply the number of the cache to which the bus has been granted. Alternatively, these encoded lines may be run in addition to the decoded lines. The encoded lines are needed by the Map processor to figure out which processor is currently bus master.

This line is logically unnecessary, but is needed to improve bus throughput. Loosely stated, it means that the current master is willing to relinquish the bus if there are other contenders at this time. Otherwise the current master will keep the bus. This allows a master to do multiple transactions without hogging the bus, and without wasting cycles to release and reacquire the bus in case there are no contenders.

The signals involved in arbitration are the MRq-MGnt pairs running to and from each potential master and the arbiter, and a single line MNewRq used to enhance bus throughput. A device requests the bus by asserting its request line. If one or more MRq lines are asserted, and the bus is free, the arbiter performs a grant cycle in which it issues the bus by asserting the MGnt line for the highest priority device that has MRq asserted. Priority is round-robin, with the device last granted the bus receiving lowest priority.

The bus recipient keeps MRq asserted for as long as it wants the bus, and the arbiter in turn keeps MGnt asserted. If the master is executing a long sequence of cycles that is not required to be atomic with respect to other devices, it asserts MNewRq to indicate its willingness to give up the bus if there are other requests pending (for correct operation, MNewRq must be asserted only by the current master). MNewRq causes the arbiter to do a grant cycle even though the master still has MRq asserted. Since the master became the lowest priority device upon receiving the bus, it will lose the bus if any requests are pending. This strategy prevents a master from hogging the bus. At the same time, it avoids wasting cycles in the case that no devices are waiting to get the bus. A solution in which the master releases and reacquires the bus, for example, does waste cycles in this case.

There are a maximum of sixteen M bus commands. Twelve of these are currently defined, and the rest are reserved for future use. In the description below, the decimal number in brackets after the command name indicates the encoding for the command.

There are currently eight M bus transactions: ReadQuad, WriteQuad, WriteSingle, Map, IORead, IOWrite, IOReadFlow, and IOWriteFlow. Five of these transactions are flow controlled: ReadQuad, WriteQuad, Map, IOReadFlow, and IOWriteFlow. Every master device which initiates such a transaction must check that the slave device has driven the command lines to another value during the second cycle of the transaction. If the command lines still contain the initiating command then the master must assume that no slave will ever respond to the command and abandon the transaction.

The IORead, IOWrite, IOReadFlow and IOWriteFlow transactions are used by caches as a general way of communicating with IO devices. The 32 bit address of such transactions defines a large, unmapped IO address space that is common to all processors. This space is carved up into disjoint, contiguous pieces, with at most one device responding to each piece. Each device is free to interpret I/O commands in any manner it chooses.

A Dragon processor not in kernel mode limits the addresses which may be issued for either memory or I/O addresses. Since the cache translates virtual addresses to real addresses this imposes no restrictions upon devices connected to the M bus in the real address space. The cache does not translate I/O addresses and so designers of devices which are connected to the M bus in I/O address space should decide if the device should be protected when the processor is in user mode. The high order eight bits of address are not allowed to be zero when the processor is in user mode.

The cache consistency problem is to prevent multiple copies of a datum in distinct caches from having different values. This problem arises because Dragon caches contain shared data that may be written into.

The solution involves the use of the nMShared and nMAbort bus lines and two additional bits shared and owner stored with each quad in a cache. For a given quad, if shared is false then no other cache contains the quad. However, if shared is true other caches may or may not contain the quad (there is uncertainty because when sharing stops this fact is not discovered immediately). Owner is true if and only if the last write into the quad was done by the processor attached to the cache.

A cache initiates a ReadQuad when it gets a miss for a quad; it issues a WriteQuad when a quad needs to get kicked out of the cache to make room for another quad (only quads with owner set need to be written out); and it issues a WriteSingle when its processor does a write to a quad that has shared set. When a cache issues a ReadQuad, WriteQuad, or WriteSingle all other caches on the bus match the quad address to determine if they have the quad. Any cache that matches asserts nMShared to signal that the quad is shared. During ReadQuads the master and all matching slaves copy the value of nMShared into the shared bit for that quad. Also, when a cache issues a WriteSingle the master copies the value of nMShared into the shared bit. This ensures that sharing is detected as soon as it starts and is eventually detected when it stops.

The owner bit is set each time a processor writes one of the words of the quad. If the quad is shared, the resulting WriteSingle will update all other copies of the quad and cause their owner bits to be cleared. Thus at any time at most one of the caches will have owner set. Owner may not be set at all, of course, if the quad has not been written into since it was read from memory.

During a ReadQuad two distinct cases are possible. Either a dirty quad (ie. one that hasn't been written out to memory yet) exists in other caches or it doesn't. In the first case the owner (and possibly other caches) assert nMShared. The owner also asserts nMAbort, preventing the memory from responding, and then proceeds to supply the quad to the master. The second case breaks down into two subcases. In the first subcase no other cache has the quad, nMShared does not get asserted, and the quad comes from memory. In the second subcase at least one other cache has the data, the nMShared line does get asserted, but the quad still comes from memory because no cache asserted nMAbort.

Some devices implement a portion of the real address space on a M bus. They may require that their local copy of data be made consistent with the data in caches, i.e. they want to clean dirty data out of caches or launder it, so that they may access that data without utilizing M bus bandwidth. They may also wish to force caches to fetch data from their local copy because they want to privately update it, again without utilizing M bus bandwidth. This can be implemented by requiring caches to forget what they know about the contents of memory locations, i.e. flushing those contents from the caches.

Locations 0 and 1 of the I/O address space are reserved to broadcast launder and flush parameters to the caches. Since this is a broadcast operation only IORead and IOWrite transactions may access these locations. Caches will not respond to IOReadFlow and IOWriteFlow transactions to these locations. Bits [0..23] of location 0 serve as a mask which is bitwise "anded" with the high order bits of each location in the cache and the result is compared to bits [0..23] of location 1. If there is a match then the entry is selected for the operation. The operation is specified by bit 31 of location 1, a zero indicating launder and a one indicating flush. Dirty data is written back to memory prior to flushing an entry. When location 1 is written the operation is started.

The map cache contains an IOWrite command reflector that takes address and data in argument registers and issues an IOWrite command. This mechanism exists so that no cache has to both issue and interpret an I/O command at the same time. The cycles look like:

Another way to do this would be to require the issuing cache to interpret the IOWrite or IOStore to location 1 itself and not involve the map processor at all.

Conceptually each cache maintains an operation in progress bit that indicates that an operation has been started but not yet finished. An IOWrite to location 1 sets this bit. The elimination, by writing back any dirty data and then resetting rpValid and vpValid, of all entries which match on address reset this bit if the operation is flush. Writing back the dirty data of all entries which match on address reset this bit if the operation is launder.

While the operation is being processed each cache arbitrates for the bus when it discovers an entry with dirty data and then rearbitrates for each successive entry found to be dirty. Requests from the P bus side demanding M bus service have higher priority than the operation requests. Both of these requirements prevent a hiccup from occuring in the system when there is a great deal of dirty data to be cleansed.

It is assumed that the amount of time required to service a launder or flush request is small compared to context switch time. Thus the processor which initiated the operation should be held by issuing PReject until the operation is complete. However the controller of the cache which issued the request must be free to process it which implies another bit of state, operation pending. While this is set the cache issues PReject; when it is reset the cache no longer issues PReject. This bit is set when the processor issues an IOStore to location 1. The processor should be very careful not to issue IOStoreHold to this location since if there is dirty data in any other cache the system will deadlock; perhaps the cache should check for this condition and treat such an IOStoreHold as if it were an IOStore.

How does the operation pending bit get reset? The wired-or approach with a pullup resistor requires too much power. One could fling an IORead off to a location with one address bit known to be zero, if any cache is not yet finished it could drive that bit to a one. This violates the single driver invariant which has been preserved on the bus so far. It also requires the state machine to poll instead of passively waiting for an input to change. Another hack would be to use a variation on Hoel's trick. Reset a flop when the IOWrite to location 1 occurs. Every cache in which operation in progress is set flips the flop on every cycle and drives the flop out onto a wire. If the cache with operation pending set ever sees two cycles in a row with the same value on this wire then it says to itself ah hah and resets operation pending. Should a weak resistive divider network should be put on this line to keep it from flopping around when no drive is applied?