Is it possible to replace a FPGA chip?

[analogRF]

I am not very familiar with FPGAs and ASICs and all that stuff so here is my question:
I have a non-working Anritsu spectrum analyzer that after many hours of testing and measurements, everything points to a bad FPGA chip on the spectrum analyzer board. I find it very odd and i think it must be very rare but bad fpga chip is the only explanation at this point. I also have strong suspicion that at least one of the pins of the FPGA is shorted to ground. It is a BGA chip with no access to the pins from the backside but measuring some of logic ICs around the FPGA leads me to belibve at least one pin is shorted.
It could be a bad solder joint and perhaps a reflow can fix it and I will attempt to do that but my question is, can I replace the FPGA with a new one?

The instrument has a bootstrap mode at boot in which one can program the various FPGAs including the SPA_FPGA which is the one I am talking about. There is a .dat file inside the FPGA directory in unpacked firmware files which belongs to SPA_FPGA and interestingly its version is 1.16 which matches the version number on the sticker that is on the chip as well. So I think if I put in a fresh FPGA chip, I should be able to program it.

One odd thing is that this file is 155kB while the FPGA (ProASIC3 A3P125-FGG144) itself only has 1kbit of flash!!??

[coromonadalix]

normally with the proper tolls you can change any kind of ic's ... hot air station is a must with the corresponding dies for the chip you need to remove

I work with fpga, cpld's   etc ... with tons of pins / pitchs, sometimes we have shorts on the pins, we remove them and the ic is still fine,  sometimes it got defective and i have to remove it and put a new one and program it.

The BIG problem you'll get is :  even changing the damaged part, do you have the firmware or the code you need to put in it .... you seem to have it ? if the bootstrapping mode works with a blank fpga, you should be able to work it out, unless something kills the fpga or tie a pin down ??


The file difference with the memory space, i would not bother with that, if the file source is okay and genuine ...

[ataradov]

Where do you get 1 kbit information from? A3P125 has 125000 gates and 4.5 KByte of block ram. 155 kB bitstream is about fine here.

Whether you can replace it depends on how they boot this FPGA. If there is a binary, it may be a good sign, but still not a guarantee that it will work.

Have you looked at the file with a text or a binary editor? Can you post how the start of the file looks like?

[analogRF]

normally with the proper tolls you can change any kind of ic's ... hot air station is a must with the corresponding dies for the chip you need to remove

I work with fpga, cpld's   etc ... with tons of pins / pitchs, sometimes we have shorts on the pins, we remove them and the ic is still fine,  sometimes it got defective and i have to remove it and put a new one and program it.

The BIG problem you'll get is :  even changing the damaged part, do you have the firmware or the code you need to put in it .... you seem to have it ? if the bootstrapping mode works with a blank fpga, you should be able to work it out, unless something kills the fpga or tie a pin down ??


The file difference with the memory space, i would not bother with that, if the file source is okay and genuine ...

that's a bit of relief 
i know the difficulty with the BGA chip removal and intallation. I have done reflow before but never replacement, so this will be my first  fortunately it is fairly small and only 144 pins. The blank chip comes from digikey and of course it has solder balls.

my question was more about the programming issue. In bootstrap mode the unit allows for FPGA programming on various boards and the files
come with the firmware package so they are genuine. What i dont know is that if the process works with a blank FPGA chip or not. The process has no feedback, I mean, you press program FPGA and the unit just comes back after few minutes without saying whether it was successful or or not. It just shows what version of FPGA was before and after but the chip already seems to have V1.16 (on its sticker) and the one with firmware is also the same version. I am hoping/assuming that the programming will also work with a blank FPGA.

[analogRF]

Where do you get 1 kbit information from? A3P125 has 125000 gates and 4.5 KByte of block ram. 155 kB bitstream is about fine here.

Whether you can replace it depends on how they boot this FPGA. If there is a binary, it may be a good sign, but still not a guarantee that it will work.

Have you looked at the file with a text or a binary editor? Can you post how the start of the file looks like?

the datasheet says it has 1kbit flash rom. it does have 36kbit of ram though.

here is the start of the SPA_FPGA file that is included in the firmware package.

[ataradov]

This looks like a regular programming file right out of the designer. There is a good chance that it could just be programmed into a blank FPGA.

[dc101]

Regardless of where the bitstream is stored, the most concerning part of the datasheet is this paragraph:

ProASIC3 devices utilize a 128-bit flash-based lock and a separate AES key to provide the highest level of protection in the FPGA industry for intellectual property and configuration data. In addition, all FlashROM data in ProASIC3 devices can be encrypted prior to loading

