Series defect on agilent 167xx boards?

[MarkL]

Great!  And you're welcome!  It's challenging and fun troubleshooting this old technology.

I assume you saw some of the posts to upgrade your 16533A to a 16534A?

...
BTW, it looks the 9 ohm measurement on my board was the connection from the left 'B' to the middle 'B'.  I had 0 ohms from the middle 'B' to the right 'B'.  Weird...

Yeah, that's strange.  My probing showed it was a direct shot from the left B to the middle B.  Maybe the connectivity to the left trace inside the via is/was damaged by the corrosion on your board.

I'll look forward to your posts on the 16750B, and maybe the 16716A when you get to it.  The 16750B is a much more capable module, and can be upgraded to a 16752B, so you might not miss having a 16716A.  But then there's the nagging, "Well, I might be able to fix this..."

[DogP]

>I assume you saw some of the posts to upgrade your 16533A to a 16534A?
>can be upgraded to a 16752B, so you might not miss having a 16716A.
Yep, once I tested the cards unmodified (to make sure I knew the state they were in when I started), the first thing I did was "upgrade" all of them.

>But then there's the nagging, "Well, I might be able to fix this..."
Heh, that's exactly what I'm expecting will happen.  Though I don't even know the state of it right now... it could be completely trashed, or it might even be working.  The seller put "for parts", which could mean anything.


BTW, I did a quick search through some of the binaries for the wrap flag stuff, and it appears to be part of the Zoom FISOs.  There's a string "FISO wrap initially TRUE", "FISO Wrap Flag never went TRUE", and "Unable to Detect WRAP Flag" (which is what I'm getting)... all in the same vicinity of other Zoom strings.  So I think I'm sticking to the plan of mapping those pins as much as possible, and maybe trying to run my finger across the FPGA pins to see if I can cause one of the other FISO wrap flag errors (if it's floating, hopefully my finger will change its state).

DogP

[DogP]

Just figured I'd post this real quick... I ended up making an extension for these cards using some IDC connectors and a ribbon cable.  Pretty janky, but it seems to work.  I wanted to test it before laying out a PCB and waiting for it to arrive... then finding out it just doesn't work. :-P

So, if I get a few free minutes this week I plan to make an adapter to use two IDE cables, since they're readily available, and in lots of different lengths.  No idea how long of a cable will work, but it doesn't sound like the backplane has any really high speed signals, so hopefully reasonably long.  I just want enough that I can lay a board either side up on my bench.  If a long cable works, I guess you might be able to come all the way out the back.


Edit: I did some testing with it on my WRAP flag board... by putting my finger on/near some of the zoom chip pins, I was able to consistently get the WRAP flag message several times in a single zoom chip select test.  So, maybe the WRAP flag itself isn't the problem, but instead pins are floating when they shouldn't be (chip select, R/W pins, etc?).  I'll have to probe those chips some more.  And to confirm that was a valid test, I took my good board and put my finger on the same pins, and had no failures.

DogP

[DogP]

I put this together this morning, and have it on order... the same board can be used for both the backplane and card sides, just populate the connectors appropriately.  And from the 1:1 printout, it actually looks like it'll fit perfectly between slots, so I guess maybe you could use multiple to debug a master/slave configuration on the bench or something.

I'll post the gerbers once I receive and test the boards (next week hopefully?).

DogP

[DogP]

They FINALLY got around to shipping the 16716A, and it arrived today.  Overall, the card is pretty clean, and seems like it might be fairly new, since all of the adhesive strips peeled off in one piece (I used heat, of course).

From an initial look, there's not much corrosion, though the little bit that I do see seems to be at a few vias, particularly under the BGAs, which of course sucks.  But even those look pretty minor compared to the other boards I had corrosion on.  The nastier part is some goop that's stuck to the top of the board and on the cables... doesn't look corrosive or anything, but kinda sticky, like someone's kid got too close to it with a piece of butterscotch candy (probably more likely that it's something like a dried up glop of paste flux that someone spilled on it on their workbench).  So, I've got some cleanup to do, as well as taking a very close look at traces/vias/etc. under the microscope.

Anyway, I plugged it in, and it shows up in pv as "(0x2f) Unrecognized module".  Any ideas on what causes that?  Part of me wants to suspect bad solder joints on the 208-pin QFP near the backplane connector... past experience has been that large QFPs on large boards that flex easily is a recipe for solder joints to pop free.  And I'm guessing that's the chip that communicates to the host, so it seems plausible.  I didn't see any pins that looked to be lifted, but I plan to look more closely at that later as well.

Thanks,
DogP

[DogP]

I looked more closely at the 16716A... I definitely don't see any corroded traces, and the few vias that had signs of corrosion look to be very minor (after cleaning up the little bit of green, there's plenty of gold still showing).  I also took care of the glops of goo, which cleaned up well w/ alcohol.

