Resolve status of strange IO line in IO array. This line was supposed to be used to reply fault in case the cache received a bad transaction.

There needs to be circuitry to check if there is a protection violation on IO, and if there is, to make the funny line match. The ram contents of this line are supposed to be the second word of the IORply that should be generated to indicate a fault.



Need to complete the design of the statistics counters.



Snooper not loaded for RBRqst when AOw=0.



The simple circuit to set and clear InterruptStatus bits in the IORam didn't work because whether the bit got set or not depended on the bit line, and the bit lines went to their non-precharged state only after the select line went high; by that time the damage had been done.

Implemented a master/slave solution to setting and clearing. The old value is saved in a master latch while RamSelect is low, and the new value is put into the slave while RamSelect is high.

It takes almost one cycle to compute match. This means that ARM/AVM are probably indeterminate when the clock edge comes, raising the possibilty of instability in the receiving flop.

Changed inverter in RCamInterface and FlagsInterface to a NOR to force ARM low during match cycles.

Looks as though BCtlClrOw and BCtlSetOw are not generated anywhere. Should go into BCtl.



The decoding of PCmdWtBit and PMode was not being done correctly. Furthermore, the flags were not getting written properly because only one of the write drivers was enabled (due to the requirements of partial match).

Moved most of the control out of the interface into a separate FlagsInterfaceCtl. Created a special gate to allow all three to get written and only one of them to be matched.

Select lines in IOHole were left floating. Also, Victim was left floating.

Connected them to Gnd/Vdd as appropriate.

Select lines in IOHole were left floating. Also, Victim was left floating.

Connected them to Gnd/Vdd as appropriate.

The signals LVM, LRM, and Victim were connected to two muxes, the RSMux, and the CSMux. These muxes were constructed using pass gates, which made them conduct signals both ways. Furthermore, since the gates needed Cmd and nDCmd to operate, and there was a delay in generating nDCmd, it was possible for more than one pass gate in a given mux to be on temporarily. This meant that this mux would put an X on one or more of the lines LVM, LRM, Victim, and on the output of the mux. Furthermore, since we wanted the operation of the two muxes to be completely independent (one for the bus, and the other for the processor), we could not impose a condition that imposed some timing relation between the use of the two muxes.

Put inverters before the pass gates in both muxes to prevent backward propagation. This caused us to flip the sense of the incoming signals to nLVM, nLRM, nVictim. As a result, the following cells needed to change in addition to the two muxes: AMCell, Victim.

The EnRS signal is to far back in the chain from LVM to RamSelect; this leaves a smaller time for the Ram to read or write, and it forces us to make the last gate be a nand which would be too large.

Moved EnRS from RSMux to SharedOwner.

The transistor strength of the pullup in the SharedOwnerInterface was weak, which was fighting with the weak inverter in the latch. The fighting took place only when the pass gate was on.

Changed pullup to medium-weak.

This problem was Rosemary related, but we need to make sure that the timing in the real circuit is such that the problem doesn't happen. The timing of PWtInProgB is the same as EnRS. Suppose that EnRS comes slightly earlier than PWtInProgB when writing to a shared line. What could happen is that the line will get written into even though we don't want this to happen.

In the simulations, we've simply made PWtInProgB span EnRS.

This problem was also Rosemary related, but we need to make sure that the timing in the real circuit is such that the problem doesn't happen. When EnRS goes down, the latch in the RSMuxInterface changes, thereby changing RSCmd. At the same time, the and gate in Shared Owner Cell is trying to turn off. There is a race here, and we need to make sure that the path via RSCmd is slower.

In the simulations, we've simply made PWtInProgB span EnRS.

The solution to P11 introduced another problem, in that the Owner bit could get written via glitches in RamSelectIn (earlier, RamSelectIn had already been gated with EnRS).

Added a P-transistor driven by nEnRS in series with the path that sets owner from RamSelectIn.