installing quartus prime on void linux
one of my classes had us install Intel’s Quartus Prime Lite software for VHDL design on an Intel FPGA board. the problem with that is that…
- I use void linux, and Intel only “officially” supports Red Hat, CentOS, and OpenSUSE
- Quartus is proprietary, which means debugging and finding help for running it is a huge pain
these seem like a pretty hefty sum of constraints, but luckily, there was already an archwiki entry about Quartus, allowing me to use it as a base to jump off of
I obviously can’t be a house for every single problem one might encounter when using this program, but I can at least share my own problems and workarounds in the hope anyone else finds it useful
this article will assume at least basic familiarity with the Linux command line and Void Linux
before doing anything
if you are on xorg, install the xhost
package and run xhost +local:
. If you don’t, Quartus will not run in the chroot. you must do this every time you restart your X server and want to run Quartus
if you are on Wayland, make sure you have Xwayland
. You don’t need to do any special xhost
stuff, so don’t worry about that
making a chroot
I made a chroot for Quartus for a few reasons:
- in case Quartus spewed a bunch of junk across my filesystem, I wanted it to be contained
- to learn how to actually make and use a chroot
- in case a system update of critical packages (e.g. glibc) caused Quartus to break. I wanted to just install it once and never worry about it ever again
- I dunno. Paranoia? Perhaps a bit a paranoia. Peace of mind
to create a chroot and install a new void installation, let us use xvoidstrap
from the xtools
package. make sure the chroot is glibc
or else quartus won’t run
$ mkdir /path/to/chroot/
$ su
# XBPS_ARCH=x86_64-glibc xvoidstrap /path/to/chroot/
now we enter the chroot and do some basic setup; this must be done as root
# xchroot /path/to/chroot
/* if DISPLAY isn't set, you'll need to set it with export DISPLAY=:0 */
/* quality of life programs. replace rxvt-unicode-terminfo with your respective terminfo */
[xchroot /chroot/] # xbps-install tmux rxvt-unicode-terminfo nnn htop vim aria2
/* important! you must configure glibc locale, or else quartus won't boot */
/* edit /etc/default/libc-locales to remove the # on your respective locale. For me, it was en_US UTF-8 UTF-8 */
[xchroot /chroot/] # xbps-reconfigure -f glibc-locales
[xchroot /chroot/] # passwd
New Password: quartus
[xchroot /chroot/] # useradd guy
[xchroot /chroot/] # passwd guy
New Password: quartus
[xchroot /chroot/] # su guy
[guy@host /] $ cd
that’s all there is to making a chroot
downloading and installing quartus
my class only required us to use the MAX 10 family of boards. I Definitely did not want to download the whole 6.6G uncompressed for every board support, so I went to “Individual Files” on the download page and downloaded only Intel Quartus Prime (Includes Nios II EDS)
and Intel MAX FPGA device support
. I downloaded both of these files to the home directory of my guy
user in the chroot. I believe they must both be in the same directory along with your cwd matching for it to detect it automatically
after that, I just ran the installer from in the chroot with ./QuartusLiteSetup-22.1std.2.922-linux.run
(use tab in case the name is different) and, to my surprise, I could install it without root. as such, I set its directory to ~/intelFPGA_lite
in guy
’s home directory and just went through the installer. no problems here
running quartus
running Quartus is where I started encountering some problems. every time I ran ./intelFPGA_lite/22.1std/quartus/bin/quartus
(which I symlinked to ./quartus
for ease of use), it’d silently fail without any reason why. inspecting the script led me to the variable QUARTUS_ROOTDIR
, which was being mangled due to where I was running it. Intel made nearly every file in the quartus directory read only for some reason, so I did find ./intelFPGA_lite -exec chmod +w {} \+
to allow me to write everything in there.
anyway, inspecting the script, I added the following lines at the beginning, before any executable code:
export QUARTUS_ROOTDIR_OVERRIDE=/home/guy/intelFPGA_lite/22.1std/quartus
export LD_LIBRARY_PATH="$QUARTUS_ROOTDIR_OVERRIDE/linux64"
the first one fixes the aforementioned rootdir, and the second line makes it use all the libraries that are bundled with quartus
I thought this would be enough, but I was getting a vague Aborted
message whenever I ran ./quartus
now. as an idea, I used LD_DEBUG
to see if I was missing any libraries, and sure enough, I was missing some library. I used xlocate
to find the package it corresponding to, dbus-libs
, and installed it in the chroot. after doing this, quartus booted successfully
USB blaster
at this point, I was pretty hopeful, so I started a new project and hacked away at my assignment. everything was smooth until I realized that I had to upload my VHDL to the board, which on Windows required some hacky USB Blaster shenanigans. hmm. oh well, I thought, and just tried doing so anyway
nothing happened. it kept displaying “Failed!”. damn. guess software miracles aren’t free
luckily, the fix for that seemed relatively simple. I ran ./intelFPGA_lite/22.1std/quartus/bin/jtagd
as root in the chroot, disconnected and reconnected the board, and then it just… hung for a long time… before failing again. hmm. at least the error was different
The fix for that issue was actually reading the official documentation! shocker! I followed the steps on Intel’s Linux documentation for USB Blaster inside the chroot (you’ll need to create the /etc/udev/rules.d
directory before creating /etc/udev/rules.d/51-usbblaster.rules
. then unplugged and replugged the board again. it worked!
lingering issues/troubleshooting
sometimes /dev
doesn’t like entering and exiting the chroot and/or jtag
and/or the usb device as a whole, and it locks up as being perpetually busy. I just restart my laptop whenever I notice this and it actually hinders my uploading because I did not have enough energy to debug this
sometimes, even after running jtagd
as root inside the container, testing if it’s going with .../quartus/bin/jtagconfig
would result in it hanging, along with uploading to the board. I fix this by simply killing the jtagd process and running it again. woohoo
other issues not mentioned I delegate to the archwiki
modelsim
I decided to not try and wrangle with Questa and the myriad of licensing issues that I heard people have on not just Linux, but Windows as well. therefore, I went with modelsim
ModelSim is a 32 bit executable. to get ModelSim to work, we first need to install some libraries that aren’t included with it (unlike with Quartus). If you don’t do this, you’ll get vague errors that caused me to go on a 30 minute googling spree ending in finding out I needed gcc-multilib
[xchroot /chroot/] # xbps-install void-repo-multilib
[xchroot /chroot/] # xbps-install -S
[xchroot /chroot/] # xbps-install gcc-multilib libXext-32bit libXft-32bit
after that, I downloaded ModelSim from Intel’s site, which should auto detect you as linux. I just put it in /home/guy
in the chroot. now we have to run it
[xchroot /chroot/] # su guy
[guy@host /] $ cd
[guy@host ~] $ chmod +x ./ModelSimSetup-20.1.1.720-linux.run
[guy@host ~] $ ./ModelSimSetup-20.1.1.720-linux.run
I noticed that I forgot to do the xhost +local:
thing, since I was doing this in a separate session. to my surprise, it had a console installation for this! nice. nonetheless, I needed to have the xhost
thingy for when I ran ModelSim in quartus, so I exited the installer with ^C
, did xhost +local:
outside the chroot, and ran the ModelSim installer again
ah. all the text is squares. I have no idea why this happened or how to fix it. because of this, I decided to go with the console installer anyway by running DISPLAY="" ./ModelSimSetup-20.1.1.720-linux.run
. I just left all the defaults as-is, which caused it to install to /home/guy/intelFPGA
(note that quartus installed to /home/guy/intelFPGA_lite
). whatever
after that, I launched quartus, went to Tools -> Options -> EDA Tool Options, clicked the 3 dots next to ModelSim
, and pointed it to /home/guy/intelFPGA/20.1/modelsim_ase/bin
. after that, I was able to run simulations perfectly fine within quartus
standalone simulator
I couldn’t get modelsim alone going, nor could I get Questa going. I thought I was SOL for a simulator, which was required for the class, but alas I was able to get GHDL and gtkwave for my project, and both are in void’s repositories
conclusion
I am not good at reflecting on stuff that I did, but I do feel as if this shaped up at least some debugging skills that I didn’t know about (okay, maybe just the LD_DEBUG
thing). either way, I hope this comes in handy for anyone else that has to deal with Quartus for whatever reason