A desk check revealed that the p-channel driver of the BidirectionalPadCommon cell was not connected to VDD, because some vias were inadvertently omitted. The fix was to insert the vias.

As a result of understanding why chips from run MPC5NA did not work, Jim Gasbarro found unwanted contacts in the DecoderLogic cell, which shorted the word drivers to VDD. The fix was to remove the unwanted contacts. Actually, there was some attempt at the design level to minimize the number of masks that had to be changed to implement the fix, which makes the design look a little funny. (Subsequently the "saved" masks had to be made anyway, to meet newly-understood mask biasing requirements, but that's another story.) Perhaps someone will want to change this sometime.

As a result of understanding why chips from run MPC5NA did not work, I found misaligned metal2 connections between some DecoderLogic cells and their associated SRamTwoBits or DRamTwoBits cells. The misalignments were by 0.5 lambda. (They caused design rule violations, but were not believed to be contributing materially to observed problems.) The problem was not exactly with the CrossRAMCellLibrary but with the fact that the patchwork/core sofetware flipped some cells during assembly, and the cells were not designed to be flipped. (In particular the software made cells DecoderLogic@125 and -noname-@2217 from the library's DecoderLogic cell, flipping the latter.) The fix was to edit one of these cells (-noname-@2217, I think) to make the connections match. This was aesthetically undesirable, but it minimimized the extent of the required changes. In the long run, it is recommended that the cells not be flipped.

When Richard Bruce tried to borrow the CrossRAMCellLibrary for his work, he tried to use OUTPUTPAD, a cell which is in the directory, although there is no instance displayed and CrossRAM03 does not use it. (It was an idea that was tried out and then discarded.) This cell suffers from the same problem as BidirectionalPadCommon: the vias that connect the p-channel driver to VDD are missing. The fix should be to delete this cell from the directory. (April 5, 1986: actually I deleted all cells from the library which weren't used.)

While inspecting a wafer processed through the thinOx step, Bob Allen found a small piece of isolated diffusion. It turns out to be a rectangle of pwell contact diffusion, 2 x 3 lambda, under the pad of the BidirectionalPadCommon cell. On the Chipndale screen it's invisible, covered up by the pad's via. Although it violates a design rule, we think it should be harmless. The fix should be to remove this stray piece of diffusion.

When CrossRAM03 was designed, the Dragon CMOS Design Rules were not completely known. In particular, design rule 6.3.6. (N-well surrounds N+ contact by 4 lambda) was not thought to be necessary. (We thought as long as N+ and N-well overlapped, it didn't matter whether the N+ was surrounded.) So there are a large number of violations of this rule. These violations are not fatal, but they could contribute to unnecessary leakage. The fix should be to run the design through a current version of the design rule checker, which knows about this design rule, and fix all violations.