Debugging the Counter

With Battat gone, Dr. Phillips came in this afternoon to help test the prototype of the address generator (the 74LVC161 binary counter and the 74LVC139A-Q1 2-to-4 line decoder). The least significant bits (LSBs) -- Q0 and Q1 -- of the counter are used as inputs to the four muxes for their individual channel-select features, while the most significant bit (MSBs) -- Q2 and Q3 -- will be used for the shutdown lines (SDs) to select which MUX chip is active.

Why This Binary Counter?

I don't believe I adequately explained our choice before, so I am doing so now. The binary counter is synchronous counter, meaning it feed all four flip-flops of the muxes in parallel, and the outputs Q0-Q3 define its present state from Count 0 to Count 15. Having a synchronous counter is much better than the alternative ripple counter, which causes each bit to lag behind its preceding one, i.e. Q1 lags behind Q0, at the expense of a 5-10 ns delay. We are building an analog MUX that connects 16 channels to an ADC for 60 ns (for 1 MSPS rate per channel) and cannot afford such a delay.

Monday Session: Observations

We began by checking if the counter operated correctly and removed the LEDs we used before for indication of the count. It worked, making our job for the day slightly easier. However, at the request of Dr. Phillips, we made a color-coding system for the outputs with wires and pin numbers:

We increased the clock frequency to  500 Hz and connected the MSBs to the decoder inputs (A and B), checking carefully if the SD lines performed correctly and equally in time length: the decoder outputs SD0-SD3 ran low for a fourth of the time in sequence and had no intermediate states between HIGH and LOW. We measured the transition times at the decoder outputs through 10x probes, with a 300 MHz oscilloscope (Model: DPO 3034), and found them to be 8-16 ns from 0 to 63%. However, once we increased the clock frequency to 9-10 MHz, the decoder output transition times were correctly-timed sometimes and at other times were clearly wrong. The incorrect time intervals were 107 ns (with an uncertainty of ~1 ns), and, coincidentally, the function (clock) generator at this point was set to 9.3 MHz, or with a period of 107.5 ns. We saw the same timing errors in the counter outputs and found the odd behavior to be quite sensitive to the exact frequency. As frequency was increased from 8.5 to 10.0 MHz, at some settings the operation was correct and at 10.0 MHz, there was no output at all. 

The Importance of Cable Types

We sought to resolve the issue by looking at the cable type. The cable used in 10x probes is specially designed to limit its capacitance and has a much higher impedance than the standard 50 ohms. (Note: The output of the function generator used for the counter clock input is marked "50 ohm," meaning that it presents a 50 ohm impedance to a signal returning to it from the attached cable.) It is also important to note that the counter input is capacitive, and, thus, will not match any ordinary cable. Consequently, we cannot avoid any reflection of the clock edge by the counter or any signal that bounces from the end of the cable back to the terminated end. The cable round-trip time is ~10 ns and the clock rise time is most likely less than that, so we should expect "ringing" or "bouncing." Acknowledging these facts, we replaced the cable from the function generator to a 50-ohm cable, matching the cable's impedance to the generator's and resolving the issue of a disruptive, reflected signal. Doing such is called "back-end termination," and ended the erratic behavior we had seen with increasing the clock frequency. Now, at 10 MHz (the maximum frequency for the Agilent 33210A model), the counter and decoder outputs displayed the expected signals. We also ensured that only one 50 ohms cable was connected to the generator's output, as two cables connected with a "T" allows a signal to reflect from the second (disconnected) end with an impedance of 25 ohms and back through the cable connected to the counter (bringing us back to where we started).

Next Steps

To be completely sure, we need to re-test the circuit with a generator capable of creating a 16 MHz clock and Prof. Berg has suggested using a high-speed bridge rectifier circuit to give us such a frequency. We also need to connect the two LSBs to the address lines on the MUX eval board. This requires soldering resistors onto the demo board per the manufacturer's recommendations and creating a minus supply, required by the MUX. Once we verify that the MUX is working (using the signal simulator circuit I designed earlier), we can move on to creating the additional MUX boards and also the printed circuit board (PCB) design.