geda:icarus_readme
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
geda:icarus_readme [2012/02/20 15:14] 127.0.0.1 external edit |
geda:icarus_readme [2014/04/14 08:58] rlutz Update README to latest version (20130827 snapshot) |
||
|---|---|---|---|
| Line 14: | Line 14: | ||
| Icarus Verilog is not aimed at being a simulator in the traditional | Icarus Verilog is not aimed at being a simulator in the traditional | ||
| sense, but a compiler that generates code employed by back-end | sense, but a compiler that generates code employed by back-end | ||
| - | tools. These back-end tools currently include a simulator engine | + | tools. |
| - | called VVP, an XNF (Xilinx Netlist Format) generator and an EDIF FPGA | + | |
| - | netlist generator. In the future, backends are expected for EDIF/LPM, | + | |
| - | structural Verilog, VHDL, etc. | + | |
| For instructions on how to run Icarus Verilog, | For instructions on how to run Icarus Verilog, | ||
| Line 69: | Line 66: | ||
| The readline library in turn uses termcap. | The readline library in turn uses termcap. | ||
| - | If you are building from CVS, you will also need software to generate | + | If you are building from git, you will also need software to generate |
| the configure scripts. | the configure scripts. | ||
| Line 89: | Line 86: | ||
| to know. It generally works pretty well. There are a few flags to the | to know. It generally works pretty well. There are a few flags to the | ||
| configure script that modify its behavior: | configure script that modify its behavior: | ||
| - | |||
| - | --without-ipal | ||
| - | This turns off support for Icarus PAL, whether ipal | ||
| - | libraries are installed or not. | ||
| --prefix=<root> | --prefix=<root> | ||
| Line 104: | Line 97: | ||
| install with --prefix=$HOME. | install with --prefix=$HOME. | ||
| - | --enable-vvp32 (experimental) | + | --enable-suffix |
| - | If compiling on AMD64 systems, this enables the | + | --enable-suffix=<your-suffix> |
| - | compilation of 32bit compatible vvp (vvp32) and the vpi | + | --disable-suffix |
| - | modules that match. | + | Enable/disable changing the names of install files to use |
| - | + | a suffix string so that this version or install can co- | |
| - | 2.2.1 Special AMD64 Instructions | + | exist with other versions. This renames the installed |
| - | + | commands (iverilog, iverilog-vpi, vvp) and the installed | |
| - | (The Icarus Verilog RPM for x86_64 is build using these instructions.) | + | library files and include directory so that installations |
| - | + | with the same prefix but different suffix are guaranteed | |
| - | If you are building for Linux/AMD64 (a.k.a x86_64) then to get the | + | to not interfere with each other. |
| - | most out of your install, first make sure you have both 64bit and | + | |
| - | 32bit development libraries installed. Then configure with this | + | |
| - | somewhat more complicated command: | + | |
| - | + | ||
| - | ./configure libdir64='$(prefix)/lib64' vpidir1=vpi64 vpidir2=. --enable-vvp32 | + | |
| - | + | ||
| - | This reflects the convention on AMD64 systems that 64bit libraries go | + | |
| - | into lib64 directories. The "--enable-vvp32" also turns on 32bit | + | |
| - | compatibility files. A 32bit version of vvp (vvp32) will be created, | + | |
| - | as well as 32bit versions of the development libraries and bundled VPI | + | |
| - | libraries. | + | |
| 2.3 (Optional) Testing | 2.3 (Optional) Testing | ||
| Line 176: | Line 158: | ||
| One can see a human readable version of the final pform by using the | One can see a human readable version of the final pform by using the | ||
| - | ``-P <path>'' flag to the compiler. This will cause iverilog to dump | + | ``-P <path>'' flag to the ``ivl'' subcommand. This will cause ivl |
| - | the pform into the file named <path>. | + | to dump the pform into the file named <path>. (Note that this is not |
| + | normally done, unless debugging the ``ivl'' subcommand.) | ||
| 3.3 Elaboration | 3.3 Elaboration | ||
| Line 203: | Line 186: | ||
| tree of NetScope objects is built up and placed in the Design object, | tree of NetScope objects is built up and placed in the Design object, | ||
| with the root module represented by the root NetScope object. The | with the root module represented by the root NetScope object. The | ||
| - | elab_scope.cc and elab_pexpr.cc files contain most of the code for | + | elab_scope.cc file contains most of the code for handling this phase. |
| - | handling this phase. | + | |
| The tail of the elaborate_scope behavior (after the pform is | The tail of the elaborate_scope behavior (after the pform is | ||
| Line 257: | Line 239: | ||
| The $attribute keyword looks like a system task invocation. The | The $attribute keyword looks like a system task invocation. The | ||
| - | difference here is that the parameters are more restricted then those | + | difference here is that the parameters are more restricted than those |
| of a system task. The <identifier> must be an identifier. This will be | of a system task. The <identifier> must be an identifier. This will be | ||
| the item to get an attribute. The <key> and <value> are strings, not | the item to get an attribute. The <key> and <value> are strings, not | ||
geda/icarus_readme.txt · Last modified: 2014/04/14 09:57 by rlutz
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
