2022-04-12 05:46:06 +02:00
|
|
|
|
|
|
|
|
Installation Guide
|
|
|
|
|
==================
|
|
|
|
|
|
|
|
|
|
Icarus Verilog may be installed from source code, or from pre-packaged binary
|
|
|
|
|
distributions. If you don't have need for the very latest, and prepackaged
|
|
|
|
|
binaries are available, that would be the best place to start.
|
|
|
|
|
|
|
|
|
|
Installation From Source
|
|
|
|
|
------------------------
|
|
|
|
|
|
|
|
|
|
Icarus is developed for Unix-like environments but can also be compiled on
|
|
|
|
|
Windows systems using the Cygwin environment or MinGW compilers. The following
|
|
|
|
|
instructions are the common steps for obtaining the Icarus Verilog source,
|
|
|
|
|
compiling and installing. Note that there are precompiled and/or prepackaged
|
|
|
|
|
versions for a variety of systems, so if you find an appropriate packaged
|
|
|
|
|
version, then that is the easiest way to install.
|
|
|
|
|
|
|
|
|
|
The source code for Icarus is stored under the git source code control
|
|
|
|
|
system. You can use git to get the latest development head or the latest of a
|
|
|
|
|
specific branch. Stable releases are placed on branches, and in particular v11
|
|
|
|
|
stable releases are on the branch "v11-branch" To get the development version
|
|
|
|
|
of the code follow these steps::
|
|
|
|
|
|
2023-06-01 07:34:02 +02:00
|
|
|
% git config --global user.name "Your Name Goes Here"
|
|
|
|
|
% git config --global user.email you@yourpublicemail.example.com
|
2022-04-12 05:46:06 +02:00
|
|
|
% git clone https://github.com/steveicarus/iverilog.git
|
|
|
|
|
|
|
|
|
|
The first two lines are optional and are used to tell git who you are. This
|
|
|
|
|
information is important if/when you submit a patch. We suggest that you add
|
|
|
|
|
this information now so you don't forget to do it later. The clone will create
|
|
|
|
|
a directory, named iverilog, containing the source tree, and will populate
|
|
|
|
|
that directory with the most current source from the HEAD of the repository.
|
|
|
|
|
|
|
|
|
|
Change into this directory using::
|
|
|
|
|
|
|
|
|
|
% cd iverilog
|
|
|
|
|
|
|
|
|
|
Normally, this is enough as you are now pointing at the most current
|
|
|
|
|
development code, and you have implicitly created a branch "master" that
|
|
|
|
|
tracks the development head. However, If you want to actually be working on
|
|
|
|
|
the v11-branch (the branch where the latest v11 patches are) then you checkout
|
|
|
|
|
that branch with the command::
|
|
|
|
|
|
|
|
|
|
% git checkout --track -b v11-branch origin/v11-branch
|
|
|
|
|
|
|
|
|
|
This creates a local branch that tracks the v11-branch in the repository, and
|
|
|
|
|
switches you over to your new v11-branch. The tracking is important as it
|
|
|
|
|
causes pulls from the repository to re-merge your local branch with the remote
|
|
|
|
|
v11-branch. You always work on a local branch, then merge only when you
|
|
|
|
|
push/pull from the remote repository.
|
|
|
|
|
|
|
|
|
|
Now that you've cloned the repository and optionally selected the branch you
|
|
|
|
|
want to work on, your local source tree may later be synced up with the
|
|
|
|
|
development source by using the git command::
|
|
|
|
|
|
|
|
|
|
% git pull
|
|
|
|
|
|
|
|
|
|
The git system remembers the repository that it was cloned from, so you don't
|
|
|
|
|
need to re-enter it when you pull.
|
|
|
|
|
|
|
|
|
|
Finally, configuration files are built by the extra step::
|
|
|
|
|
|
|
|
|
|
% sh autoconf.sh
|
|
|
|
|
|
|
|
|
|
The source is then compiled as appropriate for your system. See the specific
|
|
|
|
|
build instructions below for your operation system for what to do next.
|
|
|
|
|
|
|
|
|
|
You will need autoconf and gperf installed in order for the script to work.
|
|
|
|
|
If you get errors such as::
|
|
|
|
|
|
2023-06-01 07:34:02 +02:00
|
|
|
Autoconf in root...
|
|
|
|
|
autoconf.sh: 10: autoconf: not found
|
|
|
|
|
Precompiling lexor_keyword.gperf
|
2022-04-12 05:46:06 +02:00
|
|
|
autoconf.sh: 13: gperf: not found.
|
|
|
|
|
|
|
|
|
|
You will need to install download and install the autoconf and gperf tools.
|
|
|
|
|
|
|
|
|
|
Icarus Specific Configuration Options
|
|
|
|
|
-------------------------------------
|
|
|
|
|
|
|
|
|
|
Icarus takes many of the standard configuration options and those will not be
|
|
|
|
|
described here. The following are specific to Icarus::
|
|
|
|
|
|
|
|
|
|
--enable-suffix[=suffix]
|
|
|
|
|
|
|
|
|
|
This option allows the user to build Icarus with a default suffix or when
|
|
|
|
|
provided a user defined suffix. Older stable releases have this flag on by
|
|
|
|
|
default e.g.(V0.8 by default will build with a "-0.8" suffix). All versions
|
|
|
|
|
have an appropriate default suffix ("-<base_version>").
|
|
|
|
|
|
|
|
|
|
All programs or directories are tagged with this suffix. e.g.(iverilog-0.8,
|
|
|
|
|
vvp-0.8, etc.). The output of iverilog will reference the correct run time
|
|
|
|
|
files and directories. The run time will check that it is running a file with
|
|
|
|
|
a compatible version e.g.(you can not run a V0.9 file with the V0.8 run
|
|
|
|
|
time). ::
|
|
|
|
|
|
|
|
|
|
--with-valgrind
|
|
|
|
|
|
|
|
|
|
This option adds extra memory cleanup code and pool management code to allow
|
|
|
|
|
better memory leak checking when valgrind is available. This option is not
|
2024-01-24 11:34:46 +01:00
|
|
|
need when checking for basic errors with valgrind. ::
|
|
|
|
|
|
|
|
|
|
--enable-libvvp
|
|
|
|
|
|
|
|
|
|
The vvp progam is built as a small stub linked to a shared library,
|
|
|
|
|
libvvp.so, that may be linked with other programs so that they can host
|
|
|
|
|
a vvp simulation.
|
2022-04-12 05:46:06 +02:00
|
|
|
|
|
|
|
|
Compiling on Linux/Unix
|
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
|
|
(Note: You will need to install bison, flex, g++ and gcc) This is probably the
|
|
|
|
|
easiest case. Given that you have the source tree from the above instructions,
|
|
|
|
|
the compile and install is generally as simple as::
|
|
|
|
|
|
2023-06-01 07:34:02 +02:00
|
|
|
% ./configure
|
|
|
|
|
% make
|
|
|
|
|
(su to root)
|
2022-04-12 05:46:06 +02:00
|
|
|
# make install
|
|
|
|
|
|
|
|
|
|
The "make install" typically needs to be done as root so that it can install
|
|
|
|
|
in directories such as "/usr/local/bin" etc. You can change where you want to
|
|
|
|
|
install by passing a prefix to the "configure" command::
|
|
|
|
|
|
|
|
|
|
% ./configure --prefix=/my/special/directory
|
|
|
|
|
|
|
|
|
|
This will configure the source for eventual installation in the directory that
|
|
|
|
|
you specify. Note that "rpm" packages of binaries for Linux are typically
|
|
|
|
|
configured with "--prefix=/usr" per the Linux File System Standard.
|
|
|
|
|
|
|
|
|
|
Make sure you have the latest version of flex otherwise you will get an error
|
|
|
|
|
when parsing lexor.lex.
|
|
|
|
|
|
|
|
|
|
Compiling on Macintosh OS X
|
|
|
|
|
---------------------------
|
|
|
|
|
|
|
|
|
|
Since Mac OS X is a BSD flavor of Unix, you can install Icarus Verilog from
|
|
|
|
|
source using the procedure described above. You need to install the Xcode
|
|
|
|
|
software, which includes the C and C++ compilers for Mac OS X. The package is
|
|
|
|
|
available for free download from Apple's developer site. Once Xcode is
|
|
|
|
|
installed, you can build Icarus Verilog in a terminal window just like any
|
|
|
|
|
other Unix install.
|
|
|
|
|
|
|
|
|
|
For versions newer than 10.3 the GNU Bison tool (packaged with Xcode) needs to
|
|
|
|
|
be updated to version 3. ::
|
|
|
|
|
|
|
|
|
|
brew install bison
|
|
|
|
|
echo 'export PATH="/usr/local/opt/bison/bin:$PATH"' >> ~/.bash_profile
|
|
|
|
|
|
|
|
|
|
Icarus Verilog is also available through the Homebrew package manager: "brew
|
|
|
|
|
install icarus-verilog".
|
2023-06-09 13:30:44 +02:00
|
|
|
|
|
|
|
|
Compiling for Windows
|
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
|
|
These are instructions for building Icarus Verilog binaries for
|
|
|
|
|
Windows using mingw cross compiler tools on Linux.
|
|
|
|
|
|
|
|
|
|
To start with, you need the mingw64-cross-* packages for your linux
|
|
|
|
|
distribution, which gives you the x86_64-w64-mingw32-* commands
|
|
|
|
|
installed on your system. Installing the cross environment is outside
|
|
|
|
|
the scope of this writeup.
|
|
|
|
|
|
|
|
|
|
First, configure with this command::
|
|
|
|
|
|
|
|
|
|
$ ./configure --host=x86_64-w64-mingw32
|
|
|
|
|
|
|
|
|
|
This generates the Makefiles needed to cross compile everything with
|
|
|
|
|
the mingw32 compiler. The configure script will generate the command
|
|
|
|
|
name paths, so long as commands line x86_64-w64-mingw32-gcc
|
|
|
|
|
et. al. are in your path.
|
|
|
|
|
|
|
|
|
|
Next, compile with the command::
|
|
|
|
|
|
|
|
|
|
$ make
|
|
|
|
|
|
|
|
|
|
The configure generated the cross compiler flags, but there are a few
|
|
|
|
|
bits that need to be compiled with the native compiler. (version.exe
|
|
|
|
|
for example is used by the build process but is not installed.) The
|
|
|
|
|
configure script should have gotten all that right.
|
|
|
|
|
|
|
|
|
|
There is also a MSYS2 build recipe which you can find under `msys2/` in the repository.
|