Most modern FPGAs have the ability to support encrypted bitstreams. I have a couple of MIPS Malta development boards that use older Xilinx Virtex-II processors. The MIPS bitstream is encrypted with a key that is stored in volatile ram on the FPGA. If you were to replace the FPGA, the new FPGA would not be able to decrypt the bitstream unless you somehow knew the old key and programmed it into the new FPGA.

"Using High Security Features in Virtex-II Series FPGAs" https://www.xilinx.com/support/documentation/application_notes/xapp766.pdf

[analogRF]

Regardless of where the bitstream is stored, the most concerning part of the datasheet is this paragraph:

ProASIC3 devices utilize a 128-bit flash-based lock and a separate AES key to provide the highest level of protection in the FPGA industry for intellectual property and configuration data. In addition, all FlashROM data in ProASIC3 devices can be encrypted prior to loading

Most modern FPGAs have the ability to support encrypted bitstreams. I have a couple of MIPS Malta development boards that use older Xilinx Virtex-II processors. The MIPS bitstream is encrypted with a key that is stored in volatile ram on the FPGA. If you were to replace the FPGA, the new FPGA would not be able to decrypt the bitstream unless you somehow knew the old key and programmed it into the new FPGA.

"Using High Security Features in Virtex-II Series FPGAs" https://www.xilinx.com/support/documentation/application_notes/xapp766.pdf

yes, I saw that but I hardly think they used this feature. It just does not seem that sophisticated to me. beside where do they keep the key then? there is no battery back up anywhere on the board except an EEPROM which more than likely contains calibration data (it is sitting right next to a DAC) and even if the key is in that EEPROM, then so be it. On the main board the only use a coin battery for clock and nothing else. It does not power any NVRAM whatsoever. So even if there is a encryption key somewhere on the board, I am not gonna touch it anyway.

[analogRF]

ok, now that I am here and I am learning a bit about FPGA from you guys, here is a much more primitive and dumber question:
does the FPGA need to have a clock (like CPU) to start? I know it has a PLL on itself and has multiple clock circuits on itself and I know it will need clock to function "eventually" but what about the starting point? I mean can it "start up" its own clock? or it must be fed by a clock at the beginning?


you see,  there is a basic 10MHz reference clock on the board that all other LO frequencies will be locked to it and I am pretty sure the FPGA also gets its clock from that. However, after much reverse engineering, it is obvious that there is a CMOS switch that turns ON/OFF the VCC of the 10MHz oscillator (which will be the heart of the whole spectrum analyzer board) and I can only conclude that this switch must be controlled by one of the pins of the FPGA. I have checked every single available place on the board and it does not go anywhere and I think it must be under the FPGA

Now, my dilemma is that this switch remains off and so the 10MHz oscillator never comes online. Which for me it only makes sense if the FPGA is faulty. But let's say it was not faulty and the unit worked, then does that make sense that FPGA will have to start its own clock??

looks like a chicken and egg situation to me. You now know that I know nothing about FPGA, don't you

[dc101]

yes, I saw that but I hardly think they used this feature. It just does not seem that sophisticated to me. beside where do they keep the key then? there is no battery back up anywhere on the board except an EEPROM which more than likely contains calibration data (it is sitting right next to a DAC) and even if the key is in that EEPROM, then so be it. On the main board the only use a coin battery for clock and nothing else. It does not power any NVRAM whatsoever. So even if there is a encryption key somewhere on the board, I am not gonna touch it anyway.

Can you post the firmware or post a link to the model/firmware? Easiest way to tell would be to look at the entropy of the firmware. The way I understood the datasheet, for this particular fpga, the keys are stored in non-volatile memory. Sounds similar in theory to the secure enclave in ARM processors like NXP's iMX series.

[dc101]

ok, now that I am here and I am learning a bit about FPGA from you guys, here is a much more primitive and dumber question:
does the FPGA need to have a clock (like CPU) to start? I know it has a PLL on itself and has multiple clock circuits on itself and I know it will need clock to function "eventually" but what about the starting point? I mean can it "start up" its own clock? or it must be fed by a clock at the beginning?


you see,  there is a basic 10MHz reference clock on the board that all other LO frequencies will be locked to it and I am pretty sure the FPGA also gets its clock from that. However, after much reverse engineering, it is obvious that there is a CMOS switch that turns ON/OFF the VCC of the 10MHz oscillator (which will be the heart of the whole spectrum analyzer board) and I can only conclude that this switch must be controlled by one of the pins of the FPGA. I have checked every single available place on the board and it does not go anywhere and I think it must be under the FPGA

Now, my dilemma is that this switch remains off and so the 10MHz oscillator never comes online. Which for me it only makes sense if the FPGA is faulty. But let's say it was not faulty and the unit worked, then does that make sense that FPGA will have to start its own clock??

