Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

IP Regeneration Policy - Quartus Prime Lite 15.1

What has happened to IP regeneration policy? In the past, I could compile my QSYS or SOPC Builder system, and then compile my FPGA. And the FPGA build would use the result of the last Qsys/SOPC Builder build. These days, with Quartus Prime, there is an "IP regeneration policy" which has two options - "Always regenerate synthesis files for IP cores" and "Never regenerate synthesis files for IP cores". Unfortunately the latter is greyed out, and the former is the only thing you can select. Changing the setting in the QSF file doesn't help either - it ignores it!

My issue is that I have a DDR3 hard memory interface in my Cyclone V design, built with Qsys. It takes over 10 minutes to generate the Qsys model for synthesis. So when I hit Generate HDL in Qsys I wait 10 minutes and it's done. And then I hit compile in Quartus and it does it all again. Even if I don't touch the Qsys file, it ALWAYS spends over 10 minutes rebuilding the Qsys system. And, to make matters even worse, if I compile a new file into my project, and have a syntax error in my file, Analyse Current File doesn't spot it, so I hit "Start Compilation" and it spends 12 mintues rebuilding the Qsys system and THEN checks the new file and says - "Ooops, you messed up there and I can't get any further". This is a HUGE waste of time.

Can the tool be changed to stop regeneration of IP UNLESS the files have changed? Please?

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Did you add the .qsys file to your design, or the .qip file generated from it?

    If you add the .qip and set the top level file as the qsys_system_name.v file, and don't add the .qsys file to your project at all, then Quartus shouldn't regenerate the system, it should just use the HDL you generated from Qsys directly.

    This is what I have been doing up until now, but I haven't upgraded past 15.0 (and probably won't for a while).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thanks Galfonz and TCWORLD - that works.

    So why does Quartus add the QSYS file for you, and not the QIP?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Doing the QSYS generation is an extra manual step. If you don't check the box for adding the QSYS file to the Quartus project, you can manually add the qip file. By the way, adding ram to your PC would probably speed up the compilation considerably. Quartus and QSYS are quite the memory hogs.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I have 8GB of RAM - this PC won't take anymore. Quad core i7 with hyperthreading too.... Not sure what else to do other than buy another computer which can take 16GB or more.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I'm using a PC with i7+32GB DDR4 RAM+SSD and Qsys is still a slow beast. But then the Qsys project I'm working on has 50 subsystems and 131 custom IP cores, so fairly large! It takes about 15 minutes to generate the HDL from Qsys - takes 5 minutes and uses ~2GB of RAM just to open it!

    As the versions go on Qsys seems to get slower and more bloated so I doubt updating the PC will help much if you already have 8GB of RAM. Compile times with the larger FPGAs may be reduced (for the Stratix V's they recommend 16GB of RAM for compiling).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I've just found this thread looking for a solution for a problem I have in that my Nios2 system time stamp was not matching up. I came to the conclusion that this was due to my qsys system being regenerated and changing the time stamp but not updating the .sopcinfo file in my qsys directory although I have noticed that it generates a .sopcinfo file in the main project directory.

    I've replaced the .qsys file with the .qip and this has solved the issue.

    Hopefully this will be useful to those searching for system time stamp timestamp mismatch.