Do MaxII devices verify flash contents before configuring at power on?

[Altera_Forum]

In FMEA analysis of a board using a MaxII CPLD the question came up, do the MaxII devices perform some kind of CRC or checksum check on the configuration flash (CFM) contents before configuration? In other words, what happens if the CFM gets corrupted? 

 I couldn't find anything about this in the MaxII Device handbook.

[Altera_Forum]

You could answer ALTERA via a service request (I'm interested in the response too ;-) ). From my experience (our materials are under 14 MeV neutrons and high energies gamma beams), it seems that when the CFM is corrupted, the MAX should be reprogrammed to recover. 

But in 5 years, I saw that only once... And the CFM is much immune than an external CFI Spansion (storing the FPGA firmware).

[Altera_Forum]

--- Quote Start ---  You could answer ALTERA via a service request (I'm interested in the response too ;-) ). From my experience (our materials are under 14 MeV neutrons and high energies gamma beams), it seems that when the CFM is corrupted, the MAX should be reprogrammed to recover.  --- Quote End ---   If the configuration consistency is checked, I would expect MAX II staying in unconfigured state (all pins tri-stated with weak pull-up), otherwise it might show arbitrary erroneous behaviour. Did you remember the behaviour in this single evident?  I agree, that only Altera can answer the question fully.

[Altera_Forum]

--- Quote Start ---  You could answer ALTERA via a service request (I'm interested in the response too ;-) ).  --- Quote End ---    We'll see, I made a service request.  Regarding FPGAs, at least Cyclone III documentation seems to indicate there is some kind of error checking during configuration but again the details aren't included.

[Altera_Forum]

--- Quote Start ---  If the configuration consistency is checked, I would expect MAX II staying in unconfigured state (all pins tri-stated with weak pull-up), otherwise it might show arbitrary erroneous behaviour. Did you remember the behaviour in this single evident?  --- Quote End ---    For me, the MAX was not in HZ state with weak pull-up (as it is during configuration by Blaster), because some of its IOs driving LED or ON/OFF of board power supplies were in relevant state. But the configuration of the FPGA by the MAX PFL was failing, even after OFF/ON of the board.  Usually, the external CFI FLASH containing FPGA firmware pages is corrupted, but in this case the only way to recover was to reconfigure the CPLD CFM.    --- Quote Start ---  Regarding FPGAs, at least Cyclone III documentation seems to indicate there is some kind of error checking during configuration but again the details aren't included.  --- Quote End ---    You could find some intersting litterature about SEU mitigation in this ALTERA documents : http://www.altera.com/literature/wp/wp-01135-stxv-seu-mitigation.pdf http://www.altera.com/literature/wp/wp-01135-stxv-seu-mitigation.pdf  you could also find more docs on the ALTERA website with the "SEU mitigation" search keywords ;-)

[Altera_Forum]

--- Quote Start ---  For me, the MAX was not in HZ state with weak pull-up (as it is during configuration by Blaster), because some of its IOs driving LED or ON/OFF of board power supplies were in relevant state. But the configuration of the FPGA by the MAX PFL was failing, even after OFF/ON of the board.  --- Quote End ---   If MAX II wasn't defective (worked again after reprogramming), the observation indicates that there's no effective configuration consistency check implemented. The configuration bitstream CRC check would prevent a Cyclone FPGA from entering user mode (within the reliability of the respective CRC length).