The QFP pins on U64 seem to be OK... I checked them under the microscope, and poked at each pin w/ tips of tweezers, and they all seem solid.

I checked the LDO voltages, and I think they're OK based on calculating from the resistor values:
U63: 1.53V
U62: 2.14V
U2: -1.70V
U7: 3.33V

So... I think I've checked the simple stuff that comes to mind.  Any thoughts?


Also, since I got the cables (why I bought that card in the first place), I was able to test the 16750B card w/ the Timing Zoom problem... it appears to only be an issue communicating with the Timing Zoom chips.  I tested every channel in the regular logic analyzer mode, and they're all fine, but when I enable Timing Zoom, it'll sometimes throw errors about the WRAP flag, and looking at the waveform data, it's sometimes correct, sometimes not, and never aligned (e.g. I trigger the analyzer on the rising edge and see it at t=0, but the Timing Zoom waveform sometimes shows 0, sometimes shows 1, and never shows the edge).  Interestingly, even with a constant '1' on the line, the timing zoom still sometimes shows '0'... though I've never seen a '0' show as a '1'.

Thanks,
DogP

[MarkL]

Cool adapter!  Please post some photos when you get it built and try it out.

On the 16716A, there are some traces that run along the edge of the board that I've found are related to the board identification.  (On other models too).

The gray cable of course has to be installed.  It's also involved in board identification.

Attached is a photo of some severely damaged traces from a board that was not recognized.  This board had other problems, but once these traces were repaired I could at least run pv on it.  There are similar traces on the top side, but they were ok on this board.

I would suggest finding the endpoints of these traces and check continuity from end to end and look closely around the gray cable area.  Sometimes the corrosion gets under the soldermask and it's really hard to tell if a trace is good.  A very sharp set of probes is useful to pierce the soldermask along the way, or use homemade probes from sewing needles.  I have a set of Pomona 6275 probes with the stainless steel tips that I've sharpened to a very fine point with a hone.

Yes, that 208-pin QFP is the host interface.  It acts as an interface between the backplane bus and several on-board buses.  Board ID is done through one of the on-board buses.

On the 16750B, I think your finger poking test is a huge clue.  I would get a scope on those zoom chip pins and see what they look like with the chip select test looping.

Could you see any pattern to the zoom screen output?  Were any of the 68 inputs working at all?

[DogP]

>The gray cable of course has to be installed.  It's also involved in board identification.
LOL, thanks for pointing out the obvious... this board is missing the cable, and I was too busy looking for the corrosion that I didn't notice! Just swapped the cable from my other board and popped it in really quickly before leaving the house this AM, and it enumerated, and passed all self-tests!  So, it looks like I just need to track down (or build) one of those cables.

>I have a set of Pomona 6275 probes with the stainless steel tips that I've sharpened to a very fine point with a hone.
Yep, those are the exact probes I have as well, and what I've been using to scrape the soldermask (as well as poking through the soldermask to check continuity).

>Could you see any pattern to the zoom screen output?  Were any of the 68 inputs working at all?
The several I tested seemed to be partially working, but not fully working... though I need to test more tonight.  It would sometimes correctly show that the pin was '1' when the pin was tied high, and would never show '1' when not, so it seemed to be somewhat connected to reality.  But sometimes it'd show '0' when it was tied high as well, so it seems like more than just a time shift in the buffer.  I plan to hook up the sig gen tonight and put in a square wave to see if I can catch any edges in Timing Zoom.

Thanks,
DogP

[MarkL]

A further thought...

You could get more precise with a finger poke by using, say, a 1k resistor connected to a fine probe to pull up or pull down various pins on the zoom chips to see exactly which pin(s) is being sensitive.  The zoom chip appears to be a 3.3V part, or at least the bus interface is, so a pullup to 3.3V would be appropriate.

