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 blog post will assume at least basic familiarity with the Linux command line and Void Linux

before doing anything

if you are on xorg, install the xauth package and run xauth +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 xauth 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

back