MIF loads on some builds and not others

[JordanD]

I have a design with several .mif files for pre-loading RAM. Synthesis fails to load the files on some builds. There is no warning that it fails to load, but the build fails on hardware, so I know it isn't loading the mif. A clean build always works (no db or incremental_db folders), but subsequent builds are inconsistent whether they work or not. Is this a known Quartus bug? Using Quartus Prime Standard 18.0.

Steps:

1. Delete any db folder
2. Open project in Quartus and run synthesis
3. "Source Files Read" report includes .mif files. Critical warning that .mif files don't match the size of RAM.
4. Run through fitter etc, run on hardware, design works.
5. Run synthesis again, literally change nothing.
6. "Source Files Read" report is missing .mif files. No warnings about mif files.
7. Run through fitter etc, run on hardware, design fails.

[RichardTanSY_Intel]

Hi @JordanD 

Could you try to delete both the db and incremental_db folder before recompilation?  

Please help to share the report stating that the design is missing .mif files. Screenshot will do as well. 

Could you try to run using the latest version of Quartus Standard 20.1? To check if the issue persists. 

Best Regards,
Richard Tan

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos. 

[JordanD]

Hello @RichardTanSY_Intel 

Yes, if I delete those folders, it works. But I don't want to have to do that before every build.

I get the same results using Quartus 20.1 Lite (don't have license for Standard, trial license expired).

I know how to work around the issue, but it's still concerning that there aren't warnings for when this problem happens.

The problem is the path to the mif. My current set up is:

• In a custom VHDL file, I have altsyncram instantiation with INIT_FILE=>"apodWindow.mif"
• File apodWindow.mif is in the same directory as the VHDL file where altsyncram is instantiated. But this is not the qsf/qpf directory.
• The path to apodWindow.mif is specified in the qsf file: set_global_assignment -name MIF_FILE ../source/my_ram/apodWindow.mif

I've attached three different projects. In project1, I replicated my project set up with the folder structure and everything. It exhibits the problem I'm having. In project2, I changed the INIT_FILE path to be relative to the qsf. In project3, I set up the RAM using the IP wizard, which involves a qip file and sets INIT_FILE relative to the qsf.

I've attached images for synthesis results of each, with a clean build followed by a second build. All of them synthesize correctly on a clean build (no db or incremental_db folder). On the second build, all of them lack the critical warning about mif size. Only project1 fails to list the mif on the "Source Files Read" report, so project2 and project3 are viable solutions. However, Quartus really ought to give a warning of some kind that the file wasn't found in project1. It's exactly backwards: the critical warning appears when it found the file, and no warning appears when it didn't. Another curiosity: project3 (the wizard "right" way) in Source Files Read says a different path to the mif between builds, using absolute rather than relative.

Is there any other solution here?

[RichardTanSY_Intel]

Hi @JordanD 

It seems weird that the mif files is not loaded (project1) and critical warning message disappear on second compilation. 

I will filed a case to the engineering to investigate on this. 

Best Regards,
Richard Tan

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos. 

[RichardTanSY_Intel]

Hi @JordanD 

Just to inform you that the engineering team is still working on this. 

Best Regards,

Richard Tan

[RichardTanSY_Intel]

Hi @JordanD 

The engineering will fix this in the next Quartus release such that the warning messages will be shown during the second compilation. 

As a workaround, please clean the project first and do compilation. 

Let me know if the workaround is all right to you for now? 

Best Regards,
Richard Tan

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos. 

[JordanD]

The workaround is all right for now. Thank you for your help.

[RichardTanSY_Intel]

Hi @JordanD 

Thank you for the confirmation. With that, I will now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

Best Regards,
Richard Tan

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos.