Configuration CRC check (Arria V GX)

[mtwieghr]

This is related to my other thread. Much of the background info is the same, but I thought separate threads would help avoid confusion.

Our design (5AGXMB3G4) has a Nios II with an EPCS controller (altera_avalon_epcs_flash_controller) to interface to our configuration device (MT25QL256, using AS x1). Using quartus standard 18.1.1

We have noticed that the configuration in flash becomes corrupted over time. If we "examine" the flash with the quartus programmer, and compare the resulting jic file against the original jic used to program the flash, we generally see that the differences are very sparse, usually a few groups of four bytes set to zero near the start of the image. I've attached a screenshot where the diffs are highlighted (this is all the diffs in the entire 256Mb file).

We are investigating the reason for the corruption, but I also had questions about the behavior of the FPGAs when the configuration is corrupt. Depending on what specific parts of the configuration are cleared, we observe two different results:

Case 1: CONF_DONE stays low, nSTATUS repeatedly pulses low.

Case 2: CONF_DONE and nSTATUS release high, as if it is in user mode. But the FPGA is clearly not functioning properly. Not responding to or generating any IO signals.

So my first question is: how is case 2 possible? I was under the impression that the entire configuration bitstream is checked via CRC, so it should not enter user mode. Unfortunately, the INIT_DONE and CRC_ERROR pins are used for other functions so I can't easily use those signals to troubleshoot.

Another observation we made is that in case 1, JTAG can be used to recover the flash easily. However in case 2, JTAG does not function (the JTAG chain debug tool reports "Error: JTAG problem detected" and "Error: no device detected").

So my second question is: how is it that the (mis)configuration of the FPGA can cause JTAG to not function? After a lot of searching, the only mechanism I can find that could explain this is the Design Security Feature, but this sounds quite far fetched. I've verified that all supply voltages remain normal in all scenarios. If I hold nCONFIG low, I can detect the JTAG chain normally again. So it's not a hardware issue.

[mtwieghr]

Would it be possible to at least get a response on either of these topics?

I read through AN 357, and it says the following:

There are two CRC error checks. One always during configuration and a second optional CRC error check that runs in the background in user mode. This document discusses the user mode CRC error detection feature.

I'm interested in the "during configuration" CRC check, but I'm unable to find any conclusive details on its operation. Most documentation does not clearly distinguish between these two types of CRC checks, making it impossible to tell which one it's referring to.

Here's some more specific questions I've been unable to answer by reading the documentation:

1. Does the "during configuration" CRC check happen no matter what, or does it require certain conditions to be met in the hardware or in the configuration itself?

2. Does the "during configuration" CRC check have anything to do with the CRC_ERROR pin? Does the CRC_ERROR pin function need to be enabled for this CRC check to work?

3. What content is actually checked? In our application the flash contains both the FPGA configuration and Nios II code, and we observe that the Nios II code can be modified independently of the FPGA configuration. So clearly the FPGA and Nios II code aren't covered by a single CRC. Does each have its own CRC? Or is the Nios II code not checked at all?

[Fakhrul]

Hi mtwieghr,

Sorry for the delay, but I will try to adress your questions as below:

1-Does the configuration CRC check always happen during FPGA configuration?

Yes, the CRC check is always performed during configuration.

2-Is the CRC_ERROR pin required for this CRC check to work?

No, the CRC_ERROR pin is only for externally indicating errors.

The CRC check still happens internally even if this pin is unused.

3-What content is actually checked by this CRC?

Only the FPGA configuration bitstream is checked.

Other data in flash (e.g., Nios II code) is not part of this CRC check.

You may also refer to Arria V Device Handbook as reference.

Regards,

Fakhrul

[mtwieghr]

Hi Fakhrul, thanks for the response.

Based on what you said, I suppose the corrupted parts of the configuration shown in my first post must all be in the Nios, not the FPGA, since it wasn't caught by the CRC check.

I'd like to do some testing to verify that corrupting the FPGA image is caught by the CRC check. How do I know which part of the jic/flash memory corresponds to the FPGA bitstream?

Is there any recommendation for detecting corruption of the Nios code on the flash? Can this be done by the Nios bootloader?

[Fakhrul]

Hi mtwieghr,

To locate the FPGA bitstream in flash, you can try refer to the .map file generated with the .jic, it shows where each component (SOF,etc) is placed.

From my understanding, the corruption detection for Nios code isn’t handled by FPGA crc. If needed, you can implement a simple checksum or CRC check in the Nios bootloader to validate integrity before jumping to the app. You can try check this document as example/reference:

Nios II Custom Instruction User Guide.

Hope this helps.

Regards,

Fakhrul