Forum Discussion
New ContributorMicron MT25Q flash support query
New ContributorJohn, this response leaves me a little bit confused. I list the reasons for my confusion below:
- You referred to "Quartus programmer". My concern / original query was for the use of ASMI_PARALLEL IP core. Is Quartus programmer synonymous with ASMI_PARALLEL IP core?
- I currently do employ the use of RPD files. I generate the RPD file using the Quartus programming file generation tool (and target the MT25Q flash device). I then use the ASMI_PARALLEL IP core in my design to overwrite the config. image in flash with this new RPD file. Even though the RPD file is generated targeting the MT25Q flash, the ASMI_PARALLEL IP core must be generated specifically for the MT25Q device for it to work.
I have diff'd the Quartus generated verilog files for the ASMI_PARALLEL IP core targeting both the EPCQL1024 and MT25Q devices, and have only seen 1 line of different code. It appears to be something related to an addressing mode. This small amount of differences in the generated code that I could see was what made me question whether the IP core could be made to support both devices/generate identical verilog code when targeting these two devices.
New ContributorDid you ever get anything helpful on this? I'm looking into it right now and am very disappointed in how this has been handled by Intel. Having to do separate FPGA builds just for the flash part is just not feasible for a remote deployment strategy. I'm using the ASMI_PARALLEL as well, and although erase is currently completely broken, I'm assuming I'll get that figured out at some point. My parts are the EPCSL512/MTQU512 but the problem seems to be the same.
- FpgaDesigner
To reply to my own post in case anyone else is dealing with this, I found that I could take the generated code from a module set for the EPCQL512 and another module set for the MT25QU and mash them together so that a selector input assigns the appropriate value to the few things that have differences. I have a flash value that stores which type of flash is on-board and selects the appropriate logic. Since that is not 100% reliable (using the flash to store info about the flash!) I changed our field-reprogramming software to first do a test sector in an unused area. If it can erase->write->read twice to that sector I allow the update process to proceed. I've tested on boards with both types of flash and this works. If Intel ever changes the ASMI_PARALLEL module in a good way I will need to regenerate and update my module now, but from what I've seen so far I'd rather never let it change and keep it exactly as I have it now.
This is not the most elegant solution, but it does work. I had hoped to use the silicon ID to automatically select, but they are the same for some reason I cannot begin to grasp.