U91 (all sections) and U92 (pins 1, 2, 3) are 2 input ANDs, and one input of each section is connected to pin 29 on the U29 Altera FLEX.  The output of the 5 ANDs are each connected to one of the 5 zoom chips.  In addition, one databus trace is connected to the other side of each of the the ANDs.

So, the selection mechanism might be some kind of latched select depending on which databus trace is TRUE at the time.  Perhaps it's valid to select multiple zoom chips at the same time for some operations.  I didn't analyze it on a running system.

Without getting too crazy tracing everything at the moment, I would add to my suggestion to also poke the 1k at U91 and U92.  Sections [4,5,6] [10,9,8] and [13,12,11] of U92 appear to be unused and are left floating (which design-wise is not a good idea).

One added word of caution... I've managed to kill chips on these boards with sloppy probing by dragging a probe from one pin to the next, essentially shorting two adjacent pins together.  A couple of comparators met their demise because of this, but it could happen to any chip.

[DogP]

You could get more precise with a finger poke by using, say, a 1k resistor connected to a fine probe to pull up or pull down various pins on the zoom chips to see exactly which pin(s) is being sensitive.  The zoom chip appears to be a 3.3V part, or at least the bus interface is, so a pullup to 3.3V would be appropriate.

U91 (all sections) and U92 (pins 1, 2, 3) are 2 input ANDs, and one input of each section is connected to pin 29 on the U29 Altera FLEX.  The output of the 5 ANDs are each connected to one of the 5 zoom chips.  In addition, one databus trace is connected to the other side of each of the the ANDs.

So, the selection mechanism might be some kind of latched select depending on which databus trace is TRUE at the time.  Perhaps it's valid to select multiple zoom chips at the same time for some operations.  I didn't analyze it on a running system.

Without getting too crazy tracing everything at the moment, I would add to my suggestion to also poke the 1k at U91 and U92.  Sections [4,5,6] [10,9,8] and [13,12,11] of U92 appear to be unused and are left floating (which design-wise is not a good idea).

Thanks for the info... yes, I definitely plan to do a more precise "touch".  Though the interesting thing I guess I didn't mention is that I don't have to be physically touching the pins to induce the failure.  Just having my finger nearby, or even touching the top of the plastic chip can cause it.  Just a guess, but the chip might have a VCO running inside it to get the 2 GHz timing, and my finger nearby is coupling, inducing a signal on whatever pin(s) are floating... or maybe just added capacitance... or magic?

One added word of caution... I've managed to kill chips on these boards with sloppy probing by dragging a probe from one pin to the next, essentially shorting two adjacent pins together.  A couple of comparators met their demise because of this, but it could happen to any chip.

Yep, that's one reason I haven't done much probing yet... those are really fine pitch QFPs, not conducive to probing.  I plan to test as much as possible at the SO resistor networks, test points on the bottom of the board, vias, etc.  But I've got some mapping to do...

Thanks,
DogP

[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: [Select]

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)


Code: [Select]

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)

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: [Select]

#!/bin/sh

export PVRESULTLEVEL=10
export PVDEBUGLEVEL=9

(
  sleep 8

  echo "s e"

  while true; do
    echo "x zoomChipSelTest"
   
    sleep 3
  done

) | pv


