Disable Device ID check during JTAG Programming

--- Quote Start ---

But i cannot flash this image to my fpga because the programming tool seems to check the flash id any way

--- Quote End ---

Which error do you actually see? Wrong device ID in Quartus programmer?

There would be still the option to write the AS flash by custom logic or external hardware.

--- Quote Start ---

Which error do you actually see? Wrong device ID in Quartus programmer?

--- Quote End ---

Oh, yes, the typical error message:

Error (209025): Can't recognize silicon ID for device 1. A device's silicon ID is different from its JTAG ID. Verify that all cables are securely connected, select a different device, or check the power on the target system. Make sure the device pins are connected and configured correctly.

Error (209012): Operation failed

--- Quote Start ---

There would be still the option to write the AS flash by custom logic or external hardware.

--- Quote End ---

Yes, but i would have spend ages for a custom external programmer only to avoid this "artifical software problem". (Maybe it would be easier to switch to an other FPGA brand. But i assume every manufacturer has it's own problems.) Or is there a easy "external hardware" solution? Indeed, i have my own CAN-Bootloader - but this is so slow and i always need a running Microcontroller and CAn Controller and CAN-Bootloader software. No way for fast development.

--- Quote Start ---

Getting data OUT of the FLASH during AS configuration doesn't work with "alternative" devices.

--- Quote End ---

As stated in your original thread, it did work in the past with other "alternative" devices. In so far the statement is too general, I think.

It's necessary to check in detail why the different devices fail and whether the problem can be fixed or not.

The other point is this. Altera has never been a flash manufacturer, instead they sold rebranded third party chips with large surcharge. Intel stopped making flash memory many years ago. Apart from the price differences that matter in sensitive application, the Altera EPCS/Q chip portfolio suffered from a limited offer of package and supply voltage variants.

Thus there are many reasons to use "alternative" chips as serial configuration devices. The straightforward solution would be to give complete information about device requirements and possibly add support for industry standard flash devices in tools.

--- Quote Start ---

I had room on the board for the huge EPCQ part, so I just used it.

--- Quote End ---

That was also my approach in case of EPCQ256, to be on the safe side and have the Altera device as an assembly option, also in case of a supply bottleneck. But I found out that Micron N25Q256A13ESF worked as perfect replacement. I guess that newer Micron MT25Q256 will work as well, but didn't yet check.

I worked through serial flash datasheets and think, I've found why the Macronix and Cypress devices fail in configuration phase although they could be correctly programmed and verified as reported by gj_leeson.

These chips have non-volatile enable bits for quad SPI mode that must be set once for ASx4 to be operational. Programming and verification by SFL uses single SPI mode, so the problem shows only during FPGA configuration. Micron N25Q256A (the original EPCQ256 chip) and MT25QL256 don't have a quad enable bit.

The best solution would be to write a modified Factory SFL application that sets the quad enable bits for the respective chips. If boot time isn't critical you might try ASx1 mode in programming file conversion.