Electronics > Repair
Series defect on agilent 167xx boards?
DogP:
Quick update... I fed a roughly 2 MHz clock into several inputs on the 16750B, and looked at the difference between the regular output and timing zoom output. Attached are a couple screenshots. Notice that only some of the same signals are toggling... and sometimes it's a different set of those pins that toggle (and sometimes none at all). But, the signals that are actually toggling are the only ones that ever do toggle in timing zoom.
The other thing to notice is that most of the changing signals toggle every sample (if I zoom into the toggling section, they toggle every 500ps). #16 is the one oddball, that seems to have some sort of lower frequency component, but it doesn't match the frequency, nor time alignment with the actual 2 MHz signal.
Other than that, I moved the LA to my workbench closer to the rest of my test equipment, so I could probe it easier. I used the ribbon extender so I could probe both sides of the board, and comparing back and forth between my working 16750A and this 16750B, I haven't found anything that looks out of the ordinary. The signals at the ANDs look fine, and for the most part, everything looks very uniform while running the zoom chip select and acq tests.
One nice thing is that they didn't tent the vias on the top side of the board, so they make good test points for the scope probe.
I plan to retry the real signal test while probing to see if anything noticeably changes (like actual signal shows up, etc). Also, I'll probably make the 1K probe like you're talking about and test that while running as well.
Thanks,
DogP
DogP:
Interesting update - I tried probing a bunch of pins with my Z0 probe (simply because it's input is 1K to GND). I didn't find much interesting, EXCEPT that probing pin 135 on the FLEX chip causes things to sorta work (either side of the resistor). See attached screenshot. I say "sorta", because the frequency is still wrong, but I consistently see signals on all the pins that have signals, and I never get the error about the WRAP flag.
Also, when probing that pin, self-test actually passes the zoomChipSelTest... though fails the zoomAcqTest. But, the only failure it gets on the zoomAcqTest is the edgeCount (no errors about FISO stuck bits), which maybe makes sense, since the output frequency I was seeing didn't match the actual input frequency.
--- Code: ---pv> x zoomChipSelTest
Slot E: Filling FISOs for Pods #1 with zeroes...
Slot E: Checking FISO #4...
Slot E: Checking FISO #3...
Slot E: Checking FISO #2...
Slot E: Checking FISO #1...
Slot E: Checking FISO #0...
Slot E: Filling FISOs for Pods #2 with zeroes...
Slot E: Checking FISO #4...
Slot E: Checking FISO #3...
Slot E: Checking FISO #2...
Slot E: Checking FISO #1...
Slot E: Checking FISO #0...
Slot E: Filling FISOs for Pods #3 with zeroes...
Slot E: Checking FISO #4...
Slot E: Checking FISO #3...
Slot E: Checking FISO #2...
Slot E: Checking FISO #1...
Slot E: Checking FISO #0...
Slot E: Filling FISOs for Pods #4 with zeroes...
Slot E: Checking FISO #4...
Slot E: Checking FISO #3...
Slot E: Checking FISO #2...
Slot E: Checking FISO #1...
Slot E: Checking FISO #0...
Mod E: TEST passed # "zoomChipSelTest" (13, 5, 1)
--- End code ---
--- Code: ---pv> x zoomAcqTest
Slot E: Chip9: edgeCount=2570, exp=811
> Slot E: Chip9: Zoom Acquisition Data Frequency Test Failed!
Slot E: Chip8: edgeCount=2570, exp=811
> Slot E: Chip8: Zoom Acquisition Data Frequency Test Failed!
Mod E: TEST FAILED # "zoomAcqTest" (7, 7, -1)
--- End code ---
Do you happen to know anything about this pin? It looks like it goes to an inner layer, and haven't had a chance to track down where it ends up yet. But suspiciously, it's right next to pin 136-138, which earlier you said are some Zoom chip select pins.
BUT, something else that's interesting... I did the exact same test on my working 16750A, and got the exact same result (same pins showed activity at the faster than actual rate). So, hopefully this pin provides some clues, but maybe it actually leads nowhere. :-/
Thanks,
DogP
DogP:
OK, not quite sure what that pin is doing, but I tracked it to U16 pin 5, through a 316 ohm resistor. U16 is a SY89421V PLL, and pin 5 is the F1 input, which is the loop filter. So... I'm not sure if this is intended to give the FPGA some control over the frequency, or something else. But maybe it's a clue that clocks are a problem... so I'll take a look at the clocks in that area and see confirm everything looks correct.
DogP
MarkL:
Interesting that it could be a clock issue.
I did some poking around and found the clock input on the zoom chips. Here are my updated notes with what I think is on that side towards the pod connectors (any corrections/additions welcome):
1NB4-5040_zoom_capture
144-pin QFP
----
43 nCS
46 Data bus
48 Data bus
51 Data bus
53 Data bus
55 Data bus
57 Data bus
60 Data bus
62 Data bus
----
109 Sample data in
111 Sample data in
114 Sample data in
116 Sample data in
117 Sample data in
119 Sample data in
121 Sample data in
123 Sample data in
125 CLKA+ from zoom clock chip
126 CLKA- from zoom clock chip
127 CLKB+ from zoom clock chip
128 CLKB- from zoom clock chip
129 Sample data in
131 Sample data in
133 Sample data in
136 Sample data in
137 Sample data in
138 Sample data in
141 Sample data in
143 Sample data in
----
Notes:
Clocks run when capturing, not constant freq
CLKA and CLKB are 90 degrees out of phase most of the time
Clocks also seem to run when moving data out of the chip
Zoom clock distribution chip 1821-4731
Generates 5 pairs of clocks that are distributed to each board
Receives clock and clock- from clock chip (itself) through gray cable
Fans out clocks (CLKA+, CLKA-, CLKB+, CLKB-) for the 5 zoom chips
Each zoom chip gets its own set of 4 clocks
Attached are some scope traces of what I found on the clock inputs. nCS makes a good scope trigger input, and the clocks can be found on a tiny resistor pack on the bottom (see photo). The clocks when running are 156kHz. Might be worth a look if you suspect a clocking problem.
(Ignore the spikiness in the waveforms. I'm using a long ground wire clipped onto the chassis. Good enough for what we need to see here.)
EDIT: Forgot to mention this is all happening while zoomChipSelTest is running.
Here is the script:
--- Code: ---#!/bin/sh
export PVRESULTLEVEL=10
export PVDEBUGLEVEL=9
(
sleep 8
echo "s e"
while true; do
echo "x zoomChipSelTest"
sleep 3
done
) | pv
--- End code ---
DogP:
Aha! Smoking gun...
I started checking the SY89421V pins, and saw the 100 MHz reference at RIN, and checked the S pins, which showed N=10. So, the VCO frequency (output on HFOUT) should be 1 GHz, and FOUT (which is the feedback at FIN) should be 100 MHz.
Unfortunately, probing FOUT and FIN showed no visible signal. HFOUT is too high to check on my oscilloscope, so I grabbed the spectrum analyzer. From there, I saw the freq. was actually ~1.37 GHz, which is outside the specified range of the VCO, so it's probably slammed to the upper rail, likely because the feedback frequency is missing (it's saying "go faster, go faster!").
But, when I pull the loop filter down with the Z0 probe, it looks like it slams to the lower rail at around 320 MHz. Apparently, at 320 MHz, the rest of the circuitry can function, though obviously not as expected (but better than when it's way overclocked).
As a check, I grabbed my good card, and saw HFOUT at 1 GHz as expected, and also had 100 MHz at FOUT and FIN. So... I guess it seems very likely that U16 is bad. I'll swap it from my 16716A later tonight and confirm that's the (only) issue.
DogP
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version