Quartus Programmer no longer detects FPGA/CPLD

[shaneh_fl]

I have a fully operational v10.1 Arria II GX (EP2AGX125EF35I5ES) project complete with SOPC, Serial Lite II and DDR. It has a Cypress S29 CFI_1G and a MAX II (EPM2210F324I5) for configuration. The Navy vendor uses PFL in the CPLD to only program the CFI_1G. They created their own VHDL to configure the FPGA. I have  for months been trying to update the v10.1 project to v17.1 but I cannot because the FPGA NSTATUS constantly asserts during configuration. I even created identical v10.1 and v17.1 Bare Bones projects with no IP or processes and no GTX or DDR pins assigned and the FPGA still will not configure. There is no issue with the v10.1 bare bones project during configuration. I think that there is something going on when converting the SOF to POF with v16.1/v17.1 and even v18.1. The v17.1 bare bones project asserts NSTATUS at POF address 0x21054 and I cannot figure it out.

To make a long story short, yesterday, I decided to try and make a v17.1 standalone PFL_CONFIG project. I assigned the clock (50MHz), reset_n and all pins to the CFI_1G and FPGA. I flashed the CPLD and power-cycled. It did not work. However, now Quartus Programmer (any version) does not recognize any device on the JTAG chain. The JTAG signals go to both the CPLD and FPGA. I did try stopping and re-starting the JTAG Server. What could have happened and what should I do?

[NurAiman_M_Intel]

Hi,

May I know if there is any error message? Any changes was make?

Regards,

Aiman

[shaneh_fl]

The only message that Quartus Programmer provides is that it cannot detect any device on the JTAG Chain. Normally the Arria II FPGA is detected and when it is selected the CPLD and CFI_1G appear in the programmer window.

One thing that I failed to do with this PFL project was to assign the CPLD output pin FPGA_RST_N. I checked it the other day and it was 0V. So the FPGA is in reset. This signal is tied to a 10K pull-up so I was able to briefly put VCC3V3 on it but this did not help with the detection.

When I created the PFL_CONFIG CPLD project I did assign the PFL outputs to some CPLD_DEBUG output pins tied to a header. I do see some minimal action for the CFG_A, CFG_D, CFG_ON_N and CFG_WE_N but the signals are only active for a short time. I am now wondering if the PFL is doing something to the JTAG chain that prohibits it from seeing any devices. This is a strange problem. Any suggestions are welcome. Thanks.

[NurAiman_M_Intel]

Hi,

Have you try below?

https://www.intel.com/content/www/us/en/support/programmable/articles/000085212.html

Also, do you have another good working USB Blaster to work with? Can you try using another working USB blaster?

Regards,

Aiman

[NurAiman_M_Intel]

Hi,

Any update for this case?

Regards,

Aiman

[shaneh_fl]

I think my only solution is to replace the MAX II. It is controlling the FPGA_RST_N and I failed to assign this CPLD pin when I made this bare bones PFL Config project. There is a 10K pull-up and I tried manually putting 3.3V on it but there was no change. So as of now I am waiting for the CPLD's and stencil to get ordered. I will post the result when I get the items hopefully within a few weeks.

However, I am currently working the issue on another unit. I am now thinking that my issue could be related to how the vendor's FPGA configuration components is addressing the CFI. I have found that there is a 13-byte offset in the POF data between a v10.1 bare bones (no processes, logic or IP) POF and a v17.1 bare bones POF. Using Hex Editor to view the POF's and observing CFG_D I can see where in the POF that NSTATUS is asserting.  I am currently working on this.

[NurAiman_M_Intel]

Hi,

Thanks for the update. Since you are waiting for the USB Blaster to arrived, I shall set this case to close for now. You may open another case once you have the update.

Regards,

Aiman