Forum Discussion

KJame6's avatar
KJame6
Icon for New Contributor rankNew Contributor
7 years ago

Micron MT25Q flash support query

I see that Quartus v18.1 now includes Micron flash options in the ASMI_PARALLEL, ASMI_PARALLEL_II, and SERIAL FLASH LOADER IP cores. I use the ASMI_PARALLEL IP core in my design, specifically. These new Micron flash options in the CONFIGURATION DEVICE TYPE selection box certainly helps ease the pain of the discontinuation of the EPCQL1024 parts. However, it seems that there is no backward compatability, i.e. if I change the IP core's CONFIGURATION DEVICE TYPE selection from EPCQL1024 to MT25QU01G and generate a new image, it only works with MT25QU01G devices. The issue with this approach, is that I believe I am now forced to maintain 2 seperate FPGA builds: 1. with EPCQL1024 support (for my legacy boards), and 2. with MT25QU01G support (for my boards manufactured after the EPCQL1024 EOL notice).

After investigating the generated output verilog files for the IP Core, I notice only a very small difference in the generated code (at least at the IP's top level) between the EPCQL1024 and MT25QU01G versions. This begs the question:

Would it be possible in a future Quartus version to offer support for both of these flash devices with the same IP Core configuration? Perhaps the core could read the vendorID first, and then take appropriate action...

7 Replies

  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    7 years ago

    ​Hi,

    There is no way to use same design for BOTH flash device. The reason is that both flash is not identical and there might be issue happening if you are using the same file.

  • KJame6's avatar
    KJame6
    Icon for New Contributor rankNew Contributor
    7 years ago

    John, thanks for the reply. I do understand that there is CURRENTLY no way to use the same image for both flash devices. What I am suggesting is that, if possible, this would be a useful feature for your customers with existing product in the field that utilize EPCQ devices. If Intel cannot support both devices via some FLASH Device detection logic, essentially they are pushing the problem to customers, who will have to detect the FLASH device and use the appropriate image.

    In summary, I know that the MT25Q and EPCQ devices are not IDENTICAL, but are they close enough that some future IP addition could accomodate both?

  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    7 years ago

    ​Hi,

    I understand your concern but unfortunately there is no way to implement it using Quartus programmer as different flash will need different method to be configured.

    The only method that I can think of is by using raw binary file (RPD) which the setting will be handled by the FPGA design.

  • KJame6's avatar
    KJame6
    Icon for New Contributor rankNew Contributor
    7 years ago

    John, this response leaves me a little bit confused. I list the reasons for my confusion below:

    1. 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?
    2. 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.

    • FpgaDesigner's avatar
      FpgaDesigner
      Icon for New Contributor rankNew Contributor
      6 years ago

      Did 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's avatar
        FpgaDesigner
        Icon for New Contributor rankNew Contributor
        6 years ago

        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.

  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    7 years ago

    Hi,

    The small differences is needed in order for the IP to handle the specific flash correct. It cannot be make generic for all supported flash.