CSL Notebook Topic To Chip Cutters Date October 17, 1984 From Rick Barth Location PARC Subject Sage Design Organization CSL XEROX Release as [Indigo]Sage>Sage.tioga Came from [Indigo]Sage>Sage.tioga Last edited by Rick Barth, January 16, 1985 4:22:45 pm PST Abstract Sage is a system for testing digital integrated circuits. It eventually will allow Rosemary test programs, enhanced with timing information, to stimulate and evaluate the response of an integrated circuit. Introduction The hardware development effort in CSL has mostly switched to the design of integrated circuits. To develop these circuits requires a method for testing them outside of the system they are intended to be embedded in so that strange test conditions can be setup during development and because unit testing must be done for wafer sort during "production". There are several alternatives to testing that could be tried. Stick with the Dolphin tester. Build yet another TTL style tester based on a Dicentra or Dandelion enhanced with a Multibus card cage. Use the ED Apple tester. Build our own. Buy a "Sentry" tester. Experimental notes 10/24/84 Cranked up the Sage Tester from Gasbarro's directory. On Channel02, MPC43A, chip A, putting the pattern (LH)* in causes channels 0 through 7 to respond the same way, and channels 8 through 15 do nothing. 10/25/84 Fixed all the magic values that determine what bits to ship given what pair of outputs are wanted. The data bits have the high order bits attached to the even channels on one side of the chip and to the odd channels on the other side of the chip. This has been fixed in version 3 and beyond of the Channel chip and so the software must be changed when later revisions are used. 10/26/84 Busted the board just before leaving last night. Had all 16 channels working, one at a time, except that channel 8, and channel 9 less severely, had the 10MHz XClk coupled to it. Upon powering it up this morning the XClk was not coupled to the pin until I performed a set channel, at which time a 1V version of XClk became coupled to channel 8. BClk may not have been running since the Dicentra does not continuously generate it. Discovered that the PulseGen chip that I put my thumb on was clamping CS' to 2V and that the replacement part was one of the incorrectly bonded parts. Putting a new correctly bonded part in resurrected the system. Then playing with the pad power supply eliminated the fuzz on channel 8. This seems to be the same sort of problem as was seen in the PulseGen chip where the metal line carrying the output transistors gate voltage was narrow and that caused some sort of oscillation. Widening the metal line in the PulseGen chip eliminated the problem, we should probably do that to the Channel chip as well. 10/30/84 Yesterday saw all 16 channels in a single channel chip running at the same time. I had them all put out the same rectangular wave and then every other channel put out the same rectangular wave but 180 degrees out of phase. Then I plugged in a PulseGen03 chip, modified SageFace and SageTest to use the internal feedback circuit and tryed it out with no success. Today I started probing about, finally remembered to flip the external clock select switch into the internal position, discovered that the external clock input pad is inverting and we neglected to put that inverter into the layout for the internal feedback circuit. Putting a Model 7 picoprobe, with the 50 ohm resistor removed, down, setting the external clock select back to external and connecting the probe to the external clock input pad caused the thing to start working. The waveform is really lousy, 2V to 3V sawtooth, so it just barely works but it does work. After modifying the software to exercise the counter it became clear that the hack setup with the probe will not work. The problem is that the multiplexor for the clock comes after the tap for the control logic. Thus the external clock cannot run the internal control logic and that lousy sawtooth waveform is trying to run the counter. We blew the feedback line and then put down a sense and force probe with a pulse generator to invert the signal. This doesn't seem to work so good. Tomorrow we should try: 1) putting a real inverter in there, and 2) just disconnect the oscillator entirely and use the single cycle feature of the pulse generator to see if the counter and the Done circuit works correctly. 10/31/84 Tryed putting a real inverter in with no luck, I suspect the external clock select switch was in the wrong position, have to go back to that. Tryed injecting a clock into the control logic. It appears to work although the bits inserted into the counter have to be the 16 minus the number of cycles desired. 11/13/84 After the last set of screwing around it finally became apparent that the clock generation circuit and the stop control circuit had conflicting assumptions about the state of the clock line when the pulse generator was idle. This caused the current implementation to be punted. I redesigned the clock generation circuit to assume that the clock was low when idle. After wire wrapping the entire control circuit there were a few bugs but we now have a pulse generator that will emit a countable number of pulses or a continuous stream of pulses. If an alternating high low pattern starting with low is put into a channel and pulse lines 0 and 8 are used to control it then pulse line 0 rising edge causes the falling edge and pulse line 8 rising edge causes the rising edge. There is 30 ns delay from pulse line 0 in to channel edge fall and 70 ns delay from pulse line 8 in to channel edge rise. When pulse line 0 causes a falling edge then pulse line 3 samples that edge if it is set to have its rising edge 15ns later than pulse line 0's rising edge. 1/21/85 These notes pertain to the new Sage Dicentra code. It appears that the multiplexor clock will randomly start up in either position rather than being cleared by the reset. 1/22/85 There are two outstanding problems: 1) The waveforms have two different shapes. They are not inverses. Looking at the Read and Write channels one mode has ~100ns up and ~600ns down, the other mode has ~200ns up and ~500ns down. The precharge channel has ~50ns up and ~300ns down, the other mode has ~275ns up and ~75ns down. The access channel has ~200ns up and ~150ns down, the other mode has ~125ns up and ~225ns down. All channels change modes together. 2) My model of how the thing works does not allow me to get the data channels to change at the shift clock when I think they should but rather they change at the mux clock. It also looks like the numbering of the input pulse lines may be scrambled since the pulse lines inside of the channel chip are labelled 0, 8, 1, 9, 2, ... If the input pulse line decoder does the obvious thing then to get pulse line 1 a two must be put into the register, etc. Moving the reset pulse in SageImpl from before setting up the channel chips to after doing so eliminated problem 1. Problem 2 remains. The lowest address pulse line of a pulse pair is the mux clock, not the shift clock as I had assumed. That explains why the data channels change state on what I thought was the mux clock since it is really the shift clock. Random Thoughts 1/16/85 This note contains a list of things that should be put into the next generation of tester chips. The channel chip contains a static RAM in the center of the chip with the pin electronics arranged down 2 sides of it. There are 128 cycles of data, 2 phases per cycle, 3 bits per phase. The output values encoded are {drive 0, drive 1, pulse 1, pulse 0}, the input values are {expect 0, expect 1, expect tristate, don't care}. All input values cause the output drivers to disable. There is space for 32 channels per chip. Each DUT pin has a data pin next to it that allows loading of stimulus and unloading of response. Perhaps the number of edges should be increased to 32. Seperate VIH, VOH, VIL, VOL, pins are attached to voltage comparators. Multiple sets of these voltages are provided and some bits in the channel control register select which voltage is actually used. A pin sets compare or store mode for the sensed value? Maybe just eliminate sending stored data back to buffer memory when doing sort rather than debug. Some bits in the channel control register determine the amount of active loading put on the pin. The pulse generator chip has a more space efficient decoding mechanism, more pulse lines are provided and the length of the delay line is longer. There is a second delay line which allows the amount of time between taps of the primary delay line to be varied. To Do Prior To Layout Measure the current through the Channel chip and determine if a 32 channel chip will have cooling problems in a 144 pin pga. Find out why the delay from pulse line in to channel change is so large. The input shift register latches on the rising edge of the clock which means that it is open when the clock is low, i.e. the idle state. That means that the last sample is whatever is on the pin after the clock has stopped. Is that right? Find out why the channel chip does not put out the same waveform given the same input. It appears to be a mux clock reset problem. nChannelReset is labelled as ChannelReset in the logic drawings. Layout Widen the pad gate voltage supply line in the Channel chip. Layout the control circuit in the pulse generator. The counter can probably be saved but everything else should be redone. Perhaps use the standard cell stuff. In any case check that the complex gates have low resistance paths to ground. Push the external/internal clock multiplexor back before the tap to the control logic in the PulseGen chip. If the loop which programs which channels have local hold set and which do not takes too long then the data in the shift registers may die because of the delay between reset of local hold and the start of the clocks. A change in the tester hardware is needed to avoid this race. A line should be added from the channel control register to all the channel chips which forces all the channels to be static regardless of the value of local hold. A distinguished value is needed in the pulse line tap address registers that causes the pulse line to have no tap connected to it, just jam it high or low. This can be the default setting of the register so that the software does not need to carefully program unused pulse lines to not use the same taps as some other pulse line. Similiarly a value is needed in the channel control register to independently cause the input and output clocks to be connected to no pulse line, jamming the output to tristate. Without this feature a pair of pulse lines must be wasted or additional loading must be placed on a pulse line pair to program the unused channels. ÊÛ– "Cedar" style˜Icenter•MarkcenterHeaderšÐbl˜ImemoHeadšÏsœžœžœ˜*Lšžœžœ˜Lšžœ žœ˜%Ilogošœ˜Iabstractšž œ"ž œ#žœžœ+˜“NšžÏtœÎ˜×head˜IbodyšÐgpâ˜âP˜Š—˜˜Pš Ì˜Ì—˜Pš û˜û—˜Pš “˜“—˜Pš ë˜ëPšœ°Ïiœ˜ºP˜ÒP˜õ—˜Pš ´˜´—˜Pš £˜£P˜ßP˜œ—˜P˜2P˜w—˜˜#Iitem˜©Q˜¬—P˜•P˜‡P˜ß——˜˜Pš `˜`Pš œÐžœžœžœžœ«˜ŒP˜„——˜O˜P˜|P˜HP˜ðP˜ƒP˜@O˜Pš ;˜;PšœÞ˜ÞPšœ¼˜¼P˜ÊP˜Æ——…—* ,