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 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 10/25/84 10/26/84 2 10/30/84 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 11/13/84 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 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 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.