After reading thorough the documentation, I noted Altera (Intel) Quartus 16.0 is recommended. Given the lack of support on Intel’s side to provide anything below 17.0 via web download, is there any insight or suggestions for using Quartus versions above 16.0? Thanks for any help.
Hi Cameron,
I tested implementing a design using Quartus 2020.1 and 2020.4 and neither worked - it seems that the quartus_map command is no longer supported for newer versions of the tool. I don’t have access to any version between 16 and 2020, so I cannot tell if Quartus 17.0 would still work, though. We will come back to you with an answer in the coming days.
Regards,
Joaquin
I certainly appreciate the help. It seems like this will be an issue in the coming years as Intel is “committed” to removing older versions of Quartus when they deem necessary. I hope to perform some testing of my own soon, but I’d definitely be more interested in your results, as I am very new to the LEON software package and it’s configuration.
Hi Cameron,
Since it may take some time for us to modify the script environment for Quartus, it would be great if you could run a quick test, provided that you have access to Quartus 17.0. The GPL release, available from our website, includes a few designs targeting Intel/Altera. For instance, you can pick the one below:
grlib-gpl-2023.2-b4283/designs/leon5-altera-c5ekit/
The README file of that design explicitly mentions that Quartus 16.0 is supported, so chances are the newer version 17.0 still works. It should be enough to go to that design, ensuring that Quartus is in your PATH environment variable and running
make quartus
The tool should report something similar to the below:
cp: cannot stat ‘…/…/netlists/altera/cyclone5/*.vqm’: No such file or directory
make: […/…/bin/Makefile:1472: quartus-vqm] Error 1 (ignored)
Info: syspll1: The legal reference clock frequency is 5.0 MHz…800.0 MHz
Info: syspll1: Able to implement PLL with user settings
Info: syspll1: Variation language : VHDL
Info: syspll1: Output directory : /home/joaquin/Downloads/grlib-gpl-2023.2-b4283/designs/leon5-altera-c5ekit
Info: syspll1: Generating variation file /home/joaquin/Downloads/grlib-gpl-2023.2-b4283/designs/leon5-altera-c5ekit/syspll1.vhd
Info: syspll1: Generating synthesizable HDL design
Info: syspll1: Generating altera_pll “syspll1” for QUARTUS_SYNTH
Info: syspll1: “syspll1” instantiated altera_pll “syspll1”
Info: syspll1: Done “syspll1” with 2 modules, 3 files
Info: syspll1: Generating simulation model
Info: syspll1: Generating altera_pll “syspll1” for SIM_VHDL
Info: syspll1: Generating simgen model
Info: syspll1: Info: *******************************************************************
When I used newer versions of Quartus, I got the message of quartus_map not being supported, and therefore none of the above is printed. That should be a good first step to know if v17.0 is still supported.
That said, this is a temporary workaround, this is a problem to be properly addressed in the (hopefully not distant) future.
Regards,
Joaquin
I believe I can perform that testing this week. I was able to configure a Linux VM with the Quartus 17.0 tools, and copied over the GRLIB GPL release (latest). Based on your instructions above, it should be straightforward.
Also, I appreciated the detailed response, looking forward to helping out as best I can.
Thanks Cameron. We are setting up the tool as well, so I will try to post news this week in parallel. I will keep in touch.
Good news: we have downloaded and tested v17.0 on our end - it worked. I implemented the design I mentioned above, targeting a Cyclone-V FPGA.
We are going to check now if versions v19.1 and v18.1 work as well, to have the complete picture. We will update the documentation with the updated Quartus version for the GRLIB 2023.3 release.
That is excellent news, much thanks to your team. I planned to try that out in the next day or two, and will still do so, as I am targeting Cyclone IV and V technology. I definitely believe this is a valuable update to the documentation, and again I still plan to test similar versions and post my results.
FYI: The Cyclone IV target would use your Terasic DE2-115 template/example. I am targeting an Altera Cyclone V GT dev board for the second (but naturally I’d need to configure that on my own).
Hi Cameron. Even better news: version 20.1 is also supported.
The problem was that we had Quartus 20.1 Pro and 20.4 Pro installed in our servers, so the design was failing. Therefore, the conclusion is that any version of Quartus Standard Edition at least up to 20.1 (we have not tested any further) is supported.
I will update the documentation so that 20.1 is listed as the recommended version.
Yes very good news! So was your issue a licensing issue, or quite simply Pro didn’t work at all?
I will add, I am planning to use the “Lite” versions of 17.0 and (now) 20.1. I will work on the vm for 20.1, and then try both Lite versions. I expect success, but you never know.
The problem was that Pro does not support Cyclone V, but I was getting misleading messages about the command quartus_map not being supported anymore. In the following link you can see which families are supported by which tool:
Cyclone IV and V are supported by both Standard and Lite editions, so hopefully this works on your side as well.
Good luck!
Unfortunately I encountered a completely different error message after entering “make quartus”:
user@ubuntu:~/grlib-gpl-2023.2-b4283/designs/leon5-altera-c5ekit$ make quartus
cp: cannot stat '../../netlists/altera/cyclone5/*.vqm': No such file or directory
../../bin/Makefile:1472: recipe for target 'quartus-vqm' failed
make: [quartus-vqm] Error 1 (ignored)
/bin/sh: 2: qmegawiz: not found
Makefile:43: recipe for target 'qwiz' failed
make: *** [qwiz] Error 127
Likely an install problem or bug with Quartus, looks like the megawizard plugin isn’t launching when called by the Makefile. FYI the basic installation process of the simulation and altera libraries was successful, however. Instead of wasting time on this error I will just try Quartus 20.1 Lite + Ubuntu 18.04, considering your success.
EDIT: Same result on Ubuntu 18.04 LTS + 20.1 “qwiz” failure
user@ubuntu:~/grlib-gpl-2023.2-b4283/designs/leon5-altera-c5ekit$ make quartus
cp: cannot stat '../../netlists/altera/cyclone5/*.vqm': No such file or directory
../../bin/Makefile:1472: recipe for target 'quartus-vqm' failed
make: [quartus-vqm] Error 1 (ignored)
/bin/sh: 2: qmegawiz: not found
Makefile:43: recipe for target 'qwiz' failed
make: *** [qwiz] Error 127
Fixed the problem, whether this is the “proper” way to address the issue is TBD. I needed to explicitly add the Quartus binaries path to my ~/ .profile so qmegawiz could be found:
PATH="$PATH:/home/user/intelFPGA_lite/20.1/quartus/bin"
After adding that to ~/ .profile and rebooting, the “make quartus” command was successful. As of this moment the compilation is proceeding without error.
Adding that particular PATH wasn’t called out in the Intel or GRLIB setup instructions, so either it was “expected” to do that, or I missed a step somewhere. Not complaining at all, I’m just trying to understand what I missed (if anything at all).
** Note the above was within my Ubuntu 18.04 / Quartus 20.1 VM
Hi Cameron,
Glad you fixed it. I have quickly checked the documentation and am a bit puzzled about why the instructions on grlib.pdf do not mention the PATH variable - this step is usually a must. Currently It is only included in the section covering Windows / Cygwin installation.
However, in the instructions I provided in a previous message in this thread, I already said this:
The README file of that design explicitly mentions that Quartus 16.0 is supported, so chances are the newer version 17.0 still works. It should be enough to go to that design, ensuring that Quartus is in your PATH environment variable and running
So you can be reassured that this was definitely necessary.
I should have clarified I did add the QUARTUS_ROOTDIR (and the GRLIB) paths as instructed during initial setup for both VM’s. For some reason I still needed to add the explicit path to “/quartus/bin”. I would have expected the QUARTUS_ROOTDIR path to be enough for the OS to find the binaries. I will re-read the steps and see if I missed an explicit path configuration somewhere.
Note the compilation completed successfully, and an .SOF was generated. I will now move to working with the template designs for my board.
Quick question: what is the typical compilation time for the C5E example you provided? I’m trying to get a ballpark on that to fine tune my VM performance and make sure Quartus is configured properly. For a baseline I have provided 4 3.5GHz cores and 16GB RAM for my VM.
Really appreciate the help by the way, looking forward to learning more about these tools and the SoC itself.
I don’t have the numbers at hand, but I’d say it takes around 1.5 - 2 hours to get through synthesis, fitter and bitfiles on a similar machine (4 cores @ 3.8 GHz, 32 GB DDR4 RAM). That was for the LEON5 SoC, though. For the same design with LEON3, my impression is that it took far less, but I wouldn’t dare to say a number, as I only ran it once and didn’t compare the timestamps.
About the PATH, one normally points to the folder with the binaries. Normally you want to be able to see what version of the tool you are using by typing “which quartus”. If you don’t get any, the script environment will most likely not work.
Appears my VM performance is within normal parameters then. FYI I’m settling on using Quartus 20.1 Lite. I also tested a build where I launched quartus and built the project from within the IDE and all went well. My next steps are programming the demo configuration to my reference board and setting up GRMON etc. I saw the how-to using Eclipse so that should be useful.
Thank you again for the help!