Understood. I left my runners off, and I dislike conformal coatings passionately. Time will tell if I'm wrong.
On the 16534A card again...
Besides the previous question on the self-test, are the cal errors associated with one channel or both?
You can probe two cards at the same time by using a 16701B expansion chassis, or a home-made card extender. User DogP has some gerbers available for an extender that works well:
...
Besides the previous question on the self-test, are the cal errors associated with one channel or both?
Both. I just removed the runners from the failing board.
It still works (both channels) connected to my Siglent function generator. I tried a variety of waveforms and pulsing. All worked. Maybe slightly noisier than the fully working one.
I just re-ran calibration and didn't get the previously mentioned 'whoa this board has issues are you sure you want to continue' message and this time Trigger Delay passed but ADC, Gain and Offset still fail on both channels.
Same calibration T cable works fine on the other card.
QuoteYou can probe two cards at the same time by using a 16701B expansion chassis, or a home-made card extender. User DogP has some gerbers available for an extender that works well:I'd seen this before. I assume by "two cards at same time" one is via removing the unit cover.
I'd like a 16701B. One of my units came with the cable to connect. They're stupid expensive. Max I'd pay is $50 and it would need to be local.
I'm parting out a couple of 16700Bs. I think one has opt-003. I've had zero luck selling them for $100. Just mentioning it in case anyone wants any parts (for spares). I'll probably keep the boards from one for spares for my 16702B. I also have a 16702B that will be for sale (two logic cards (low end) with original runners replaced, all cables/pods, optional pattern gen card) if anyone is interested.
Well, the trick is to get two cards powered up at the same time, and depending on the problem, configuring them the same or start them looping on the same test. Sounds like you have enough chassis to do it.
Wow, another dead PLL. Can you see any clock output from the dead one?
The PLL can be had on any of the 167xx cards with Timing Zoom except the 16715A. It might help to know your country for anyone who can scrounge up a PLL.
It's really better to check continuity via to via on all the traces running through or near corroded areas. Extremely sharp probes pushed into the via holes at an angle works well. On multiple occasions I've had traces with no visible breaks and it turned out the corrosion had gotten under the soldermask. It can take some time to do the testing. But you're right, it could also have eaten away the via hole plating, and that's happened to me too.
The HP-UX based analyzers are able to turn on detailed debugging output when running any of the verification tests (pv). Is there any more detail from the windows version on which bit(s) and/or chips are failing during "Memory Unload Modes Test"?
On the 1675x cards I think the acquisition memory access path from the backplane is through one of the FPGAs near the backplane connector (I think it's the Altera MAX), up to the Virtex FPGAs on top, and then back down to the actual DRAM chips. On the 1671x cards, it goes direct from the backplane controller FPGA to the memory chips (there are no Virtex FPGAs acting as a memory controller layer).
I'm in the US for anyone that might have a donor PLL board.
Yes, I probably need to get some better sharp probes for my DMM. I have fluke probes, but they have really crappy (worn) tips. I also have the push-on finer probe tip adapters that go over regular fluke probes - they're not exactly the sharpest, but they do poke through the solder mask on the vias with some prodding - having some nice sharp probes would be a nice upgrade though.
Yes, on the windows analyzer, you can turn up the verbosity of the self tests to 9, which I think is equivalent to the max verbosity you can set in pv as well. I don't remember exactly now what the error is, but it's either a consistent byte missing, or a consistent word missing. I also seem to recall getting different results running the tests in order from the beginning to the unload test, vs running some tests after the unload test and then going back to the unload test. It still fails in the same way, but it seems to fail for a lot more data values if I come back to the unload mode test after running other tests further down - maybe it's just because of what data has been left in the memory from the other tests.
It is interesting to me that the memory address and data bus tests pass, so all of the paths from the memory controller FPGAs to the DRAMs are good, but a consistent failing byte or 2 bytes in the unload test sounds like a control signal problem between the memory controller FPGAs and the back plane CPLD/FPGA (whatever it is)
...
Hmmm... I could be wrong about the testing path, or maybe only some of the signals are routed through the Virtex. I'll have to take a closer look at that.
Looking at replacement cables, the long run is lossy coax, measuring 178R for 135CM, so about 130R/meter. Given the 90K on the tip, lossless coax probably isn't going to make too much difference to the levels.
(Samtec can't provide lossy)
...
I had been reverse engineering the card recently and spent many hours producing a kicad schematic and testing the card on a bus extension.
A few pictures for fans of corrosion
Looks like a 16710A/11A/12A?
Are you going to attempt repair?
Mod A: TEST passed # "testEPLDpath" (1, 0, 1)
Mod A: TEST passed # "testLoadFPGA" (1, 0, 1)
Mod A: TEST passed # "testCableDetect" (1, 0, 1)
Mod A: TEST passed # "testFPGARegs" (1, 0, 1)
Mod A: TEST passed # "testChipRegsChip0" (1, 0, 1)
Mod A: TEST passed # "testChipRegsChip1" (1, 0, 1)
Mod A: TEST passed # "testChipRegsChip2" (1, 0, 1)
Mod A: TEST passed # "testChipRegsChip3" (1, 0, 1)
Mod A: TEST passed # "testChipRegsChip4" (1, 0, 1)
Mod A: TEST passed # "testChipRegsChip5" (1, 0, 1)
Mod A: TEST passed # "testZCal" (1, 0, 1)
Mod A: TEST passed # "testAdCntrs" (1, 0, 1)
Mod A: TEST passed # "testAdCntrRecords" (1, 0, 1)
Mod A: TEST passed # "testChipStateClocks" (1, 0, 1)
Mod A: TEST passed # "testChipTimingClocks" (1, 0, 1)
Mod A: TEST passed # "testChipCal" (1, 0, 1)
Mod A: TEST passed # "testMemsDataLines" (1, 0, 1)
Mod A: TEST passed # "testMemsWalkingOnes" (1, 0, 1)
Mod A: TEST passed # "testMemsAdrsLines" (1, 0, 1)
Mod A: TEST passed # "testMemsFullMeas" (1, 0, 1)
Mod A: TEST passed # "testRecordFlags" (1, 0, 1)
Mod A: TEST passed # "testOscillator" (1, 0, 1)
Mod A: TEST passed # "testComparators" (1, 0, 1)
Mod A: TEST passed # "testI2Csimple" (1, 0, 1)
Mod A: TEST passed # "testResources" (1, 0, 1)
Mod A: TEST passed # "testOtherPsyncs" (1, 0, 1)
Mod A: TEST passed # "testArmsTrigs" (1, 0, 1)
Mod A: TEST passed # "testEncoders" (1, 0, 1)
Mod A: TEST passed # "testHiSpeedMACs" (1, 0, 1)
Mod A: TEST passed # "testMemoryCal" (1, 0, 1)
i have a bunch of these older 167** cards that have failed, i gave up on them, i have since moved onto 169xx cards
...
i have a bunch of these older 167** cards that have failed, i gave up on them, i have since moved onto 169xx cards
i have a bunch of these older 167** cards that have failed, i gave up on them, i have since moved onto 169xx cards
Any chance you're looking to part with one of the dead 167** cards? I have a 16751B with a bad comparator IC and bad pod cables, waiting for a card to pull parts from.