- Quartus Prime Lite version 17.0.2.602
- ModelSim-Altera (i.e. the "free" one)
- openSUSE 42.2 (kernel: 4.4.90-18.32-default)
Simulation is an important step when working with FPGAs. Unfortunately, out of the box, the ModelSim-Altera simulation tool will not run from either the Quartus Prime Lite IDE nor the cmdline under a modern (post-4.x kernel), 64-bit, Linux.
To get an idea of the problem (and verify it's occurring with your setup) try running the simulator tool by clicking on Tools -> Run Simulation Tool -> RTL Simulation (I'm fairly sure simulation can only be run after a design has been successfully compiled, so you'll need to start with a compiling project. Also I'm pretty sure you'll also need a top-level HDL for simulation, simulation doesn't work with schematic capture only (although getting the IDE to generate HDL from a schematic is fairly straight-forward))
For me this action results in the following error message:
Oddly, the contents of that file (i.e. where the error message says to check for more details) are only populated after you hit OK. Meaning you have to make the dialog box go away before you can open the file it tells you to check for more information. IOW, you can't keep the dialog box open to help find the file, you have to make note of where the file is, close the dialog box, then open the file. For reference mine looks like this:
Info: Start Nativelink Simulation processNote that this error message location, /home/trevor/devel/fpga/de10-lite/rapid_verilog, is the directory that I created for this project. Also note that orgate is the name of this project's top-level entity. Therefore the location and filename of your error message will be different, but should follow the same pattern. For future reference I'll refer to /home/trevor/devel/fpga/de10-lite/rapid_verilog as ${PROJECT_DIR}.
Info: NativeLink has detected Verilog design -- Verilog simulation models will be used
========= EDA Simulation Settings =====================
Sim Mode : RTL
Family : max10
Quartus root : /opt/Altera/intelFPGA_lite/17.0/quartus/linux64/
Quartus sim root : /opt/Altera/intelFPGA_lite/17.0/quartus/eda/sim_lib
Simulation Tool : modelsim-altera
Simulation Language : verilog
Simulation Mode : GUI
Sim Output File :
Sim SDF file :
Sim dir : simulation/modelsim
=======================================================
Info: Starting NativeLink simulation with ModelSim-Altera software
Sourced NativeLink script /opt/Altera/intelFPGA_lite/17.0/quartus/common/tcl/internal/nativelink/modelsim.tcl
Error: Can't launch ModelSim-Altera Simulation software -- make sure the software is properly installed and the environment variable LM_LICENSE_FILE or MGLS_LICENSE_FILE points to the correct license file.
Error: NativeLink simulation flow was NOT successful
================The following additional information is provided to help identify the cause of error while running nativelink scripts=================
Nativelink TCL script failed with errorCode: issued_nl_message
Nativelink TCL script failed with errorInfo: Can't launch ModelSim-Altera Simulation software -- make sure the software is properly installed and the environment variable LM_LICENSE_FILE or MGLS_LICENSE_FILE points to the correct license file.
while executing
"error "$emsg" "" "issued_nl_message""
invoked from within
"if [ catch {exec $vsim_cmd -version} version_str] {
set emsg "Can't launch $tool Simulation software -- make sure the software is properly installed..."
(procedure "launch_sim" line 88)
invoked from within
"launch_sim launch_args_hash"
("eval" body line 1)
invoked from within
"eval launch_sim launch_args_hash"
invoked from within
"if [ info exists ::errorCode ] {
set savedCode $::errorCode
set savedInfo $::errorInfo
error $result $..."
invoked from within
"if [catch {eval launch_sim launch_args_hash} result ] {
set status 1
if [ info exists ::errorCode ] {
set save..."
(procedure "run_sim" line 74)
invoked from within
"run_sim run_sim_args_hash"
invoked from within
"if [ info exists ::errorCode ] {
set savedCode $::errorCode
set savedInfo $::errorInfo
error "$result" $savedInfo ..."
(procedure "run_eda_simulation_tool" line 334)
invoked from within
"run_eda_simulation_tool eda_opts_hash"
What's really bad about the error messages that show up in the GUI dialog box and in the rpt file is that they imply there's some sort of problem with a license file. There isn't. No license (not even a "free" one) is required to run ModelSim-Altera. This is a red herring. There are a bunch of things that are wrong and need fixing. But none of those have anything to do with licensing. So please resist the urge to log into the Altera website, generate a license, download, and install it. There will be no change to your predicament and hopefully I've saved you from going down that path and wasting a few hours.
If, at Altera's Quartus Prime Lite download page, you selected Combined Files then the simulation software, ModelSim-Altera, would have been installed along with the entire Quartus Prime Lite package.
During installation, the Quartus Prime Lite installer will ask you for an install location. I'm going to call that location ${QUARTUS_INSTALL_DIR} throughout this post (which for me is /opt/Altera/intelFPGA_lite/17.0). At ${QUARTUS_INSTALL_DIR} we find the modelsim_ase directory, which is the directory that contains the ModelSim-Altera Simulation software.
To start investigating what's going wrong, we need to start with where the Quartus Prime Lite IDE looks for the simulation tool. Under Tools -> Options
Select General -> EDA Tool Options
If we look look into this ${QUARTUS_INSTALL_DIR}/modelsim_ase/bin directory, we see that it is filled with symlinks:
Looking carefully, we see that all these links point to just one file!
Looking through this vco file we see it's a shell script. Its job appears to be a multiplexer: the calling program tries to run one of the programs in this bin directory. Based on a bunch of things the vco script finds, it figures out which "real" program to run and where to find this "real" program. The script appears to have support for being run on AIX, Cygwin, Win*, SunOS, HP-UX, and Linux. As you can tell by this list, vco is probably in need of an update!
In the case of Linux, the script first tries to determine which "mode" it should use. The possible modes are "32" and "64". But it doesn't make its determination based on the processor on which it is run, it makes this determination based on a combination of what specific program the caller is requesting, and what directory names it finds in ${QUARTUS_INSTALL_DIR}/modelsim_ase. In most cases, even when running on 64-bit hardware, when run on Linux it will set the "mode" to 32.
Next the vco script tries to define the directory in which to find the actual Linux programs to run. It does this by looking at what kernel is running. The script has support for kernels starting with 2.4.x and running up to 3.x. If the current kernel is something that it can match in this range, it sets the run directory to "linux". Any kernel it finds outside this range is assumed to be something ancient, so it sets the run directory to "linux_rh60". For reference, RedHat Linux 6.0 came out in 1999 with a 2.2.5 kernel. Therefore, when run on a modern system with a post 3.x kernel, it will want to find the programs to run in a directory named ${QUARTUS_INSTALL_DIR}/modelsim_ase/linux_rh60. If we look in the ${QUARTUS_INSTALL_DIR}/modelsim_ase directory, we find a linuxaloem directory and we find a linux symlink to linuxaloem. But we don't find any linux_rh60 directory nor symlink. So it appears that support for early systems has been removed from Quartus Prime Lite, but the vco script still tries to use that directory when it doesn't know what to make of the kernel version.
There are a couple ways to solve this issue. On the one hand you could dig into the vco script and try to fix some of its shortcomings. You could create a linux_rh60 symlink that simply points to either linuxaloem or linux. But at the end of the day, the easiest thing to do is to completely bypass the vco script altogether by editing the directory path in the EDA Tool Options to point to ${QUARTUS_INSTALL_DIR/modelsim_ase/linuxaloem instead! This way when Quartus Prime Lite wants to run the simulator, it will simply invoke the correct Linux binary directly instead of going through the multiplexing script first.
Now that we've routed around this problem, we can try running the simulator again... nope, not fixed.
Looking in the ${QUARTUS_INSTALL_DIR}/modelsim_ase/linuxaloem directory, we find a bunch of actual executables (i.e. not more scripts). If we try to run, for example, the vsim program we get:
$ ./vsim
./vish: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
Why is it running the vish program? In any case, this error makes a little bit of sense. We noted above that the vco script decides to set the mode to "32", despite running on the 64-bit machine. If we look at these programs (in ${QUARTUS_INSTALL_DIR/modelsim_ase/linuxaloem) we find:
$ ldd vsimand
linux-gate.so.1 (0xf7783000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf773e000)
libdl.so.2 => /lib/libdl.so.2 (0xf7739000)
libm.so.6 => /lib/libm.so.6 (0xf76f2000)
libc.so.6 => /lib/libc.so.6 (0xf7549000)
/lib/ld-linux.so.2 (0xf7785000)
$ ldd vish
linux-gate.so.1 (0xf76f6000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf76b1000)
libdl.so.2 => /lib/libdl.so.2 (0xf76ac000)
libm.so.6 => /lib/libm.so.6 (0xf7665000)
libX11.so.6 => not found
libXext.so.6 => not found
libXft.so.2 => not found
libXrender.so.1 => not found
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xf7626000)
librt.so.1 => /lib/librt.so.1 (0xf761d000)
libncurses.so.5 => /lib/libncurses.so.5 (0xf75f2000)
libc.so.6 => /lib/libc.so.6 (0xf7449000)
/lib/ld-linux.so.2 (0xf76f8000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xf73b1000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xf7388000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0xf735e000)
libz.so.1 => /lib/libz.so.1 (0xf7346000)
libbz2.so.1 => /usr/lib/libbz2.so.1 (0xf7337000)
libpng16.so.16 => /usr/lib/libpng16.so.16 (0xf72fb000)
Obviously my openSUSE install already has libX11 (and friends) installed, why does ldd claim to not find them? If you look at the libraries it does find, you'll notice that ldd is finding them in /lib/... not /lib64/.... This means these binaries are looking for 32-bit libraries, not 64-bit ones. Therefore, we need to install some 32-bit packages. Also, as it turns out, my system already has a bunch of 32-bit compatibility libraries installed, otherwise the ldd outputs wouldn't have even been this good. If your ldd tests on these binaries doesn't come out as well, you may need to find and install even more 32-bit libraries than were needed on my system. On my openSUSE 42.2 system the following helps get past this "thanks for the 32-bit binaries" issue:
# zypper install libX11-6-32bit libXext6-32bit libXft2-32bit libXrender1-32bit
Now that we've routed around this problem, we can try running the simulator again... nope, not fixed. However, this time we get no error dialog. I do see some sort of dialog pop up then quickly disappear before I can read anything, but the simulator doesn't start.
If we start the Quartus software from the cmdline, when we try to run the simulator we'll see the following error message on the cmdline from which we invoked the IDE:
$ ./quartus
Info: *******************************************************************
Info: Running Quartus Prime Shell
Info: Version 17.0.2 Build 602 07/19/2017 SJ Lite Edition
Info: Copyright (C) 2017 Intel Corporation. All rights reserved.
Info: Your use of Intel Corporation's design tools, logic functions
Info: and other software and tools, and its AMPP partner logic
Info: functions, and any output files from any of the foregoing
Info: (including device programming or simulation files), and any
Info: associated documentation or information are expressly subject
Info: to the terms and conditions of the Intel Program License
Info: Subscription Agreement, the Intel Quartus Prime License Agreement,
Info: the Intel MegaCore Function License Agreement, or other
Info: applicable license agreement, including, without limitation,
Info: that your use is for the sole purpose of programming logic
Info: devices manufactured by Intel and sold by Intel or its
Info: authorized distributors. Please refer to the applicable
Info: agreement for further details.
Info: Processing started: Wed Oct 25 02:55:26 2017
Info: Command: quartus_sh -t /opt/Altera/intelFPGA_lite/17.0/quartus/common/tcl/internal/tivelink/qnativesim.tcl --rtl_sim orgate orgate
Info: Quartus(args): --rtl_sim orgate orgate
Info: Info: Start Nativelink Simulation process
Info: Info: NativeLink has detected Verilog design -- Verilog simulation models will be ud
Info: Info: Starting NativeLink simulation with ModelSim-Altera software
Warning: Warning: File orgate_run_msim_rtl_verilog.do already exists - backing up currentile as orgate_run_msim_rtl_verilog.do.bak2
Info: Info: Generated ModelSim-Altera script file /home/trevor/devel/fpga/de10-lite/rapiderilog/simulation/modelsim/orgate_run_msim_rtl_verilog.do File: /home/trevor/devel/fpga/d0-lite/rapid_verilog/simulation/modelsim/orgate_run_msim_rtl_verilog.do Line: 0
Info: Info: Spawning ModelSim-Altera Simulation software
Info: Info: Successfully spawned ModelSim-Altera Simulation software
Info: Info: NativeLink simulation flow was successful
Info: Info: For messages from NativeLink scripts, check the file /home/trevor/devel/fpga/10-lite/rapid_verilog/orgate_nativelink_simulation.rpt File: /home/trevor/devel/fpga/de10ite/rapid_verilog/orgate_nativelink_simulation.rpt Line: 0
Info (23030): Evaluation of Tcl script /opt/Altera/intelFPGA_lite/17.0/quartus/common/tclnternal/nativelink/qnativesim.tcl was successful
Info: Quartus Prime Shell was successful. 0 errors, 1 warning
Info: Peak virtual memory: 796 megabytes
Info: Processing ended: Wed Oct 25 02:55:26 2017
Info: Elapsed time: 00:00:00
Info: Total CPU time (on all processors): 00:00:00
Failed to obtain lock: couldn't open "/home/trevor/.modelsim_lock": file already exists
Error in startup script:
Initialization problem, exiting.
Initialization problem, exiting.
Initialization problem, exiting.
while executing
"Transcript::action_log "PROPREAD \"$key\" \"$value\"""
(procedure "VsimProperties::Init" line 59)
invoked from within
"VsimProperties::Init $MTIKeypath"
(procedure "PropertiesInit" line 18)
invoked from within
"PropertiesInit"
invoked from within
"ncFyP12 -+"
(file "/mtitcl/vsim/vsim" line 1)
** Fatal: Read failure in vlm process (0,0)
Note: if we try running vsim (from ${QUARTUS_INSTALL_DIR}/modelsim_ase/linuxaloem) directly we also get:
$ ./vsim
Failed to obtain lock: couldn't open "/home/trevor/.modelsim_lock": file already exists
Error in startup script:
Initialization problem, exiting.
Initialization problem, exiting.
Initialization problem, exiting.
while executing
"Transcript::action_log "PROPREAD \"$key\" \"$value\"""
(procedure "VsimProperties::Init" line 59)
invoked from within
"VsimProperties::Init $MTIKeypath"
(procedure "PropertiesInit" line 18)
invoked from within
"PropertiesInit"
invoked from within
"ncFyP12 -+"
(file "/mtitcl/vsim/vsim" line 1)
** Fatal: Read failure in vlm process (0,0)
If we google some of these messages, we find that it's a very strange way of saying that the program is unhappy with our system's version of freetype. The solution to this issue is to download, compile, and install an older version of freetype. We don't, however, want to install this older version to any system locations (and therefore mess up our system's package manager). Therefore, we will simply provide an alternate install-to directory, and use some tricks to make sure these Quartus programs use the alternate library. In my case I downloaded freetype-2.4.7, built, and installed it. But hold on: by default my system will compile everything to 64-bit code. That won't work in this case because, as we've established, these binaries are 32-bit and are looking for 32-bit libraries. Therefore in order to build for 32-bit on a 64-bit system:
$ CFLAGS=-m32 ./configure --prefix=/home/trevor/local/packages/freetype-2.4.7-32bit/
FreeType build system -- automatic system detection
The following settings are used:
platform unix
compiler cc
configuration directory ./builds/unix
configuration rules ./builds/unix/unix.mk
If this does not correspond to your system or settings please remove the file
`config.mk' from this directory then read the INSTALL file for help.
Otherwise, simply type `make' again to build the library,
or `make refdoc' to build the API reference (the latter needs python).
cd builds/unix; ./configure '--prefix=/home/trevor/local/packages/freetype-2.4.7-32bit/'
configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/trevor/devel/extern/freetype-2.4.7/builds/unix':
configure: error: C compiler cannot create executables
See `config.log' for more details
builds/unix/detect.mk:84: recipe for target 'setup' failed
make: *** [setup] Error 77
That's not good. If we look at the builds/unix/config.log file we find:
configure:2904: checking whether the C compiler works
configure:2926: gcc -m32 conftest.c >&5
/usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/6/libgcc.a when searching for -lgcc
/usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/ld: cannot find -lgcc
/usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/6/libgcc.a when searching for -lgcc
/usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
That's a classic problem that happens when one tries to build 32-bit software on a 64-bit system. The 32-bit versions of more build infrastructure needs to be added:
# zypper install gcc-32bit
Now the build should work:
$ CFLAGS=-m32 ./configure --prefix=/home/trevor/local/packages/freetype-2.4.7-32bit
...
$ make install
If we then try to run the vsim program by hand from the cmdline we (still) get:
Error in startup script:
Initialization problem, exiting.
Initialization problem, exiting.
Initialization problem, exiting.
while executing
"Transcript::action_log "PROPREAD \"$key\" \"$value\"""
(procedure "VsimProperties::Init" line 59)
invoked from within
"VsimProperties::Init $MTIKeypath"
(procedure "PropertiesInit" line 18)
invoked from within
"PropertiesInit"
invoked from within
"ncFyP12 -+"
(file "/mtitcl/vsim/vsim" line 1)
** Fatal: Read failure in vlm process (0,0)
That's because we're still using the system's freetype. In order to use the freetype we've just built and installed:
$ LD_LIBRARY_PATH=/home/trevor/local/packages/freetype-2.4.7-32bit/lib:$LD_LIBRARY_PATH ./vsim
Failed to obtain lock: couldn't open "/home/trevor/.modelsim_lock": file already exists
Reading pref.tcl
Success!!
But what can we do to make sure this recently-compiled freetype is used automatically?
If we look carefully at the full log that we get from when we ran Quartus Prime Lite from the cmdline and tried to run the simulator from the resulting IDE, we see that one of the first things the IDE does is to run quartus_sh. This file is located in ${QUARTUS_INSTALL_DIR}/quartus/bin. If we look into this file we see that it is a script which is very similar in function to the vco script we found in the modelsim_ase directory [in fact, if we look at everything in that directory we see that the contents of every file is exactly the same as every other file in that directory with actual copies instead of symlinking to just one script!]. Most of the script determines what to do, then at the end the actual program is invoked. Just before invoking the actual program a qenv.sh file is sourced. The qenv.sh file is found in ${QUARTUS_INSTALL_DIR}/quartus/adm directory. If we edit this qenv.sh file and, very close to the top, add the following line (adjust it so it matches your specific situation):
export LD_LIBRARY_PATH=/home/trevor/local/packages/freetype-2.4.7-32bit/lib:$LD_LIBRARY_PATH
then we'll find that we can invoke the simulator from within the IDE and it will come up with the work folder that we need to simulate our design!!
SUCCESS!
Now we can simulate our design by right-clicking on orgate and selecting Simulate
Voila!
One webpage that was immensely helpful was this one from the Arch community, thanks!!