[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

[MarkL]

Awesome sleuthing!

I can confirm it's 1GHz.

And you found a signal that does NOT appear on the bottom.  So now I have to say "almost all signals appear on the bottom".  I can understand why they didn't want any extra vias on that pair!

[DogP]

Success!  While I probably have other things I should be doing tonight, I don't have anything I'd rather be doing.   I swapped the SY89421V from my 16716A, booted it up, and it passes all self-tests, and the Timing Zoom signals show up correctly with the regular waveform.

As expected, it looks like the SY89421V is way obsolete.  Any chance you have a "parts" board you'd be willing to sell one off of?  Or, know where I could find one?  Digikey/Mouser don't have them anymore, and I didn't see any for sale on ebay or aliexpress.  I could probably hack together a replacement, but probably not worth the cost/effort of building a small carrier to do that.

Thanks for digging into those clock signals on the Zoom chips... I guess luckily for me I didn't need to trace them, but hopefully it'll help someone in the future.  And overall, thanks for sticking with me while I worked my way through these boards!  I'm really excited to start getting to use the machine.  Though I'm also excited to mess around with the pattern generator a bit, as well as writing some code for the TDK.

Thanks,
DogP

[DogP]

I can confirm it's 1GHz.

Haha... gotta rub it in with a screenshot from your awesome scope!

DogP

[MarkL]

Excellent!

It was fun following along and it gave me an excuse to do more tracing and post it.  Thanks for sharing the details of what you were doing.

I took a quick look, and from I can tell they used the SY89421VZC on all the zoom-capable 167xx boards, including the higher end 16753A/54A/55A/56A.  I have a bunch of dead boards and I can send you a PLL, no problem.  Send me a PM and we can work out the details.  Maybe you can email me a pre-paid USPS label and I can drop the chip (properly protected) in a flat rate envelope, or something like that.

[MarkL]

I can confirm it's 1GHz.

Haha... gotta rub it in with a screenshot from your awesome scope!

DogP

Of course I do.  But it's my limit.  I've resorted to the spectrum analyzer approach a few times too.  It makes a nice tunable voltmeter.

[MarkL]

So with your discovery of the 1GHz clock, what I was seeing on the CLK inputs to the 1NB4-5040 zoom capture chips was not making sense.  I couldn't figure out why they would go to the trouble of creating a 1GHz clock just to divide it down.  I assumed, wrongly, that each chip had its own PLL that somehow synced up to a slower incoming clock.  Not so.

My error was that I wasn't looking for a higher speed clock, so I didn't have the scope set up right to see it, and certainly not using appropriate probes.  The clocks run to read out the data, and that was not a surprise, but they also run at a much higher speed when capturing the samples.  And, as I found out, in zoomChipSelTest, the entire capture interval is much shorter than normal mode, on the order of 2.5us, and very easy to miss if you weren't looking for it in the test cycle of over a second.

So, instead of trying to observe the clocks with a looping zoomChipSelTest in pv, I set the module to repeat a data capture under normal operation.  And this time I used Tek P6245 1.5GHz active probes.  The 1GHz clock is at the limit of the scope and close to that of the probes, so everything looks like a sine anyway, and a wobbly one at that due to the sin(x)/x interpolation.  A much faster scope system is really needed to probe the CLK properly.  (And before anyone says it, yes, I should also use shorter grounds.)

Here are a couple of screen shots of the zoom clock inputs while capturing data.  As before, CLKA and CLKB are each a differential pair (zoom_clka+_clka-.png).  When capturing, CLKA and CLKB are duplicates with no phase offsets (zoom_clka+_clkb+.png).  The frequency changes with the inverse of the sample rate.  A sample period of 0.5ns (the fastest) runs the CLK at 1GHz, so the chip must be capturing samples on the rising and falling edges.

This is a guess, but maybe CLKA is for one half of the chip and CLKB is the other half. There appear to be two groups of 8 sample inputs and maybe they wanted the chip to be able to capture at different rates with 8-bit granularity in other instruments.

The last screen shot (zoom_capture_readout.png) is one cycle of capture and data download in normal operation mode.  The above 1GHz captures are taken during the first waveform interval in the beginning at the trigger marker.

Just puttin' it out there for comparison if anyone needs zoom clock info in the future.

[MarkL]

Since I had the probing set up, I went back and took a closer look at the operation of "zoomChipSelTest".

Here is the test being performed in pv with "d d=9 r=9":

   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" (380, 0, 1)

Below is the scope capture.  The top of the screen shows a zoomed out view of the first segment of the above test for "Slot E: Filling FISOs for Pods #1 with zeroes" through the beginning of "Slot E: Checking FISO #4".  The scope trigger was set on CLKB+ pulse width <10ns.

The bottom is zoomed into the first part of the segment.  What's shown is a short burst of about 156kHz, maybe doing some set up of registers in the zoom chip.  This is followed by 33.6us of the 1GHz clock being turned on, which would be the "filling with zeroes" part.  After the 1GHz clock burst, the clock resumes 156kHz to extract the data from the zoom chip.  This is repeated 4 times, once for each of the 4 pods in the test.  What I think is the nCS pin is only active for most of the data extraction part, so there's probably more to the zoom chip select and read/write that's not understood yet.  Maybe it's just a read select.

The sample data inputs change across all the chips before each of the above 4 steps.  I didn't do an exhaustive check of all 68 inputs, but in a few spot checks it appears pv sets up the comparators to generate zeroes for the current pod and the rest are set to ones.  It then does the capture, gets the captured data from all 5 zoom chips, and then presumably looks to make sure there are only zeroes on that one pod.

There is also a short 2.5us burst of 1GHz on the clock that precedes each test cycle (not shown) that was mentioned in the previous post, but I don't have a good guess what's happening there.

While probing this area, I was also able to see that the FISO numbering starts with #0 at U55 near the edge.  On a 16715A/16A it's in the same order starting with #0 at U8.  So, if a problem is reported on one zoom chip, you know which one it is now.

Again, just posting the info here for future debugging.  It's all guesswork.  Any additions/corrections/verification is welcome.


And a side note for all pv debugging: I found out somewhat by accident if you set "d r=10" for some operations, you get even more detail.  The help says "r=9" is the highest level needed, but this apparently is not true.  Makes me suspicious if there's anything more for even higher debug levels.  I didn't see any differences past 10, but who knows.

[DogP]

Very cool... great info as always!

BTW, my extension boards arrived, and they work!   Attached are some pics.

I tested with a pair of 17" long IDE cables, which are long enough to stick out the back of the chassis.  I used a 2-drive cable (cables I had nearby) - apparently the extra connector isn't hurting signal quality too much - it gives you a convenient place to probe for reverse engineering the backplane too.   I don't have any longer cables here, so I'm not sure what the limit is.

Somewhat surprisingly, it all fits as planned... the connectors tuck between backplane connectors, and doesn't block an adjacent slot.  And the cables plugged in at the card don't block access to components near the connector.  All of the connectors fit snugly, so they don't feel like they'll fall out, though I put a small screw hole in case you'd like to attach it.  Particularly, I was worried if you pull on the card when working on it, it might pop out of the socket.  So, I might 3D print a bracket to clamp over the rear connector on the card.

Maybe you could modify a filler panel and leave the cables hanging out the back for when you need to test a board outside the chassis... then you wouldn't need to remove the bottom, or even pull the unit out at all.  A 24" cable (or longer) might be helpful for that.  Or, maybe add a trap door in the bottom so you can pull the cable out the front, since presumably the front will be facing your workbench, and is probably the most convenient place for debugging a board.

Anyway, I'll post the gerbers, assembly notes, etc. to Github later tonight.  But if anyone (US shipping) wants a set, I've got some extras (I ordered 20 boards, since it was only a couple bucks more than 5)... just pay a few bucks for shipping.

DogP

[DogP]

Uploaded extension files to Github: https://github.com/pdaderko/16702B/tree/main/card_extension ...

DogP

[Hamster]

Repair log for two 1675X Cards...

Card # 1 Zoom/Comp Errors:

  Comparators Test running...
  ...Comparators Test ended. Result: Failed***

  ZoomChipSel Test running...
  ...ZoomChipSel Test ended. Result: Failed***

Image show area of repair: 1675X_COMP_ZOOM_ERROR

Card #2 Errors:

  Memory Data Bus Test running...
      Slot B, Data Failures, chip 1, bank 1, port 3, Mems U90, U87
   < Truncated >
  ...Memory Data Bus Test ended. Result: Failed***

  Dma Test running...
   < Truncated >
      Slot B, Chip 1: RAM Count Only Unload Test ...
      Slot B, Chip 1: Interleaved Data & Count Unload Test ...

      Slot B, Chip 1, SDRAM U71:
   < Truncated >
      Slot B, Chip 1: Interleaved Data & Count Unload Test Failed!
    > Slot B, Chip 1: DMA Unload Modes Test Failed!
      Slot B, Chip 1: Bad RAMs:  U71 Bad Data: 0x3FFF
  ...Dma Test ended. Result: Failed***

  Memory Sleep Mode Test running...
      Slot B, Chip 1, SDRAM U74:
      Slot B, Chip 1, SDRAM U71:
      Slot B, Chip 1: Bottom bank check failed before Sleep mode.
  ...Memory Sleep Mode Test ended. Result: Failed***

Image of areas of repair: 1675X_MEMORY_ERROR

--- Card # 2 had prior repairs with rails removed, the card had developed additional failures after sitting. ( Note, there were "Chips" in error, but the repairs were not even in the area or memory controller )