[_CD4_]<dragon7.0>SmallCache>Documentation>SmallCacheProblemLog.tioga!36

SmallCacheProblemLog.tioga

Written by: Pradeep Sindhu, August 28, 1987 4:04:06 pm PDT

Last Edited by:

Pradeep Sindhu, May 16, 1988 3:44:30 am PDT

DRAGON SMALL CACHE PROBLEM LOG

DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY

Dragon Small Cache

Problem Log

Release as [Indigo]<Dragon>SmallCache>Documentation>SmallCacheProblemLog.tioga, .press

Abstract: This document contains a log of problems discovered while debugging the design of the small cache.

XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

For Internal Xerox Use Only

Note: Strike font indicates problems that have been resolved.

Bugs To Fix (From SCActionItems.tioga)

1. Check that AVM, ASh, and ARM are latched in such a way that they are valid for two cycles. This is to make it impossible for latches in PInterfaceCtl driven by PCycle1, PCycle2, etc. to glitch because of AVM and ASh.

2. Provide a way to load the FIFO header from the input to the RBuf.

3. Provide a way to cancel an FBRqst in the FIFO when the Snooper says so.

4. In PInterfaceCtl LdPAdrs is not generated correctly in case of a fault. The problem is that a command in the following PhA will see a reject.

5. The cache needs to distinguish between BIO and IO. One way to do this is to not put the Id part of an IO address in the array but put it outside. Lets call this the IOITdMatcher. The signal that it produces is IOITdMatch.

6. Take care of Set and Clr owner from bus side.

7. Make BCtlSelWSData depend on CWSEq with a hardwire mux.

8. Optimize the bus side microprogram (factor common terms).

9. Make sure that in the SharedOwner interface layout, the pullup transistor is able to overcome the weak transistor in the latch.

10. Prepare streamlined victim cell for Lochner.

11. Think some more about SharedOwnerCell to see if it can be made smaller.

Stuff to Add (From SCActionItems.tioga)

1. Add the pristine bit, which indicates that there has been no write into the cache from the processor side. The advantage of having this bit is that the IFU will never contend for its RAM with RBRqst's coming over the bus. Since RB's are the most frequent transactions, we've essentially eliminated RAM contention for the IFU cache

