We have had some instances where programming an FPGA appears to kill the FPGA.
For instance, we had two boards that has a Cyclone III and wouldn't program because Quartus said it couldn't access the JTAG chain. We measured low resistance on the programming header. Then we removed the FPGAs and found that the low resistance was gone. Then we replaced the FPGAs and the low resistance was still gone. However, the first one I tried to program came up with the same error and the programming header had low resistance again (6 ohms on the TMS signal). The second one programmed properly.
We are using the power supplies on the board to power and they look clean.
We are using an Altera USB blaster to program.
Unfortunately I didn't measure for low resistance right after powering the board and before programming but I will after we replace the Cyclone III again.
What in the process of powering and programming the board could kill some FPGAs but not others?
May i know if:
 The board is a custom board built by your company?
 Have you program the newly replace FPGA with the same image? Are you able to program it? If able, does it work as intended?
This is a custom board that one of our customers designed and initially tested. We manufacture, program and test these units. Then ship them finished units. We have been making these for years and have come across this problem in the past but haven't had a chance to look into it until recently. We still have plenty of success but want to increase the yield.
We only have one image to put on the FPGA and when I tried Quartus told me that it couldn't access the JTAG chain. So I wasn't able to load the image and the FPGA does nothing.
Yes i understand. It looks like the issue is that the pin is having issue after programming via JTAG and it is happening on some board only.
Have you check the signal integrity on the board? Is there any issue affecting the pin on the board? Have you tried with another piece of USB Blaster on the failure board?
What do you mean by checking the signal integrity of the board? Are there particular signals that I should look at because there are a lot of signals on the FPGA?
I don't have another USB blaster to try but I am able to program other boards including the board I mentioned that was previously dead and now operates fine.
Yes, since the issue is due to programming issue. What i am suggesting is look at the signal pin from the 10-header which the USB Blaster is connecting to. And see if there is any signal integrity issue on it?