Are thermal effects on an FPGA different depending on how it is programmed/configured?

Question

I am currently on the fence in a debate regarding FPGA environmental testing (thermal cycling).

The question is, can the same FPGA stressed to the same thermal limits yield different results depending on how it is configured/programmed?

For example, data rates, data corruption, etc.

With something like a microcontroller I would say that regardless of how it is programmed the hardware remains the same, so its thermal properties will remain the same. FPGAs are a bit of a grey area, because although the configuration is described in code (i.e. HDL), it is creating a configuration in hardware within the FPGA.

Thoughts and opinions welcome, but if you have any relevant research papers or articles that would be great.

Thanks

Edit: To add a bit of clarity, I will be more specific about the use case. The under test is a system control unit, where the main processor is an i.MX6 Arm CPU, with the main signal processing unit being an IGLOO2 FPGA. There are two builds of software available for it:

1. Test control software, designed to stress it for design proving activities, but serves no purpose in the real world.
2. Operational software, the software that will be shipped with the item

The argument is that because the environmental stress testing has been performed with the TCS there is a gap in our proving evidence because thermal cycling has not been performed using the software which it will be shipped with. The testing is performed in an environmental chamber which cycles between -40C and +70C. The counter argument is that the TCS is inherently designed to excessively stress the item, therefore the operational software should be fine.

The third argument thrown in to the mix is that regardless of the build of software, the hardware is the same, so the effects of external thermal stimuli should be the same.

Edit 2: Clearly I'm still struggling to explain myself. The product was designed internally but is being manufactured by a contractor in another country. The main qualification testing (environmental and EMC) is being performed by the contractor, however we are unable to ship them the 'real' software as it is restricted and cannot leave the country. With that in mind, we provided the contractor with technical requirements such as thermal environment, bus speeds, and a 'sanitized' functional requirements which were designed to be representative but without breaking restrictions. With this, they created their own software (a.k.a the TCS). The question I am asking is if the code is functionally representative but simply 'not the same' as the software that will ship with the product, then how much of a gap do we really have in our evidence?

Answer 1

Sorry, but both a microcontroller and an FPGA will have different thermal behavior depending on how they are used. If you intend to do thermal cycling or life testing you must run the application software (or similar) on a microcontroller and apply the application configuration (or similar) to an FPGA.

You need to be careful to differentiate between the thermal properties (which depend only on the physical construction and packaging) and the thermal behavior (which depends on usage as well). For thermal cycling and life test you want to be sure that the die itself is as hot, and in the same places, as it will be in use.

EDIT: It sounds like your real problem is that you haven't convinced the customer that your "TCS" really is an overstress. If the customer remains skeptical then you have no choice but to run the actual application software. If you are trying to demonstrate something about reliability or failure rate, then running a test without application code (or demonstrably worse) is no test at all.

Answer 2

There's an old saying in the aerospace industry that goes along the line of "Test like you fly, and fly like you test". That means that when you're performing an acceptance test on a product as part of a sell off to your customer, you want the test environment/scenario to be as close as possible to what the unit will see in use. The only difference in testing vs use is that acceptance testing usually involves a slightly wider temperature range that what might be seen operationally, in order to weed out marginal devices.

So following this line of reasoning, you do NOT want to use a special TCS firmware/software load for your acceptance tests.

Edit 1 - To answer Op's questions

Not sure what you mean by the "evidential gap". But if you really want to stress the unit, just run it over a wider temperature range than what it expects to see operationally. Here's a contrived example. Say your unit is supposed to operate from 0C to 40C. At a minimum, every unit that's sold should be tested over (say) -5C to 45C. On a design verification (qualification) unit, you expand that temperature range even more, say running one unit over -15C to +60C.

The only reason I would do what you're suggesting - come with a test load for the FPGA to make it run hotter, is if your thermal analysis shows that the FPGA is the weak link - the part with the least amount of thermal margin, and other components may not survive the extended temperature range testing I mentioned above.

Answer 3

1. You can ask the TCS if retesting is required. I would recommend making an evaluation first (see item 3. below).
2. Thermal stress does depend on the FPGA code and how it is used.
   Your FPGA will run hotter if you are running it at 100MHz than when you are running it at 100kHz.
   Example: if you would have a big serial shift register in your FPGA and you feed it with a sequence of alternating ones and zeros at 100MHz, you can expect that it will be running hotter than when feeding it with all zeros.
3. You can evaluate the risk by measuring the temperature when running the program used for testing, and comparing that to running the application program under worst case conditions.
4. It all depends on whether you wanted to pass testing like Volkswagen did, or if you want to actually test your product and make sure it is safe and functional under all expected conditions. Even when using a typical application, it does depend on whether your device is actually doing hard work or not.
5. In the end you're still only testing a typical system - not one where all your components have worst case characteristics.