Problem 1 (April '87)

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.

Status: Unresolved

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.

Fix:

Problem 2 (April '87)

Need to complete the design of the statistics counters.

Status: Resolved

Fix:

Counters will not be put into the first version of the cache, sorry.

Problem 3 (June '87)

Snooper not loaded for RBRqst when AOw=0.

Status: Done

Fix:

Snooper is now loaded on MyRBRqst rather than on MyFBRqst which was causing the above problem.

Problem 4 (July '87)

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.

Status: Resolved

Fix:

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.

Problem 5 (July '87)

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.

Status: Resolved

Fix:

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

Problem 6 (August 10 '87)

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

Status: Done

Problem 7 (August 11 '87)

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).

Status: Resolved

Fix:

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.

Problem 8 (August 17 '87)

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

Status: Resolved

Fix:

Connected them to Gnd/Vdd as appropriate.

Problem 9 (August 17 '87)

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

Status: Resolved

Fix:

Connected them to Gnd/Vdd as appropriate.

Problem 10 (August 17 '87)

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.

Status: Resolved

Fix:

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.

Problem 11 (August 17 '87)

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.

Status: Resolved

Fix:

Moved EnRS from RSMux to SharedOwner.

Problem 12 (August 23 '87)

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.

Status: Resolved

Fix:

Changed pullup to medium-weak.

Problem 13 (August 23 '87)

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.

Status: Unresolved

Fix:

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

Problem 14 (August 23 '87)

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 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.

Status: The path from EnRS to RamSelectIn is longer than the path from EnRS to the and gate, so we should win the race comfortably.

Problem 15 (August 30 '87)

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).

Status: Resolved

Fix:

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

Problem 16 (Sept 15 '87)

In the OutputSection, if PCtlLdFIFO and BCtlLdFIFO are asserted at the same time, then junk will be loaded into the fifo header. Check to see that PCtlLdFIFO is not asserted when BCtlLdFIFO is.

Status: Unresolved

Fix:

Problem 17 (Sept 22 '87)

The order of wires for BDataIn is incorrect. The two words of a cycle should be interleaved, but they are not. The fix requires changes to all of the registers that are in the pipeline between BDataIn and the ReplyHeader input of the FIFO.

Status: Unresolved

Fix:

Problem 18 (Sept 23 '87)

RSCmd was not being generated properly for direct access from processor (ie. not via PCtl).

Status: Resolved

Fix:

Used PCycle0 to force the pside input to the RSCmd mux to have the appropriate value.

Problem 19 (Oct 21 '87)

After Reset, the array signals ARM, and AVM were still X's. They should be 0's instead.

Status: Resolved

Fix:

We initialize the match latches for ARM and AVM in the array to 0 using LdML and ClampM. This adds some circuitry to the interfaces but leaves the array cells untouched.

Problem 21 (Nov 1 '87)

In RamInterface and CamInterface, the precharge and sense circuitry was bad. One inverter was being used to both sense and to drive the Bit and nBit lines, which results in a real slow precharge for one of the two lines.

Status: Resolved

Fix:

Changed cells to use individual precharge inverters.

Problem 22 (Nov 3 '87)

Looks like the timing of EnCamSelExt is not identical to that of EnCamSel. This is a mistake.

Status: Done (March 24 '88)

Problem 23 (Dec 7 '87)

Cesar pointed out that the direction of material for the non cam and ram array cells is improperly chosen. The current choice (m2 vertical, m1 horizontal) is bad because vertical wires are used inside every cell, and sometimes more than once. Horizontal wires either go through without being used, or are used only at the left and right periphery of the cell. It is therefore better to have m1 vertical and m2 horizontal to avoid extra vias all over the place.

Status: Unresolved

Fix:

Invert direction of material in array cells other than cam and ram.

Problem 24 (Dec 26 '87)

In IORam the strengths of the set and clear gates should be made higher so that the ratio of strengths is 3:1 rather than 2:1.

Status: Done

Problem 25 (Dec 29 '87)

Add logic to generate PReset. See CacheNotebook III.

Status: Done

Problem 26 (Dec 29 '87)

Make sure that in the microcode and in the logic PCtlPartVMch, PCtlPartFMch, and xPartRMch are two cycles long instead of just one. These signals must have the same timing as the DriveBitLine signals for correct operation.

Status: Done

Problem 27 (Jan 4 '88)

Test debug datapath in Outputsection.

Status: Not Done

Problem 28 (Jan 8 '88)

xDrVCamBL and xDrRCamBL were inverted in the control. This problem was introduced by moving logic from the interfaces to the standard cell part.

Status: Done

Problem 29 (Jan 10 '88)

RCamInterlockCtl generates an RCamForP that is 3 cycles long. Also, the microcode checks RCamForP three times: during ReadRCam2, ReadRCam3, and ReadRCam4. This causes us to lose one cycle, at the tail end of the use of the RCam by the bus. The fix is to modify RCamForP so it is a two cycle negative pulse ~(BCycle0 or BCycle1) rather than three. The inhibit pulse for PCtl signals should remain 3 cycles long ~(BCycle0 or BCycle1 or BCycle2).

Status: Done

Problem 30 (Jan 11 '88)

The microcode assumes that the data in the ram read latch can sit for two cycles. This is incorrect because the ram read latch is not edge triggered, and so the data could be destroyed almost immediately. The fix is to check whether we have RamForP after having done a read, and if we don't then to simply redo the read.

Status: Done

Problem 31 (Jan 12 '88)

In the microcode when we're waiting for RBRply to come back (HMReturn2PC), a VCam Match is done too early in the case of Write and CWS. When the RBRply comes back, a match is done on cycle1 as usual. On cycle3 ARM is ready, and on cycle4 we produce the control signals to write to the victim or to the line that matched the RCam. Thus the earliest next match of the VCam (or RCam) is by a pulse on BCycle6. At the moment, the microcode generates a pulse on BCycle 3. (NonFBTIP changes on BCycle1; uCode sees it, thinks and changes its output on 2; the control pulse appears at the output on 3).

Status: Done

Problem 32 (Jan 12 '88)

The weak pullup transistor for computing AOw and ASh is too strong. AOw will never be asserted!!

Status: Done

Problem 33 (Jan 12 '88)

Check the design of the circuit to generate ARM and AVM carefully. In particular think about putting an inverter immediately after nAM so that you have a good handle on the threshold.

Status: Done

Problem 34 (Jan 12 '88)

ARM is asserted when you write to the RCam. This causes RamForP to go away. The fix is to compute the signal SnoopCycle (which tells when ARM is really valid) and and it with ARM before using it in RamInterlock Ctl

Status: Done

Problem 35 (Jan 15 '88)

In FlagsInterfaceCtl, incoming flags from a MapRply were being captured in a 4 bit register enabled by MyMapRply1. First, this causes FlagsIn to have the timing of BCycle2 which is one cycle too late to be loaded into the FlagsInterfaceRegister because its enable comes on BCycle1. Secondly, there is no need for an enabled register in FlagsInterfaceCtl because the flags will be held in the FlagsInterfaceRegister anyway. Therefore delete the enable from the register in FlagsInterfaceCtl.

Status: Done

Problem 36 (Jan 15 '88)

In FlagsInterlockCtl, OR MyRBRply56 with PCtlFlagsForP so that nPMFlags will be high while the bit lines to write flags are being driven.

Status: Done

Problem 37 (Jan 19 '88)

In the layout of the ram interface, WdRdData and WdWtData are each 256 bits at the top. You have to put a routing cell to have only 32 wires for each of these (actually you need to solve the problem for only the one that's in metal1).

Status: Done

Problem 38 (Jan 19 '88)

ComCellLeftEnd.icon

See what to do with it. Commented out right now.

ArrayMiddle.sch

Check that cell is visible to Sisyph ($SisyphExtractProc#$ExtractNull)

Status: Done

Problem 39 (Jan 20 '88)

Flags were not being written in correctly when we get a PartialVirtualMatch. Now what is done is that flags to be written into the array are always stored in a register in FlagsInterlockCtl and written during MyRBRply56 along with the VCam. The advantage of writing both flags and VCam at this time is that there is only one case to deal with. This also removed the signal PCtlFlagsForB from the microcode.

Status: Done

Problem 40 (Jan 21 '88)

The select wire of the reply mux needed to be flipped. It was causing the wrong word to be returned to the processor.

Status: Done

Problem 41 (Jan 21 '88)

The signals DrDBusRRLatch and DrDBusPWtLatch were not being computed properly in the case of a read hit and write hit. These are now automatically computed from PCycle1orPCycle2. Note that if we get PCycle1 we're sure that we got the ram and so we have permission to drive the DBus during cycles 1 and 2.

Status: Done

Problem 42 (Jan 21 '88)

In the microcode Jmp has ss[PCtlDBusCmd, DBusPWtLatch]. This conflicts with read hits which want to put the ram read latch on the DBus. Remove this.

Status: Done

Problem 43 (Jan 21 '88)

While I was discussing with Jean-Marc about powering the array, I could not answer how the interface is supplied and why the very thin lines are enough. Actually, I am conviced that it nor enough, and my far (a factorof 5 to 10). My rough computations make me think some 60mm lines are needed inside the interface of the Ram. I am not sure I have not taken something into account. I just would like to be sure you know what you do. The problem is for Vdd, not for Gnd. The reason is that Gnd runs vertically while Vdd runs horizontally. This mail is just in case I would forget to speak to you about this problem.

Cesar.

Status: Not Done

Problem 44 (Feb 1 '88)

In the microcode PCtlBusy was not deasserted in the case of PWriteHit.

Status: Done

Problem 45 (Feb 2 '88)

In the microcode, the code for PWriteHit and retry after PWriteMiss was being shared. The miss case terminated with a PCtlReleaseP, so a PCtlReleaseP was also being done in the PWriteHit case. If we now have PWriteHit followed by a miss of any kind, the reject that gets set by PCtlBusy will get cleared by the last PCtlReleaseP. The two cases were split (one instruction added).

Status: Done

Problem 46 (Feb 4 '88)

In the microcode, PAccessPermission was being checked one cycle too early. Moved the check for this to the appropriate place.

Status: Done

Problem 47 (Feb 4 '88)

Took the input of PAccessPermission from the output of the FlagsReg rather than directly from FlagsOut. The older method was wrong because it failed to check permission in the case of a map miss.

Status: Done

Problem 48 (Feb 18 '88)

The timing of PCtlPartFMch assumed in the microcode was not the same as that assumed in FlagsInterfaceCtl. In the microcode it was assumed to be a one cycle long pulse; in FlagsInterfaceCtl it was assumed to be two cycles long. Change the microcode so as to stretch the signal to two cycles.

Status: Done

Problem 49 (Feb 18 '88)

In cell PInterfaceCtl, PCtlFault was being fed directly to the PhA/PhB synchronization gate while PCtlFaultCode was arriving one cycle later since it went through a flip-flop. Since PCtlFault makes FaultA go high immediately, this meant that if PCtlFault arrived in the second half of PhB, the FaultCode would not be valid although fault would be asserted on the PBus. Fix this by adding one delay stage between PCtlFault the input of the PhA/PhB synchronizer.

Status: Done

Problem 50 (Feb 27 '88)

The MSB of RAdrs fed to the RCam was directly taken as BCmdMSB. This was a problem for the DeMap command, which stupidly has BCmdMSB=1. This caused DeMap to not work because it would try to match the IO part and of course it got a mismatch. Fixed the problem by computing RAdrsMSB depending on DeMap. In the future, the DeMap opcode might be changed so it sits in the lower part of the command space (ie BCmdMSB=0).

Status: Done

Problem 51 (Feb 29 '88)

When the processor initiates a DeMap, the cache may get a match, and thereby overwriting the matching location. The fix is to cause the PCmdSpclBit to force a mismatch. Also, remove the terms Demap and SpclRead from Reject1 in PInterfaceCtl since they are taken into account by AVM.

Status: Done

Problem 52 (Feb 29 '88)

The operation ClearAllVPValid was not implemented. To implement it, we need to add a control line to the array (ClrAllVPV) and to PCtl.

Status: Done

Problem 53 (Feb 29 '88)

The flops to generate the partial match signals from PCtlPartVMch and xPartRMch don't fit into the array, so they need to be moved back into control.

Status: Done.

Problem 54 (Feb 29 '88)

The behavioral description of Victim in SmallCacheArrayImpl was bogus because it didn't model the use and victim flops correctly. Fix it.

Status: Done.

Problem 55 (Mar 1 '88)

When doing a successful CWS (oldval=sample) from the processor side, you were relying on the new value read from the ram hanging around for two cycles on the DBus while you did the write. Unfortunately, doing the write necessarily modifies the wdSelect lines so that this value changes. The solution is to add a RamRdLatch that takes its input from the DBus and outputs to the DBus via a tristate. Then, when the new value is read from the ram it can be placed in this latch and this latch driven on to the DBus during the write.

Status: Done.

Problem 56 (Mar 5 '88)

Timing of PWtInProgB is dubious. We need to clock PWtInProgB using RamClock.

Status: Not Done.

Problem 57 (Mar 5 '88)

In the VCamInterface, the read latch is sometimes loaded at the same time as a match is done. This will cause a conflict on the bit lines because the precharge transistors will be trying to drive the line to 2.5V and the drive transistors will be trying to drive them up or down. The fix is to gate Prech with nDrBitLines so it never rises when the bit lines are being driven.

Status: Done.

Problem 58 (Mar 7 '88)

The timing of ClrSh and SetSh was off by one cycle. They were being asserted in cycle 7 when they should have been asserted in cycle 6.

Status: Done.

Problem 59 (Mar 7 '88) Was a nonexistent problem (I incorrectly thought that WriteBlock shouldn't do cyclic order).

Problem 60 (Mar 8 '88)

BCtlDrDBusBData was not being asserted for the oldval of a CWSRply. Add the hardware to BCtl to assert BCtlDrDBusBData during cycles 7 and 8.

Status: Done.

Problem 61 (Mar 8 '88)

When executing a CWS from the bus side, the sample value being returned to the processor that initiated the CWS was the one it originally read out (ie. while executing the CWS from the processor side). To load PRdLatch with the sample value we must put the sample value on the DBus, but of course this means that we cannot have the OldValue on the DBus at the same time. This means that we must move the bus side comparator from its current location (DBus<—>WdRdData) to DBus<—>Output of BWdWtPipe.

Status: Done.

Problem 62 (Mar 11 '88)

The behavioral proc for the array had two bugs, one related to VCam match and the other to RCam match. The match latch was being loaded only on ClockLtoH, whereas it should have been loaded on the appropriate Ld signal.

Status: Done.

Problem 63 (Mar 11 '88)

The behavioral proc for the array implemented the pipelining of RML1, 2, 3 and 4 incorrectly. Rather than doing sequence element assignment to move data from one stage to the next, it assigned pointers to the sequences themselves. The first time this was done, it caused the latches for RML1, 2, 3 and 4 became identical so that the pipelining was effectively defeated.

Status: Done.

Problem 64 (Mar 12 '88)

When the cache generates a reply on the bus side it doesn't flip the request/reply bit. Need to fix both BCyclePipe.sch and SmallCacheBCyclePipeImpl

Status: Done.

Problem 65 (Mar 14 '88)

The logic to generate SelWd1 for the input mux is incorrect since it doesn't take IOWrites into account. Also, it is better to switch the sense of this signal to SelWd0, since this signal would be raised more exceptionally, and so is cheaper to generate. This way, only the terms for CWS and RBRply would need to be taken into account instead of the terms for CWS, RBRply, IOWrite, and WSRply.

Status: Done.

Problem 66 (Mar 14 '88)

There is a bug in the generation of LdVML in VCamInterlockCtl. The term xLdVCamWR should be removed and the xLdVCamWR-Reset used instead. The problem is that LdVML will stay asserted longer than ClampVM (during Reset), causing LVM to go to X's immediately after Reset.

Status: Done.

Problem 67 (Mar 17 '88)

The transistor level simulation fails because the VCamBitLines are not driven when MyMapRply comes back. The VCamRdLatch is loaded on MyMapRply1, and since the bit lines are x's at this time, the latch also gets X's. Then, when sending the RBRqst, the block part of the address is x's. The fix is to (a) assert PCtlWtMchVCam while waiting for MyMapRply; and (b) to keep PAddr on the ABus while waiting for MyMapRply. This way, the VCamWtReg has the PAddr when MyMapRply comes back (remember that VCamWtReg got clobbered by the AID Ram Read done a short while earlier), and so when the bit lines are driven the correct value appears in the VCamRdLatch.

Status: Done.

Problem 68 (Mar 21 '88)

This one is not a real problem, but one only for simulation. The use bit in the array is not cleared during Reset. The fact that the use bits are X's eventually causes all victim bits to become X's. In the simulation of the array this didn't happen because Victim was being shifted explicitly, which caused the use bits it passed over to get cleared. Unfortunately, Victim is not X resistant during normal operation. The quick fix is to put a strong transistor in Victim (just for simulation) to cause the use bit to get cleared during reset.

Status: Done.

Problem 69 (Mar 22 '88)

It looks as though SmallCacheArrayImpl automatically inhibits a Flags match if PCtlPartVMch is asserted. This is incorrect since there is a separate PCtlPartFMch signal that does this.

Status: Done.

Problem 70 (Mar 22 '88)

There is a problem in the microcode, where PCtlPartFMch is not being asserted when doing a partial match to find the translation. If the flags don't match, the translation won't be found. Note that problem 70 was being masked by problem 69 so that we couldn't find it using the behavioral simulation of the array.

Status: Done.

Problem 71 (Mar 24 '88)

Microcode problem: The ReadVCam macro is bogus because EnCamSelExt is not raised.

Status: Done.

Problem 72 (Mar 24 '88)

Microcode problem: The ReadRCam macro has EnCamSelExt fixed to low. This is a problem because when we read the RCam to get a mapping, EnCamSelExt must be low, but when we read it to get a victim address, it needs to be high. Therefore, the value of EnCamSelExt must be passed as a parameter.

Status: Done.

Problem 73 (Mar 24 '88)

How the hell was the behavioral simulation of the array working given Problem72? Obviously, EnCamSelExt was not being taken into account properly.

Status: Done.

Problem 74 (April 4 '88)

In the microcode for CWS, the PCtlWtMchVCam signal to rematch the processor address just after reading CWSNew from the ram was being generated one cycle too early. This was causing the value in LVM1 to go change (to that corresponding to the new match) during the last half cycle of EnRS, and thereby corrupting the CWSNew being read out. This didn't show up on the behavioral simulation because the data is read out on the edge just before the half cycle in question. The fix is to delay PCtlWtMchVCam and the subsequent RamWrite by one cycle.

Status: Done.

Problem 75 (April 4 '88)

This one is not a real problem, but one that is convenient to fix for purposes of simulation. During the idle loop, RBufDataLo is loaded, but RBufDataHi is not. Thus the high half of the second word of a WriteSingle is unpredictable since it wasn't loaded. Lets load both high and lo halfs of RBuf so as to avoid this problem.

Status: Done.

Problem 76 (April 5 '88)

This one is not a real problem either, but one that is convenient to fix for purposes of simulation. When the first 5 cycle packet is sent by the cache, the signal SelectCycle is X's according to Rosemary, but in real life it will be one of the patterns (1000), (0100), (0010), (0001). The fact that SelectCycle is X's instead of being unknown but one hot causes the data for the first 5 cycle packet to be corrupted. This problem can be fixed for the simulation by buffering FIFORdReg Q before connecting it to the muxes that follow.

Status: Done.

Problem 77 (April 5 '88)

This one may be a real problem. The RamRdLatch (the 256 bit one) is not buffered before being connected to a FFwithEnable inside the FIFO (the fifoWtReg). When this register is loaded, there can be feedback from the output of the FF back to the RamRdLatch through the pass gates. This feedback may flip the latch (in the simulation it causes Rosemary to go into an infinite loop). It is probably a good idea to buffer the RamRdLatch from the FF. Since we don't want to touch the Array any more the best thing to do is to hack the fifo wt register. If we modified the FFWithEn, then it would also take care of problem 76.

Status: Done.

Problem 78 (April 15 '88)

The PBusInterface document specifies that PReject and PFault be driven to 0 during PhA and either driven weakly to zero or driven hard to 1 during PhB. These requirements stem from having to deal with more than one cache on the same PBus. When we restrict the number of caches per PBus to one (which is already the case) we can simply drive these signals hard all the time. Driving them in the way specified requires raw transistors, which the standard cell system doesn't appreciate, so the temporary solution is to drive hard both during PhA and PhB.

Status: Done.

Problem 79 (April 20 '88)

The PBus was being driven by PhB AND PCmdIn.CS. This causes PBus conflicts during writes. Clearly the drive equation should be PhB and PCmdIn.CS and PCmdIn.Read. Also make sure that PhB is connected to the fastest input of the nand.

Status: Done.

Problem 80 (April 20 '88)

The PWtLatch was being loaded by RejectAB AND PhB. During reads, the value loaded into this latch is unpredictable (for Rosemary, causing it to loop) because the drive on the PBus turns off at the same time as the the latch enable turns off (both are gated with PhB). Change the load equation to be RejectAB AND PhB AND PCmdIn.Write. Also make sure that PhB is connected to the fastest input of the nand (check LdPAdrs as well to see if PhA is connected to the fastest input).

Status: Done.

Problem 81 (April 21 '88)

Make sure that PhB and PhA are connected to the fast input for each of the signals PReject and LdPAdrs.

Status: Done.

Problem 82 (April 22 '88)

The signal SetReschedule is fed into an asynchronous RS flip flop (the stupid one that is used to synchronize clock signals to PhA-PhB). This is catastropic because the slightest glitch on SetReschedule (which are certain to occur) can set the flop which will cause PReschedule to go high for a PhA/PhB cycle. Perhaps the simplest thing to do at this point is simply provide PReschedule=SetReschedule. Ie., just eliminiate the crappy synchronizer.

Status: Done.

Problem 82 (April 27 '88)

Found a bunch of places in the behavioral proc for the array where SCParms.numBitsPerWord was being used instead of SCParms.numWordsPerLine. Unfortunately, this problem didn't get caught earlier because these two values were the same for the test parameters. Of course, they were not the same for the full size cache.

Status: Done.

Problem 82 (May 5 '88)

In RamInterlockCtl, the computation of xDrDBusWdRdData was incorrect. The term PCtlDrDBusWdRdData was being gated with PCmdRdBit causing ram reads done by the microcode on behalf of write operations (eg. to read the AID register) to not work. Remove the gating of PCmdRdBit.

Status: Done.

Problem 83 (May 5 '88)

After fix 82 there is conflict between the microcode driving the DBus and the autopilot driving the DBus (eg. for writes). Fix this by disabling the drive from the microcode during PCycle1or2. This needs to be done only for PCtlDrDBusWdRdData because this signal is on by default.

Status: Done.

Problem 84 (May 6 '88)

There was a bug in the clearing of NonFBTIP. This register should be cleared by TimeOut as well as by Reset and by receipt of the reply. If it is not cleared by TimeOut, the next time the duration of the timeout will be completely random because the timeout counter keeps running as long as NonFBTIP is asserted.

Status: Done.

Problem 84 (May 15 '88)

In the microcode, IdlePC loads RBufDataHi even though it doesn't need to. Because we want to use RBufDataHi to read out stuff via the debug path, we shouldn't do this.

Status: Done.