1. The protocol must be changed to include a clear all vp valid order and a mechanism to make interpretation of map done a function of the processor which issued the map operation. In addition their "relocation field" must be reserved for processor number. I don't think this requires any change in their current design.

2. The ED design must look at the real address extension field and only match when it is zero. If it does not do this then the machine is restricted to 8 MW (32 MB) of real memory, which is clearly inadequate.

1. TTL to CMOS level shifters must be inserted on all inputs.

2. The cache should only set MNAbort for a read quad addressing a block it contains if the master bit is set for the quad. This requires removal of some logic from the array. It should always set MNShared with a timing that is one cycle delayed from where it does os now..

3. The quadword transport order must conform to the ED order, it will depend on the address bits and MNShared, instead of being a simple count. This requires a state machine instead of a counter.

4. Stream write must be treated as write quad. This requires modifying the command decoder in the M controller to map both requests into the same microsequence. Stream reads must be treated not quite like read quads.

5. The ED design has two dead cycles in read quad and responds with shared on the second cycle. This requires another cycle in the read quad microcode. It does not allow for faster memories in the future that could respond with only one dead cycle.

6. The IFU must be changed to issue some new P bus commands so that the cache can map them through to the corresponding M bus commands that ED has defined for mapping operations.

7. Correspondingly, the cache must be changed to do mapping with the ED mechanism instead of using IORead as it does now.

8. The wait cycles in write quad are at the end of the transaction instead of at the beginning, as read quad is. This requires two flow control mechanisms in the hardware instead of one.

9. In the ED design the commands are multiplexed on the high order bits of the data bus and there is a address/command cycle wire to differentiate command cycles from data cycles.

10. The page size should be changed back to 512 bytes to avoid confusion. This requires modest changes to the cache.

1. ED does not allow a cycle from bus grant to bus mastership. The current cache design requires a phase of delay to setup the array to perform address assembly rather than address matching. One could burn a cycle or redesign the match array. Neither of these solutions are acceptable in my opinion.

2. ED transmits their parity delayed by one cycle. This is less than wonderful for the Dragon cache since it uses dynamic memory with parity and would like to store it on the same phase that the rest of the data is stored. A number of solutions have been proposed, all of which are hacks.

3. Their I/O address encoding does not leave large chunks of sequential space unmapped. This means that addressing the display memory will have to be done in chunks. Or we could implement another set of I/O commands that conform to our desires. However then their bus masters will not be able to drive our bus slaves. They may change this.

4. The map operations that they have defined do not have sufficient space to transmit the address space i.d. There is no encoding space for other map processor commands such as enumerate map entries if we implement flow controlled I/O operations. The clearest solution is to adopt our I/O command based map operations. Defining M bus commands for these operations is unnecessary.

1. They do not flow control their I/O operations. We will not be able to directly map some portion of our I/O address space onto the VME bus. This means that some more cumbersome mechanism such as causing the baseboard processor to do the I/O by commands passed through shared memory or by using software loops testing status bits will be required. We also will not be able to read/write the frame buffer unless the unreasonable restriction that the frame buffer be able to process such requests every cycle is imposed

2. The redesign will take 3 to 6 months of LSI designer time, in particular my time. Some of that time is just reorganizing the controller, some of it is synchronization costs since I can no longer just lean back in my chair and make design decisions, I have to coordinate with the guys down south.

3. There is only space in their encoding for 16 processors.

4. We may end up hitting a show stopper that requires a major change on their part in order to allow for functionality that we must have. They will most likely not do it and so all the work will have been for nought.

5. We may not explore parts of the design space that we ought to because we feel that we should be compatible with their design.

6. The ED design does not respond to DHold. Without this we lose the ability to stop the machine at an arbitrary cycle. This eliminates a very powerful debugging tool.

7. Their encoding only allows for transmission of 24 bits of virtual page. Coupled with their 512 byte page size this restricts our virtual address space size to 31 bits.

8. The maximum real address space size is 28 bits, currently it is 23 bits. This restricts us to 8 MW or real memory.

9. The page size of 512 bytes doubles the size of the map table and at least doubles the probability of map misses in the cache.

10. If we enhance the M bus command set to include flow controlled I/O commands then the command encoding space is full.

11. The I/O address space is only 28 bits. This is a problem when we have large frame buffers. We need at least 25 bits for the map processor, assuming that we change to I/O command based map processor operations.

1. They already have a working M bus using TTL implementations. We can use it for initial debugging.

2. They have memory, disk and ethernet controller boards. The memory board is certainly a boon, especially since it has a dumb map processor on it. The disk and ethernet boards are less of a boon since we had planned on buying commercial versions of these anyway. The disk board makes things more wonderful for the software since it supports labels, unlike known commercial boards.

3. The mechanical and backplane design have been done.

4. As yet unknown future designs can be traded back and forth.

5. The boards that we design are an obvious upgrade path for more processor performance for their system.