looks like a chicken and egg situation to me. You now know that I know nothing about FPGA, don't you

I would assume most FPGAs would require a clock signal before they can do anything, but the datasheet references something called "instant on" (https://www.microsemi.com/product-directory/low-power/4881-instant-on) which looks like maybe it could be used to turn something else on? It's hard to tell, the datasheet and website are pretty vague.

[analogRF]

this is the file from the firmware package that is called SPA_FPGA and when the firmware "programs" the FPGA on the spectrum analyzer board, it is using this file here.

[analogRF]

yes, I saw that but I hardly think they used this feature. It just does not seem that sophisticated to me. beside where do they keep the key then? there is no battery back up anywhere on the board except an EEPROM which more than likely contains calibration data (it is sitting right next to a DAC) and even if the key is in that EEPROM, then so be it. On the main board the only use a coin battery for clock and nothing else. It does not power any NVRAM whatsoever. So even if there is a encryption key somewhere on the board, I am not gonna touch it anyway.

Can you post the firmware or post a link to the model/firmware? Easiest way to tell would be to look at the entropy of the firmware. The way I understood the datasheet, for this particular fpga, the keys are stored in non-volatile memory. Sounds similar in theory to the secure enclave in ARM processors like NXP's iMX series.

NVRAM where? Can't be on the FPGA chip itself. If there is a key somewhere in an eeprom then why should I care? when I ask the device to program the FPGA it will use that key (if it indeed exists at all) to encrypt or decrypt the FPGA code that is in the firmware package

[amyk]

The entropy on that file is too high for a regular bitstream. Of course, it could just be some sort of obfuscatory "encryption" that they added, and not a per-device unique key. Hard to tell without doing some really hardcore RE.

[analogRF]

I would assume most FPGAs would require a clock signal before they can do anything, but the datasheet references something called "instant on" (https://www.microsemi.com/product-directory/low-power/4881-instant-on) which looks like maybe it could be used to turn something else on? It's hard to tell, the datasheet and website are pretty vague.

yes, that's my big question. Is it supposed to start before it has its own clock and then start the 10MHz REF? I have looked everywhere and that 10MHz REF supply voltage switch does not go anywhere and has to be connected to a pin on FPGA. There is a ribbon cable that comes in from the CPU board and I have traced all of its pins that do not go to the FPGA and none of them controls the 10MHz REF supply switch. There are whole lot of other pins on that ribbon cable that do not go anywhere so i assume they must also go to the FPGA. of course the JTAG interface (or whatever interface is needed for programming it) must be among them

[dc101]

The entropy on that file is too high for a regular bitstream. Of course, it could just be some sort of obfuscatory "encryption" that they added, and not a per-device unique key. Hard to tell without doing some really hardcore RE.

I would agree, it could either be encryption or compression. I downloaded Microsemi's Libero IDE to attempt to compile an example bitstream for comparison, but unfortunately it requires a license and there is no free/lite version.

I did find this rather interesting article regarding the ProASIC3 https://link.springer.com/content/pdf/10.1007%2F978-3-642-33027-8_2.pdf
So in theory, it's possible to recover the encryption key, assuming the FPGA works enough to talk JTAG.

[ataradov]

FPGAs go no need an external clock to start. They use internal clock for configuration. After that is done, it is up to the user if the design even needs a clock.

But most practical design would need the clock, of course. So if you don't see any sort of clock going into the FPGA, then it may have configured, but the actual user design can't run.

[jklasdf]

If I had to guess, it's unlikely they would have used the encryption feature of the FPGA, especially if you were able to supply an FPGA programming file somewhere. That doesn't necessarily mean though that whatever file you found is in a format directly usable by the Actel/Microsemi (/now Microchip) tools directly, but may a file that they use to program the FPGA in system. Note that the 1Kb of flash in the datasheet refers to the amount of *user* flash available on the FPGA. This is completely separate from the configuration flash (much larger), and can be used to store stuff like a board ID or calibration or version information. The configuration flash cells are used to control the configuration of the FPGA directly (it is not like FPGAs where the configuration is loaded from flash into SRAM cells first), and that is what the "live at power on" stuff is referring to. A major market for FPGAs is space, where the live at power on is important, and the flash cells directly controlling the configuration is more resistant to single-event upsets than SRAM cells.

It is possible that the FPGA configuration can drive some pins to start up some external clock source (without requiring a clock source first). At some point though, most likely the FPGA requires a clock to do whatever job it was meant to do in the system.

[jklasdf]

Also for what it's worth, even if they are using the FPGA's encryption feature, there is apparently a backdoor to access the keys on these FPGAs: https://www.researchgate.net/publication/260327656_Breakthrough_Silicon_Scanning_Discovers_Backdoor_in_Military_Chip