FPGA Configuration Troubleshooter

You can use this troubleshooter to help your FPGA configuration attempt. While this troubleshooter does not cover every possible case, it does identify a majority of problems encountered during configuration. This troubleshooter can be supplemented with Intel® FPGA's Knowledge Database to help you identify and fix your configuration problem.

What is your configuration issue?

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation.

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
For direct EPCS programming through AS programming cable, check the power supply of the programming cable and the interface to the EPCS device. The Quartus® II programmer will not be able to read/write any information from/to the EPCS device if the power supply or the interface is not stable.

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The EPCS density (e.g. EPCS64 or EPCS128) that you were using when this issue was encountered

    A description of when the failure started to happen and the failure symptoms. For example, the EPCS programming started to fail at the beginning/at the end of the programming cycle.

    A screen shot of nCS, DCLK and ASDO signals probed at the FPGA end

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct MSEL setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    All the timing specifications are met

    The supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA or reprogram and verify the flash using the new programming file The latest Quartus II software might have the bug fix
Check the signal integrity of the DCLK and DATA line/bus signals Noise at the lines/buses will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects configuration error and pulls the nSTATUS pin low
Enable the INIT_DONE option in the Quartus II software and check on the INIT_DONE pin to ensure the device exits the initialization stage If INIT_DONE remains low after the CONF_DONE pin is released high, the device fails to exit the initialization stage. If the CLKUSR option is enabled, ensure sufficient clock cycles have been provided through the CLKUSR pin as stated in the device handbook, otherwise the device will fail to exit initialization stage. If INIT_DONE goes high after the CONF_DONE pin is released high, the device has successfully entered user mode.

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

    The nCE, nCONFIG, nSTATUS CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file. The latest Quartus II software might have the bug fix.
Check the signal integrity of the dedicated JTAG signals Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure the nCONFIG and nSTATUS pins have been released high before the auto-detect or program instruction is executed in the Quartus II programmer If the nCONFIG and nSTATUS pins are not released high, the device is still in reset state or the device is not powered up properly. Therefore the device is not ready to receive any JTAG instruction including the silicon ID check instruction
Check the contact of the programming cable to the target device If the connection in between the programming cable and the target device is not stable, the signal/data corruption in between both devices will cause the FPGA fail to receive the valid JTAG instruction from the host

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Which configuration scheme that you are using?

 

Passive Serial (PS)

    Checklist

    Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct PS setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

    Debug Strategies

    The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

    Strategy Implications Enable the INIT_DONE option in the Quartus® II software, and check on the INIT_DONE pin to ensure the device exits the initialization stage If INIT_DONE remains low after the CONF_DONE pin is released high, the device fails to exit the initialization stage. If the CLRUSR option is enabled, ensure sufficient clock cycles have been provided through the CLKUSR pin as stated in the device handbook, otherwise the device will fail to exit initialization stage. If INIT_DONE goes high after the CONF_DONE pin is released high, the device has successfully entered user mode. If CONF_DONE doesn't go high, probe at the DCLK and DATA signals. Observe both signals after the start button is clicked on the Quartus II programmer If both signals remain low, then the program instruction has not been issued to the FPGA properly.

    If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

     

JTAG

  • Checklist
  • Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.
  • MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

    The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are tied to pull-up/pull-down resistors according to the recommended setup in the device handbook

    The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

  • Debug Strategies
  • The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.
  • Strategy Implications Enable the INIT_DONE option in the Quartus® II software and check on the INIT_DONE pin to ensure the device exits the initialization stage If INIT_DONE remains low after the CONF_DONE pin is released high, the device fails to exit the initialization stage. If the CLRUSR option is enabled, ensure sufficient clock cycles have been provided through the CLKUSR pin as stated in the device handbook, otherwise the device will fail to exit initialization stage. If INIT_DONE goes high after the CONF_DONE pin is released high, the device has successfully entered user mode. If CONF_DONE doesn't go high, probe at the TDO, TDI and TCK signals If the TDI signal remains low while the TDO signal is toggling during the configuration, it means the configuration data is not going through the JTAG scan chain register to configure the CRAM bits correctly. This could be due to the JTAG program instruction is not being issued to the FPGA properly.
  • If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:
  • The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

