On the 16555D card, I wouldn't bother trying to get it to work in a pair with the good card until you figure out what's wrong with it in the stand-alone configuration. Please post the pv results for the bad card by itself, both the summary of all tests, and then the first test that failed with debug options turned on. There might be clues there.
On the 16720A, I don't have much experience troubleshooting that card since mine has always worked. I agree that it could be the FPGA (the Altera MAX), but there's plenty of other possibilities surrounding it that could be preventing the loopback from working. Given that some of the other tests are actually passing, I wouldn't be inclined to suspect it right away.
I think I would try to figure out exactly what the system is doing during the loopback test. The manual says it's trying to write a pattern to memory and read it back. The first set of debug output implies it is doing byte read/writes. The only memory I see on the board is the Micron SDRAM (48LC4M16A2) and there are 8 of them.
I would try to find which SDRAM chip(s) it's trying to read/write to by looking at the write enable pins on each. If you have enough probing capability, you could even try to figure out the data pattern that's being attempted (looks like it might be 0x00, 0x55, 0xff, 0xaa from your diagnostic output).
The manual says 6 of these chips are used for data, so I'm guessing the other 2 might be used for sequence control, and probably it's the two nearer the clock circuitry which would be U121 and U117. It's only a guess, but you could start your probing with those 2 since the errors being reported are only byte sized.
Another technique to try to localize where the errors are coming from is to lift legs on chips, particularly the memory chips, and correlate it to what new errors start appearing. Useful signals for this test would be chip select, write enable, and a data I/O line or two (not all at the same time). This might be a good option, considering how long the loopback test runs (at least couple of minutes on my system).
A similar technique is to hold down various signals with a 50ohm or smaller resistor. The size resistor can be determined by watching on a scope to make sure you've ruined the switching levels enough to cause an error.
Also note the large number of LVTH245 chips. My guess is that they are probably controlling access for each memory chip to a common bus, which is how the memory is read and written by the system. Perhaps lifting a leg or two on these could induce interesting errors that might correlate to the loopback errors. Maybe one of these is sick, but it depends on how they've laid out the memory addressing.
It's not easy debugging these cards with no schematics and no documentation for the debugging output, especially if you don't have a working card to compare with. Sometimes it's just easier to buy another card.