CrossRAM03Problem14Jan86.tioga
Hoel, January 31, 1986 12:20:04 pm PST
CrossRAM03 Problem, January 14, 1986
Introduction
This morning, as I was looking at a Versatec plot of an input pad and output pad from CrossRAM03, I noticed that the BIDIRECTIONALPAD's P-channel output driver is not connected to the metal2 VDD bus. The necessary vias are missing. This means that CrossRAM03, version MPC5NAV, won't work.
Here are some interesting questions about what to do:
o How long would it take to make a new via mask?
I believe Microfab is currently looking for work and would offer 3-day turnaround for free. The MEBES software can be run overnight. A fix to the Chipndale source could be made without having to reassemble the chip from the core description.
o Should this mistake be fixed in MPC5NA, the ICL run?
I'd like to say yes, but there are other factors to consider: possibly causing a schedule slip, possibly messing up other dice, etc.
o Should this mistake be fixed in the VTI run?
Definitely.
o Have we found the last mistake in CrossRAM03?
That's very hard to say. It was rushed and didn't get as much checking as it should have gotten. The new design rule checker didn't work at that time. Anyhow, fixing this particular mistake would allow us some visibility into the functioning of the interior of the chip, whether good or bad; the current mistake obscures everything.
o How much would it cost to make a new via mask?
Say between $1500 and $2000. Perhaps this is irrelevant, since we want to make the VTI run regardless, and we need the fix to learn anything useful.
Ray Kennedy
I talked with Ray Kennedy about the problem. Ray says ICL is about five days from having to have the via mask. The ICL crew is presently working extra hard to make the schedule slip caused by a flakey Coyote glass system, so Ray is particularly interested in not slowing down progress to wait for a design fix. He thinks people might come in on the weekend, etc. So, he thinks they'll need the via mask by Monday at latest.
Ray also made the point that he'd rather not slip in a new via mask at the last minute. It increases the chance that something else will get screwed up. (For example, he's seen a case where the job deck for the fix didn't get made right.) But he's willing to hear our case.
Ray will put a hold on MPC5NA at the via patterning step. He will then await word from me about what plan to follow. Either lift the hold and use the old mask, or substitute a new via mask and then lift the hold.
Bob Allen
(About 11:30.) I can't find Bob Allen. But he's in. I leave him a note to contact me ASAP. I need to find out how fast we can really get the new via mask made.
(4:00.) Bob is in a meeting; but he'll be out by 4:30. I'll talk with him then.
Ed McCreight
About 3:00 I talked with Ed about the problem. He thinks we should just get on with making a new via mask. He told me how to set up the MEBES command file to make just one layer. I'll use the name MPC5NSV.
Ed agrees that it makes no sense to submit the run to VTI without fixing the via mask.
If ICL is concerned about whether the new via mask is OK, Ed suggests printing a silicon wafer with both the old and the new via masks, perhaps with the new one offset by a micron, and visually inspecting the result.
Bryan Preas
About 4:15. Bryan supports the plan to make the new via mask and talk ICL into using it. He's not especially concerned about the probability that more bugs remain; you don't know it's bug-free until you see it work.
Bob Allen and Sue Stuber
About 4:30. I meet with Bob as scheduled. Sue joins us. We all agree that making a new via mask is the right idea. Microfab should be able to turn it around quickly. (Sue thinks the line may need the mask even before Monday, Ray's estimate.) I agree to bring over a mag tape by 10:00 tomorrow morning (Wednesday, January 15, 1986).
---------------------------------------
So
So here's what I did:
1. Made a modified source file.
a. %cdread [Indigo]<Dragon>CrossRAM3>CrossRAM3Fabricated2December.dale. This is the Chipndale source of the original CrossRAM03 chip, MPC5NAV, and its VTI-biased version, MPC5NRV.
b. Pushed into BidirectionalPadCommon and added six vias, connecting the P-channel output driver to the metal2 VDD bus.
c. Renamed design to "CrossRAM03Fabricated 14Jan86."
d. Notice that it's hopeless to do any significant amount of further checking before turning over the tape tomorrow at 10:00.
e. Output to local file
CrossRAM03Fabricated14Jan86.dale.
(Directory ///users/Hoel.PA/Chipndale22drc/.)
2. Made a modified Mebes command file.
a. %open CDMEBESForMPC5NRV.load.
(Directory ///users/Hoel.PA/Chipndale22drc/.)
b. copied to CDMEBESForMPC5NSV.load. Modified to generate only the via mask and to output to design MPC5NSV.
c. %CDMEBESForMPC5NSV. (Ran the modified load file.)
d. In Chipndale, selected menu space-P, the MEBES entry. (About 6:15.) (Done by 6:35.) It wrote two files on directory ///MPC5NSV/, namely MPC5NSV.arch and MPC5NSV70.AA. (The latter file has a few more bytes in it than did the previous via file; that looks right.)
3. Wrote resulting files to mag tape. (Wednesday morning, about 9:00.)
a. It wrote two files. TapeTool.log is:
TapeTool of June 10, 1985 8:59:50 am PDT
Session began at January 14, 1986 6:38:10 pm PST
Please open connection
Opening to Maggie ... Tape Server Protocol, V0.3
Opening to Maggie ... Connection already open.
Enumerating file list ... Done
Enumerating file list ... Done
Starting write from []<>MPC5NSV>MPC5NSV.arch!1 ... Done.
2048 bytes written (not including padding), in 1 records. (16384 bits/sec)
Starting write from []<>MPC5NSV>MPC5NSV70.AA!1 ... Done.
505856 bytes written (not including padding), in 247 records. (134894 bits/sec)
Closing connection with Maggie
b. Note that the file names are right and the byte counts match those of the disk files.
4. Checked MPC5NSV70.AA with MebesPlot.
a. (Sure enough! The added vias are present.)
----------------
Ray Kennedy
About 9:30 am, Wednesday, January 15, 1986. Tape in hand, I look for Bob or Sue, but find Ray first. I tell him that we're going to send the tape to Microfab ASAP. Ray again cautions against last-minute screw-ups. Maybe we should plot the tape here first and take a look.
Ray suggests we get Bill Meuli into the loop. Ray hands me off to Bill.
Bill Meuli
Bill hasn't heard about the via problem with CrossRAM03. But Benny is at this moment going through some kind of check list -- I guess because of a similar screw-up with the metal mask for some other customer. So lets talk to Benny. Bill hands me off to Benny.
Benny Pugh
Benny knows about the via problem with CrossRAM03, because of a mask letter (I think that's what it was called) he got yesterday. So things are cool. I can just give the tape to Sue or Bob.
Later (about 11:30) I bring Benny a copy of my MebesPlotFakeDoc and bring MebesPlot over onto his machine and give him a five-minute demo. Benny likes it much better than the stuff that was available in Cedar 5.2., which required you to type in the coordinates.
Sue Stuber
Sue receives the tape (about 9:50). Sue is afraid that if we wait to turn around a plot through Microfab it will slow down the mask. (It takes a day to plot. Then someone has to go and get it. Then I have to check it. Etc.) So if I'm sure it's the right data, she'd be inclined to omit the plot. She'll check with Ray to make sure there is general agreement.
Sue says Microfab has the capability to show the data on the screen, but I'd have to go there to take a look. Sue says she's used this capability many times before. But this time she wouldn't know what to look for. I decide to decline this opportunity. (What can it tell me that MebesPlot can't?)
I'll go back and check the data using Ed's MebesPlot software. Benny is interested in learning more about this.
Later (about 11:30) Sue says the tape is at Microfab. I confirm that the new vias are present on the disk file ///MPC5NSV/MPC5NSV70.AA, as seen by the MebesPlot software. Sue thinks the mask should be back in ICL by Friday. Great.