Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20644 Discussions

Using CRC detection with standalone FPGA

Altera_Forum
Honored Contributor II
1,209 Views

Hello, 

I'm planning a board with a standalone Stratis II FPGA. Since I have no external CPU on the board, I plan to use a EPCS device to configure the FPGA in AS mode.  

 

I want to employ the run-time CRC detection feature of the Stratix II FPGA. However, when CRC fails the FPGA raises its CRC_ERROR pin and ... then what ?  

Is there an elegant connection scheme to make the FPGA re-start its own configuration by AS from the EPCS if CRC_ERROR happened ? Or should I use a Max II with Flash memory instead of the EPCS ? 

 

Thanks in advance
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
442 Views

I think, that a re-configuration could be achived with simple logic, e.g. generating an nconfig pulse on a crcerror rising edge, if this solution would meet your requirements.

0 Kudos
Altera_Forum
Honored Contributor II
442 Views

 

--- Quote Start ---  

I think, that a re-configuration could be achived with simple logic, e.g. generating an nconfig pulse on a crcerror rising edge, if this solution would meet your requirements. 

--- Quote End ---  

 

 

Where do you recommend to place this logic ? In the FPGA itself ? 

Usually nConfig goes from the configuration device to the FPGA. In what manner is it safe to connect another logic line to it ?
0 Kudos
Altera_Forum
Honored Contributor II
442 Views

The usage of NCONFIG depends on the configuration scheme. For AS, as you requested it can trigger a reconfiguration, it has to be connected to an open drain driver. You'll find all necesssary detail in the Configuration Handbook or the respective FPGA documentation. 

 

It may be possible to use internal logic also to connect CRC_ERROR to NCONFIG, although I imagined external logic primarly.
0 Kudos
Altera_Forum
Honored Contributor II
442 Views

So you recommend an external open-drain logic, something like an open-drain buffer fed from '0' connected to nCONFIG, with CRC_ERROR serving as its enable with a pulldown ? 

This way when CRC_ERROR is: 

* 'Z' during FPGA configuration and initialization: pulldown makes driver disabled and nConfig isn't affected 

* '0' when everything is normal during operation: same as above 

* '1' when an error is detected: the buffer is enabled and transfers '0' to nCONFIG, which triggers FPGA reconfig, which in turn makes CRC_ERROR 'Z' again and closes the buffer. 

 

Sounds reasonable ?
0 Kudos
Altera_Forum
Honored Contributor II
442 Views

From the information given in the device handbook, a pull-down resistor at CRC_ERROR output should assure, that the output is high only in case of CRC error, so an open drain inverter is needed to connect it to NCONFIG, however you realize it.

0 Kudos
Altera_Forum
Honored Contributor II
442 Views

Assuming you still trust the logic in the FPGA after the CRC is detected. 

 

What about using the ALTREMOTE_UPDATE MegaWizard to request a reload?
0 Kudos
Altera_Forum
Honored Contributor II
442 Views

May refer to 'Restart on Error detection ' options

0 Kudos
Reply