Electronics > Repair
Series defect on agilent 167xx boards?
<< < (23/50) > >>
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
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod