CrossRAM03 Problems Introduction Today, March 26, 1986, I asked Rick Barth for the write lock on CrossRAM03, so I could update the CrossRAMCellLibrary, to fix a presumably non-fatal bug discovered yesterday. Rick thought that that might not be the best idea. Instead Rick suggests that CrossRAM03 be updated only to fix fatal bugs. This will minimize the chance of making a functional design non-functional. All non-fatal bugs should be fixed only in CrossRAM04. In this way, we should always be able to go to fab with one design that is known to work and the next generation of design, which ought to be better but might be buggy. During that conversation, we noticed that nobody had been keeping a complete list of all the bugs, both fatal and non-fatal, that have been found in CrossRAM03 since it was first submitted for fabrication December 2, 1985. Clearly that was a mistake. This document is my attempt to remember a complete list of these bugs. April 5, 1986: Later Rick said he didn't mind relinquishing forever the write lock on CrossRAM03, since CrossRAM04 is the current design. I should keep Rick informed as to all bugs discovered, of course. It should be pointed out that for CrossRAM03, we've long since abandoned the notion of keeping as the source the cell library and the core generation programs. The core stuff has been allowed to move on to CrossRAM04. The only "source" left for CrossRAM03 is the Chipndale file made by the core stuff, and a sequence of Chipndale files, each derived from the previous one by editing with Chipndale, to take the bugs out with the least design changes possible. References 1. ///Users/Hoel.PA/Chipndale22drc/CrossRAM03Problem14Jan86.tioga This document describes the problem of missing vias in the output driver. 2. ///Users/Hoel.PA/Chipndale22drc/CrossRAMRevisionStatus9Feb86.tioga This document describes the revision status of CrossRAM03 masks, per layer. Design Problems Fixed In this section we list bugs we considered serious enough to fix at the mask level. (April 5, 1986: we also list bugs we changed without having to make new masks. That's a change of philosophy from when this document was first written.) Note that the fixes didn't get made to the CrossRAMCellLibrary (the one stored with CrossRam3.df) in most cases. Instead, the fixes got made to the Chipndale output produced by the CrossRAM's patchwork/core software. The reason is that this software was pretty experimental at the time, and it was deemed much less risky to make selected Chipndale edits rather than edit the library and run the assembly software again. Missing Vias 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. Found: January 14, 1986. Fixed: January 15, 1986, in: CrossRAMCellLibrary and CrossRAM03Fabricated15Jan86. Extra Contact 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. Found: ? Fixed: February 4, 1986, in: CrossRAM03Fabricated4Feb86 ONLY. (Not fixed in CrossRAMCellLibrary.) April 5, 1986: Fixed also in RevisedCrossRAMCellLibrary, in a more straight forward way, that did not try to minimize masks which had to be changed. Misaligned Metal2 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. Found: ? Fixed: February 4, 1986, in: CrossRAM03Fabricated4Feb86 ONLY. (Not fixed in CrossRAMCellLibrary. In fact, not fixable in CrossRAMCellLibrary, without rethinking the design, since the problem was with the interaction between the library and the core stuff.) Missing Vias Again 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.) Found: March ?, 1986. Fixed: April 5, 1986, in: RevisedCrossRAMCellLibrary ONLY. (Not fixed in CrossRAMCellLibrary.) Stray Diffusion 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. Found: March 25, 1986. Fixed: April 5, 1986 in: RevisedCrossRAMCellLibrary ONLY. (Not fixed in CrossRAMCellLibrary.) Not Fixed Yet In this section, we list bugs not serious enough to have been fixed yet. N-well Contacts 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. Found: December ?, 1985 xCrossRAM03Problems.tioga Hoel, April 6, 1986 1:42:38 pm PST First edited by Hoel, March 26, 1986 10:57:45 am PST Κ˜J™;J™J™4Ititle˜head˜ Ibody˜ΫM˜ΓM˜ΝM˜Ν˜ item˜BN˜I—˜FN˜K———˜˜MšœρΟe>œη˜–˜ ˜»N˜˜N˜5———˜ ˜ΒN˜˜NšœΟbœ&˜EN˜•———˜˜ N˜˜NšœžœΖ˜ε———˜˜šN˜˜Nšœžœ&˜E———˜˜³N˜˜Nšœžœ%˜D————˜ M˜H˜˜ΙN˜————J˜—…—(³