I have a Cyclone V FPGA with Intel EPCQ32A configuration device attached, and I appear to be stuck in a configuration error loop. I observe that CONF_DONE is never asserted, but nSTATUS toggles up and down, with low (asserted time) around 200us, and high around 600us repeatedly.
I am in JTAG mode, and there is no other access to the EPCQ32. I only have the .jic file from the manufacturer that I'm working with, and it was generated with Quartus version 13.0.1 build 232. I have the Prime Programmer Lite edition version 18.1.0 build 625. MSEL[4:0] pins are 10011/Active Serial Standard, but I understand that this doesn't matter in JTAG mode. I have checked all pullups and power supplies for correctness. I have checked the quality of my connections, such as DCLK, as well for any possible signal integrity issues.
When I program the EPCQ, the SFL is loaded, the EPCQ is programmed, and the verify operation succeeds (CRC passes). When I do a readback, using 'Examine,' the readback file differs by the header (which contains tool version information), and the same four bytes near the end, past the 32Mbit/4194304Byte boundary. Since this looks like some sort of encapsulation around the actual EPCQ image, I tend to think that this is not a problem. Is it?
Upon power cycle, CONF_DONE never asserts, nCONFIG stays high, and nSTATUS toggles, as described above.
I don't understand what error is encountered by the FPGA when configuration data is loaded to it. How do I debug this? Is there something else I could be doing wrong?
I suspect it might be the minimum Data Hold time (tDH) timing specification for Active Serial (AS) configuration issue.
I checked your Cyclone V OPN (5CEFA2F23C8N), and it was listed as the affected OPNs:
You may refer to the following CUSTOMER ADVISORY (ADV1831) for more details.
Thank you for your reply.
What I see from ADV1831 is that the data hold time requirement has gotten smaller, which is normally a good thing. But that document references another document, which I will need to dig into.
What I have observed in probing the configuration phase further is that I am getting an error because CRC does not pass. CRC does not pass because the FPGA ignores the first four bits of read data during a Fast Read command. Therefore all read data is shifted by a nibble, which is obviously wrong. THe FPGA performs the CRC check and fairly immediately restarts.
My guess is that the original jic file, which was targeting the Micron N25Q032A13ESE40G NOR flash, has a different dummy cycle setting from the new EPCQ32A part. In the EPCQ32A spec, I don't see a way of changing the number of dummy read cycles.
I don't have the luxury of the .sof file, so I seem out of luck with generating a new jic that targets the EPCQ32A. Any possible workarounds for that?
I dont think you can change the dummy clock for EPCQ-A device.
In your current .jic file, which configuration device that was selected? (i.e epcq, epcs)
May I know which programming IP did you used for this design?
Sorry for the delay, I am in jury duty for the next month.
--Right, there is no way to change the Intel EPCQ-A dummy cycles.
--In the current .jic file it shows EPCQ when I add it to the Quartus Prime Programmer Lite utility.
I have also discovered that when switching back to the old Micron part, everything works just fine again. But as this part is EOL, I still don't have a long term solution.
Maybe you can have a look at our Device Configuration Support Center.
There is information for Intel Supported Third Party Configuration Devices.
(Go to Intel Supported Configuration Devices -> Intel Supported Third Party Configuration Devices)
I've never seen this page before! It sounds like it could be the solution. I will try one of the Micron parts and let you know.