[_CD4_]<dragon7.0>SmallCache>Documentation>SCProblemLog.tioga!21

SCProblemLog.tioga

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

Last Edited by:

Pradeep Sindhu, August 18, 1986 5:25:26 pm PDT

DRAGON SMALL CACHE PROBLEM LOG

DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY

Dragon Small Cache

Problem Log

Release as [Indigo]<Dragon>SmallCache>Documentation>SCProblemLog.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.

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: Unresolved

Fix:

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

Status: Unresolved

Fix:

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: Unresolved

Fix:

Add delay stages to RCamInterface and RCamInterlockCtl.

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: Not Done

Problem 25 (Dec 29 '87)

Add logic to generate PReset. See CacheNotebook III.

Status: Not 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. One cycle long signals cause glitches for Rosemary.

Status: Not 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: Not 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: Not Done

Problem 32 (Jan 12 '88)

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

Status: Not 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: Not 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: Not 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