Arria 10: Remote Update may brick FPGA and Factory Fallback won't work

[FabianL]

Hello,

we have observed some critical failures when doing tests with various potential error scenarios concerning a remote Update of the FPGA bitstream in the attached SPI Flash device.

We could repeatedly trigger cases, when the FPGA internal fallbeck mechanism to the factory load does not work. We do not use any bitstream encryption.

Test scenarios:

1. Erased flash & partially programmed application load image --> Fallback mechanism works as expected
2. Invalid application load image location, i.e. start of application load is shifted by1-10 Byte (Manually induced error scenario) --> The reprogramming sequence starts but never completes and no fallback to the factory load is performed. => The FPGA is completely unresponsive unless programmed via JTAG

It is obvious, that the 2nd scenario might be a more exotic error scenario, however we require a robust setup and have to make sure, that the FPGA remains accessible under any circumstances, so we need the Factory Fallback mechanism to work reliable! 

As a best guess I could assume it might be related to this Note in 1.3.1. Remote System Configuration Mode that the factory fallback mechanism won't work for Arria 10  FPGAs if the last 576 Bytes of the bitstream are corrupted.

Note: The fallback to the factory image does not work under the following conditions: If the last 576 bytes of an unencrypted application image bitstream are corrupted. 

Intel recommends that you examine the last 576 bytes of the unencrypted application image before triggering the application image configuration.

But I have noticed that the binary images of the FPGA bitstream vary in size. So there is no way to check explicit memory locations for these 576 Bytes. Is there any way to identify this section?

My Questions:

1. Why is the factory configuration fallback mechanism not working in the above described scenario? The Factory load image is valid!
2. What method does intel recommend to reliable make the factory fallback mechanism work?
3. How can I examine/validate a FPGA bitstream in flash memory before executing it?

Thanks a lot for any help

Best regards

Fabian

[FabianL]

Hello,

is there any advise for this topic?

Thanks

Fabian

[FvM]

Hi,
did you try to enable configuration watchdog? Requires serving the watchdog in application design, of course.

Regards
Frank

[FabianL]

hi Frank,

Thanks for the hint. That actually helps to trigger the fallback to the Factory image.

However 2 questions remain:

1. Any idea why the regular CRC check is not causing a factory fallback?
2. Our application design is not actively serving the watchdog. We are using the Avalon IP "Remote Update Intel FPGA IP" Version 19.1.0. We do not set any of the Watchdog Registers in the application image, so I would have expected that the watchdog would trigger and cause a factory image fallback. But his is not happening. Instead the factory image fallback reliable works with an invalid image.

So please don't get my 2nd point wrong. This is exactly the behavior that I was asking for. But it is not what I expect from the datasheets and I would like to understand it before introducing this into production.

Thanks

best regards

Fabian