JTAG

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

    The nCE, nCONFIG, nSTATUS CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the dedicated JTAG signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

 

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

     

Active Serial (AS), Active Parallel (AP), Passive Serial (PS), Fast Passive Parallel (FPP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

 

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the configuration device or flash using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the DCLK and DATA line/bus signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

 

 

    The MSEL pins are tied to the correct MSEL setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

    Ensure the supported flash device is used

     

    If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    1. The version of the Quartus II software that you were using when this issue was encountered

    2. The FPGA part number that you were using when this issue was encountered

    3. A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    4. Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    5. Specify your observations after performing the recommended debug strategies

Active Parallel (AP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct AP setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure the supported flash device is used/li>

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the flash using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the DCLK, DATA bus and flash control signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure the byte address of the configuration data is set to 0x020000 during the programming file generation. The default configuration boot address is 0x010000 in 16-bit word addressing, equivalent to 0x020000 8-bit byte addressing in the supported flash memory device

The incorrect address setting in the programming file causes the FPGA to read the wrong/invalid data from the parallel flash

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the flash device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Active Serial (AS)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct AS setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the configuration device using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the nCS, DCLK and DATA signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the configuration device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

JTAG

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

    The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specifications are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the dedicated JTAG signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using and the error message appears in the message window when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Passive Serial (PS), Fast Passive Parallel (FPP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct PS/FPP setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

    Ensure the supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the flash using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the DCLK, DATA line/bus and flash control signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the flash device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Active Serial (AS)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct AS setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the configuration device using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the nCS, DCLK and DATA signals, ensure there is activity on these signals in between the FPGA and the configuration device

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no capacitance load or external device that could cause the delay on the CONF_DONE pin

Delaying or loading the CONF_DONE pin would cause the CONF_DONE fail to raise high within the valid timing window

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the configuration device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

     

JTAG

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

    The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the dedicated JTAG signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no capacitance load or external device that could cause the delay on the CONF_DONE pin

Delaying or loading the CONF_DONE pin would cause the CONF_DONE to fail to raise high within the valid timing window

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

     

Passive Serial (PS), Fast Passive Parallel (FPP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct AP/PS/FPP setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

    Ensure the supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the flash using the new programming file. The latest Quartus II software might have the bug fix.
Check the signal integrity of the DCLK, DATA line/bus and flash control signals Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure there is no capacitance load or external device that could cause the delay on the CONF_DONE pin Delaying or loading the CONF_DONE pin would cause the CONF_DONE fail to raise high within the valid timing window

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the flash device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The nCE, nCONFIG and nSTATUS pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Check the soldering contact in between the FPGA and the board surface The nCONFIG and nSTATUS pins will not be released if the FPGA is not properly powered up or the FPGA does not exit POR successfully

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The FPGA part number that you were using when this issue was encountered

    A screen shot of the voltages (e.g. core voltage, configuration voltage) ramp up from the power-up stage

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the AS configuration setting according to the device handbook

    The dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Ensure the programming cable is powered up and interfaced to the FPGA correctly The Quartus® II programmer will not be able to read/write any information from/to the EPCS device if the power supply or the interface is not stable.
Check if the EPCS device can be programmed through an AS programming cable. This is to ensure the functionality of the EPCS device. Skip this step if you are not able to test with an AS programming cable due to the restriction on your hardware.
Ensure the SFL image exists in the FPGA before the EPCS device is programmed If the SFL bridge does not exist in the FPGA, then the Quartus II programmer will not able to access the ASMI interface in the FPGA to program the EPCS device
After the SFL image is configured to the FPGA, without power cycling the device try to perform auto-detect in the Quartus II programmer If only the FPGA is detected, it signifies that the Quartus II programmer is unable to access the ASMI interface of the FPGA through the SFL bridge, or the Quartus II programmer is not able to detect the interface in between EPCS and the FPGA through the ASMI. Check the power supply and the interface of both devices, or use the SFL from the latest Quartus II software version If both FPGA and EPCS are detected, this is most likely a signal integrity issue. Check the signal integrity of the DATA0, DCLK, nCS and the ASDO pins. Noise at these signal locations will interrupt the EPCS programming process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    A screen shot of the error message shown in the Quartus II message window

    The EPCS density (e.g. EPCS64 or EPCS128) that you were using when this issue was encountered

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure the supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Ensure the programming cable is powered up and interfaced to the FPGA correctly The Quartus® II programmer will not be able to read/write any information from/to the flash device if the power supply or the interface is not stable.
Ensure the PFL image exists in the MAX II CPLD or the FPGA before the flash device is programmed If PFL bridge does not exist in the MAX II CPLD or the FPGA, the Quartus II software is not able to access to the flash device
After the PFL image is configured to the FPGA, without power cycling the device try to perform auto-detect in the Quartus II programmer If only FPGA is detected, it signifies that the Quartus II programmer is unable to access the flash device through the PFL bridge. Check the power supply and the interface in between the MAX II CPLD or FPGA and the flash devices, or use the PFL from the latest Quartus II software version. If both FPGA and EPCS are detected, this is most likely a signal integrity issue. Check the signal integrity of the DATA line/bus, DCLK, the control signal pins. Noise at these signal locations will interrupt the flash programming process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    A screen shot of the error message shown in the Quartus II message window

    The flash device (e.g. Numonyx 512MB, Spansion 128MB etc.) that you were using when this issue was encountered

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct MSEL setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
The Quartus® II bitstream generation could be contributing to the issue. Download the latest version of the Quartus II software. Regenerate the programming file and reconfigure the FPGA or reprogram and verify the flash using the new programming file The latest Quartus II software might have the bug fix
Ensure the CONF_DONE pin is not being delayed.

    Ensure there is no extra capacitance load on the CONF_DONE trace

    Use advance option bit setting to add the post-device bitstream pad bytes

    For AS configuration, use advance option bit setting to disable the CONF_DONE error check or change the program length count

Delaying the CONF_DONE causes the device to miss the CONF_DONE detect window and configuration error occurs Note: If the CONF_DONE error check is disabled, the FPGA will not check if the CONF_DONE rises correctly within the valid timing window.

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    Attach the uncompressed and compressed programming files

    A description of when the failure started to happen and the failure symptoms. For example, the configuration started to fail at the beginning/at the end of the programming cycle.

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct MSEL setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
The Quartus® II bitstream generation could be contributing to this issue. Download the latest version of the Quartus II software. Regenerate the programming file and reconfigure the FPGA or reprogram and verify the flash using the new programming file The latest Quartus II software might have the bug fix
Ensure the CONF_DONE pin is not being delayed.

    Ensure there is no extra capacitance load on the CONF_DONE trace

    Use advance option bit setting to add the post-device bitstream pad bytes

    For AS configuration, use advance option bit setting to disable the CONF_DONE error check or change the program length count

Delaying the CONF_DONE causes the device to miss the CONF_DONE detect window and configuration error occurs Note: If the CONF_DONE error check is disabled, the FPGA will not check if the CONF_DONE rises correctly within the valid timing window.
Ensure the device is successfully key programmed before you perform the configuration with the encrypted file If the key is not present in the device then the device is unable to decrypt the encrypted file
Ensure the same key is used to do the file encryption and to program the device If the key is not compatible then the device is unable to decrypt the encrypted file

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    Attach the uncompressed and compressed programming files

    A description of when the failure started to happen and the failure symptoms. For example, the configuration started to fail at the beginning/at the end of the programming cycle.

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The nCE, nCONFIG, nSTATUS CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file The latest Quartus II software might have the bug fix
Ensure the device is not programmed with the non-volatile key before you perform the volatile key programming Once a non-volatile key (one time programmable) has been programmed into the device you will not be able to program a volatile key
Ensure the VCCBAT is powered up properly The VCCBAT is a dedicated power supply for volatile key storage. The volatile register will not be powered up if there is no VCCCBAT supply.
Ensure the same setup (same board, download cable and the Quartus II software version) is able to perform JTAG programming before you perform the volatile key programming If JTAG programming fails, then it is not a specific volatile key programming failure. 

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of the error message shown in the Quartus II message window

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The nCE, nCONFIG, nSTATUS CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file The latest Quartus II software might have the bug fix
Ensure the device is not programmed with the non-volatile key before you perform the volatile key programming Once a non-volatile key (one time programmable) has been programmed into the device you will not be able to program a volatile key
Ensure the non-volatile key programming frequency (JTAG TCK frequency) is set according to the specifications Unregulated JTAG TCK frequency would interrupt the poly-fuse programming.
Ensure the proper download cable (for example Ethernet Blaster or JTAG technologies) is used for the non-volatile key programming. An unsupported download cable will not enable the programming of the non-volatile key
Ensure the same setup (same board, download cable and the Quartus II software version) is able to perform JTAG programming before you perform the volatile key programming If JTAG programming fails, then it is not a specific volatile key programming failure. Note:Please return to the Configuration Troubleshooter initial page to select JTAG related failures.

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of the error message shown in the Quartus II message window

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Ensure that you have enabled the remote update block in your design If the remote update block is not enabled, you will not be able to use the remote update feature
Ensure that your user logic is according to the outline specified in the altremote_update megafunction user guide (Refer to the device handbook on how to enable the remote update block in your design) Some of the interface might not work properly when you switch to other application images
Ensure that you assigned the right starting address for your application page. Refer to handbook and related application notes for more information on how to assign the right start address. The device will not be able to load the appropriate image if the start address of the application is assigned incorrectly
Ensure that the start address of your application page is written properly to the remote update circuitry. Use the right param[2..0], assert write_param for one clock cycle and make sure the data on the data_in input bus is stable before write_param is asserted. The device will not be able to load the appropriate application image if the start address of the application image is written incorrectly
Ensure that you trigger the reconfiguration input of altremote_update for at least one clock cycle. Refer to the handbook or user guide for related specification (if any) on reconfiguration input port of altremote_update megafunction This ensures the device is able to detect the nCONFIG positive edge to initiate reconfiguration

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screenshot of SignalTap II at the start address writing operation of the application image

    Clock frequency supplied to the altremote_update megafunction

    Specify your observations after performing the recommended debug strategies

Which configuration scheme that you are using?

 

Passive Serial (PS)

    Checklist

    Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct PS setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

    Debug Strategies

    The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

    Strategy Implications Enable the INIT_DONE option in the Quartus® II software, and check on the INIT_DONE pin to ensure the device exits the initialization stage If INIT_DONE remains low after the CONF_DONE pin is released high, the device fails to exit the initialization stage. If the CLRUSR option is enabled, ensure sufficient clock cycles have been provided through the CLKUSR pin as stated in the device handbook, otherwise the device will fail to exit initialization stage. If INIT_DONE goes high after the CONF_DONE pin is released high, the device has successfully entered user mode. If CONF_DONE doesn't go high, probe at the DCLK and DATA signals. Observe both signals after the start button is clicked on the Quartus II programmer If both signals remain low, then the program instruction has not been issued to the FPGA properly.

    If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

     

JTAG

  • Checklist
  • Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.
  • MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

    The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are tied to pull-up/pull-down resistors according to the recommended setup in the device handbook

    The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

  • Debug Strategies
  • The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.
  • Strategy Implications Enable the INIT_DONE option in the Quartus® II software and check on the INIT_DONE pin to ensure the device exits the initialization stage If INIT_DONE remains low after the CONF_DONE pin is released high, the device fails to exit the initialization stage. If the CLRUSR option is enabled, ensure sufficient clock cycles have been provided through the CLKUSR pin as stated in the device handbook, otherwise the device will fail to exit initialization stage. If INIT_DONE goes high after the CONF_DONE pin is released high, the device has successfully entered user mode. If CONF_DONE doesn't go high, probe at the TDO, TDI and TCK signals If the TDI signal remains low while the TDO signal is toggling during the configuration, it means the configuration data is not going through the JTAG scan chain register to configure the CRAM bits correctly. This could be due to the JTAG program instruction is not being issued to the FPGA properly.
  • If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:
  • The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

JTAG

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

    The nCE, nCONFIG, nSTATUS CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the dedicated JTAG signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

 

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

     

Active Serial (AS), Active Parallel (AP), Passive Serial (PS), Fast Passive Parallel (FPP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

 

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the configuration device or flash using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the DCLK and DATA line/bus signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

 

 

    The MSEL pins are tied to the correct MSEL setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

    Ensure the supported flash device is used

     

    If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    1. The version of the Quartus II software that you were using when this issue was encountered

    2. The FPGA part number that you were using when this issue was encountered

    3. A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    4. Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    5. Specify your observations after performing the recommended debug strategies

Active Parallel (AP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct AP setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure the supported flash device is used/li>

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the flash using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the DCLK, DATA bus and flash control signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure the byte address of the configuration data is set to 0x020000 during the programming file generation. The default configuration boot address is 0x010000 in 16-bit word addressing, equivalent to 0x020000 8-bit byte addressing in the supported flash memory device

The incorrect address setting in the programming file causes the FPGA to read the wrong/invalid data from the parallel flash

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the flash device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Active Serial (AS)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct AS setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the configuration device using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the nCS, DCLK and DATA signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the configuration device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

JTAG

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

    The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specifications are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the dedicated JTAG signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using and the error message appears in the message window when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Passive Serial (PS), Fast Passive Parallel (FPP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct PS/FPP setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

    Ensure the supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the flash using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the DCLK, DATA line/bus and flash control signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the flash device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Active Serial (AS)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct AS setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the configuration device using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the nCS, DCLK and DATA signals, ensure there is activity on these signals in between the FPGA and the configuration device

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no capacitance load or external device that could cause the delay on the CONF_DONE pin

Delaying or loading the CONF_DONE pin would cause the CONF_DONE fail to raise high within the valid timing window

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the configuration device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

     

JTAG

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

    The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the dedicated JTAG signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no capacitance load or external device that could cause the delay on the CONF_DONE pin

Delaying or loading the CONF_DONE pin would cause the CONF_DONE to fail to raise high within the valid timing window

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

     

Passive Serial (PS), Fast Passive Parallel (FPP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct AP/PS/FPP setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure all the timing specification are met

    Ensure the supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the flash using the new programming file. The latest Quartus II software might have the bug fix.
Check the signal integrity of the DCLK, DATA line/bus and flash control signals Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure there is no capacitance load or external device that could cause the delay on the CONF_DONE pin Delaying or loading the CONF_DONE pin would cause the CONF_DONE fail to raise high within the valid timing window

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA and the flash device part number that you were using when this issue was encountered

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The nCE, nCONFIG and nSTATUS pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Check the soldering contact in between the FPGA and the board surface The nCONFIG and nSTATUS pins will not be released if the FPGA is not properly powered up or the FPGA does not exit POR successfully

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The FPGA part number that you were using when this issue was encountered

    A screen shot of the voltages (e.g. core voltage, configuration voltage) ramp up from the power-up stage

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the AS configuration setting according to the device handbook

    The dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Ensure the programming cable is powered up and interfaced to the FPGA correctly The Quartus® II programmer will not be able to read/write any information from/to the EPCS device if the power supply or the interface is not stable.
Check if the EPCS device can be programmed through an AS programming cable. This is to ensure the functionality of the EPCS device. Skip this step if you are not able to test with an AS programming cable due to the restriction on your hardware.
Ensure the SFL image exists in the FPGA before the EPCS device is programmed If the SFL bridge does not exist in the FPGA, then the Quartus II programmer will not able to access the ASMI interface in the FPGA to program the EPCS device
After the SFL image is configured to the FPGA, without power cycling the device try to perform auto-detect in the Quartus II programmer If only the FPGA is detected, it signifies that the Quartus II programmer is unable to access the ASMI interface of the FPGA through the SFL bridge, or the Quartus II programmer is not able to detect the interface in between EPCS and the FPGA through the ASMI. Check the power supply and the interface of both devices, or use the SFL from the latest Quartus II software version If both FPGA and EPCS are detected, this is most likely a signal integrity issue. Check the signal integrity of the DATA0, DCLK, nCS and the ASDO pins. Noise at these signal locations will interrupt the EPCS programming process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    A screen shot of the error message shown in the Quartus II message window

    The EPCS density (e.g. EPCS64 or EPCS128) that you were using when this issue was encountered

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

    Ensure the supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Ensure the programming cable is powered up and interfaced to the FPGA correctly The Quartus® II programmer will not be able to read/write any information from/to the flash device if the power supply or the interface is not stable.
Ensure the PFL image exists in the MAX II CPLD or the FPGA before the flash device is programmed If PFL bridge does not exist in the MAX II CPLD or the FPGA, the Quartus II software is not able to access to the flash device
After the PFL image is configured to the FPGA, without power cycling the device try to perform auto-detect in the Quartus II programmer If only FPGA is detected, it signifies that the Quartus II programmer is unable to access the flash device through the PFL bridge. Check the power supply and the interface in between the MAX II CPLD or FPGA and the flash devices, or use the PFL from the latest Quartus II software version. If both FPGA and EPCS are detected, this is most likely a signal integrity issue. Check the signal integrity of the DATA line/bus, DCLK, the control signal pins. Noise at these signal locations will interrupt the flash programming process

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    A screen shot of the error message shown in the Quartus II message window

    The flash device (e.g. Numonyx 512MB, Spansion 128MB etc.) that you were using when this issue was encountered

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct MSEL setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
The Quartus® II bitstream generation could be contributing to the issue. Download the latest version of the Quartus II software. Regenerate the programming file and reconfigure the FPGA or reprogram and verify the flash using the new programming file The latest Quartus II software might have the bug fix
Ensure the CONF_DONE pin is not being delayed.

    Ensure there is no extra capacitance load on the CONF_DONE trace

    Use advance option bit setting to add the post-device bitstream pad bytes

    For AS configuration, use advance option bit setting to disable the CONF_DONE error check or change the program length count

Delaying the CONF_DONE causes the device to miss the CONF_DONE detect window and configuration error occurs Note: If the CONF_DONE error check is disabled, the FPGA will not check if the CONF_DONE rises correctly within the valid timing window.

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    Attach the uncompressed and compressed programming files

    A description of when the failure started to happen and the failure symptoms. For example, the configuration started to fail at the beginning/at the end of the programming cycle.

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The MSEL pins are tied to the correct MSEL setting according to the device handbook

    The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
The Quartus® II bitstream generation could be contributing to this issue. Download the latest version of the Quartus II software. Regenerate the programming file and reconfigure the FPGA or reprogram and verify the flash using the new programming file The latest Quartus II software might have the bug fix
Ensure the CONF_DONE pin is not being delayed.

    Ensure there is no extra capacitance load on the CONF_DONE trace

    Use advance option bit setting to add the post-device bitstream pad bytes

    For AS configuration, use advance option bit setting to disable the CONF_DONE error check or change the program length count

Delaying the CONF_DONE causes the device to miss the CONF_DONE detect window and configuration error occurs Note: If the CONF_DONE error check is disabled, the FPGA will not check if the CONF_DONE rises correctly within the valid timing window.
Ensure the device is successfully key programmed before you perform the configuration with the encrypted file If the key is not present in the device then the device is unable to decrypt the encrypted file
Ensure the same key is used to do the file encryption and to program the device If the key is not compatible then the device is unable to decrypt the encrypted file

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    Attach the uncompressed and compressed programming files

    A description of when the failure started to happen and the failure symptoms. For example, the configuration started to fail at the beginning/at the end of the programming cycle.

    A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

    Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The nCE, nCONFIG, nSTATUS CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file The latest Quartus II software might have the bug fix
Ensure the device is not programmed with the non-volatile key before you perform the volatile key programming Once a non-volatile key (one time programmable) has been programmed into the device you will not be able to program a volatile key
Ensure the VCCBAT is powered up properly The VCCBAT is a dedicated power supply for volatile key storage. The volatile register will not be powered up if there is no VCCCBAT supply.
Ensure the same setup (same board, download cable and the Quartus II software version) is able to perform JTAG programming before you perform the volatile key programming If JTAG programming fails, then it is not a specific volatile key programming failure. 

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of the error message shown in the Quartus II message window

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The nCE, nCONFIG, nSTATUS CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file The latest Quartus II software might have the bug fix
Ensure the device is not programmed with the non-volatile key before you perform the volatile key programming Once a non-volatile key (one time programmable) has been programmed into the device you will not be able to program a volatile key
Ensure the non-volatile key programming frequency (JTAG TCK frequency) is set according to the specifications Unregulated JTAG TCK frequency would interrupt the poly-fuse programming.
Ensure the proper download cable (for example Ethernet Blaster or JTAG technologies) is used for the non-volatile key programming. An unsupported download cable will not enable the programming of the non-volatile key
Ensure the same setup (same board, download cable and the Quartus II software version) is able to perform JTAG programming before you perform the volatile key programming If JTAG programming fails, then it is not a specific volatile key programming failure. Note:Please return to the Configuration Troubleshooter initial page to select JTAG related failures.

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screen shot of the error message shown in the Quartus II message window

    Specify your observations after performing the recommended debug strategies

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

    The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications
Ensure that you have enabled the remote update block in your design If the remote update block is not enabled, you will not be able to use the remote update feature
Ensure that your user logic is according to the outline specified in the altremote_update megafunction user guide (Refer to the device handbook on how to enable the remote update block in your design) Some of the interface might not work properly when you switch to other application images
Ensure that you assigned the right starting address for your application page. Refer to handbook and related application notes for more information on how to assign the right start address. The device will not be able to load the appropriate image if the start address of the application is assigned incorrectly
Ensure that the start address of your application page is written properly to the remote update circuitry. Use the right param[2..0], assert write_param for one clock cycle and make sure the data on the data_in input bus is stable before write_param is asserted. The device will not be able to load the appropriate application image if the start address of the application image is written incorrectly
Ensure that you trigger the reconfiguration input of altremote_update for at least one clock cycle. Refer to the handbook or user guide for related specification (if any) on reconfiguration input port of altremote_update megafunction This ensures the device is able to detect the nCONFIG positive edge to initiate reconfiguration

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

    The version of the Quartus II software that you were using when this issue was encountered

    The FPGA part number that you were using when this issue was encountered

    A screenshot of SignalTap II at the start address writing operation of the application image

    Clock frequency supplied to the altremote_update megafunction

    Specify your observations after performing the recommended debug strategies

If you have questions, you can find the available support options at Intel® Customer Support.  Intel customers with Intel® Premier Support can find training and help topics at Intel® Premier Support.

You can also search the Intel® Community to ask and answer questions about the FPGAs and Programmable Solutions family of products.