new blog: quartus

This commit is contained in:
yosh 2024-01-08 20:12:11 -05:00
parent 02fab8bf57
commit 9dc7acbec1
2 changed files with 127 additions and 0 deletions

View File

@ -0,0 +1,121 @@
# 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...
1. I use void linux, and Intel only "officially" supports Red Hat, CentOS, and OpenSUSE
2. 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](https://wiki.archlinux.org/title/Intel_Quartus_Prime) 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:
1. in case Quartus spewed a bunch of junk across my filesystem, I wanted it to be contained
2. to learn how to actually make and use a chroot
3. 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
4. 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](https://www.intel.com/content/www/us/en/software-kit/785085/intel-quartus-prime-lite-edition-design-software-version-22-1-2-for-linux.html) 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`](https://wiki.archlinux.org/title/Debugging#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](https://www.intel.com/content/www/us/en/support/programmable/support-resources/download/dri-usb-b-lnx.html) 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](https://wiki.archlinux.org/title/Intel_Quartus_Prime#USB-Blaster_not_working)
## 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](https://www.intel.com/content/www/us/en/software-kit/750666/modelsim-intel-fpgas-standard-edition-software-version-20-1-1.html), 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](https://github.com/ghdl/ghdl) and [gtkwave](https://gtkwave.sourceforge.net/) 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

View File

@ -47,3 +47,9 @@ TITLE="2023 music I downloaded | ~yosh"
TB_TITLE="2023 music"
POST_TIME=2024-01-03T00:00:00Z
ENTRY_UUID=ed4f7623-c7f2-4c3a-b73e-bc5eb6c46736
2024-01-09_quartus-linux.md
TITLE="quartus prime on void linux | ~yosh"
TB_TITLE="quartus"
POST_TIME=2024-01-09T02:15:00Z
ENTRY_UUID=6e4e758b-7090-4c35-b20b-a5fbacd0e0d8