Cppcheck fixes in vvp

SV: chained method calls a().b()

.github/test.sh

@@ -1,14 +0,0 @@
-#!/usr/bin/env sh
-
-echo "Using the bundled ivtest to run regression tests."
-echo " pwd = $(pwd)"
-
-cd ivtest
-
-status=0
-
-perl vvp_reg.pl || status=1
-
-perl vpi_reg.pl || status=1
-
-exit $status

.github/workflows/deploy_docs.yml

@@ -19,10 +19,15 @@ jobs:
     - name: Install dependencies
       run: |
         sudo apt update -qq
-        sudo apt install -y make autoconf python3-sphinx
+        sudo apt install -y make autoconf python3-venv
+        python3 -m venv .venv
+        . .venv/bin/activate
+        pip install --upgrade pip
+        pip install -r Documentation/requirements.txt
 
     - name: Make Documentation
       run: |
+        . .venv/bin/activate
         cd Documentation
         make html
 

.github/workflows/test.yml

@@ -1,24 +1,27 @@
 name: test
 
 on:
-  # Every push onto the main branch and releases triggers a retest.
+  # Every push onto the main branch triggers a retest.
   push:
     branches:
       - master
-      - v12-branch
   # All pull_requests trigger a retest.
   pull_request:
+  workflow_dispatch:
 
 jobs:
 
   mac:
     strategy:
       fail-fast: false
-    runs-on: macos-latest
+      matrix:
-    name: '🍏 macOS'
+        libvvp: [true]
+        suffix: [true]
+    runs-on: macos-15-intel
+    name: 🍏 macOS${{ matrix.libvvp && ' +libvvp' || '' }}${{ matrix.suffix && ' +suffix' || '' }}
     steps:
 
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v6
 
     - name: Install dependencies
       run: |
@@ -27,46 +30,66 @@ jobs:
     - name: Build, check and install
       run: |
         export PATH="/usr/local/opt/bison/bin:$PATH"
+        CONFIG_OPTS="--enable-libveriuser"
+        if [ "${{ matrix.libvvp }}" = "true" ]; then
+            CONFIG_OPTS="$CONFIG_OPTS --enable-libvvp"
+        fi
+        if [ "${{ matrix.suffix }}" = "true" ]; then
+            CONFIG_OPTS="$CONFIG_OPTS --enable-suffix"
+        fi
         autoconf
-        ./configure
+        ./configure $CONFIG_OPTS
-        make check
+        make -j$(nproc) check
         sudo make install
 
     - name: Test
-      run: ./.github/test.sh
+      run: |
+        make check-installed
 
 
   lin:
     strategy:
       fail-fast: false
       matrix:
-        os: [
+        os: ['22.04', '24.04']
-          '20.04',
+        # libvvp: [false, true]
-          '22.04'
+        # suffix: [false, true]
-        ]
     runs-on: ubuntu-${{ matrix.os }}
-    name: '🐧 Ubuntu ${{ matrix.os }}'
+    name: 🐧 Ubuntu ${{ matrix.os }}${{ matrix.libvvp && ' +libvvp' || '' }}${{ matrix.suffix && ' +suffix' || '' }}
     steps:
 
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v6
 
     - name: Install dependencies
       run: |
         sudo apt update -qq
-        sudo apt install -y make g++ git bison flex gperf libreadline-dev autoconf python3-sphinx
+        sudo apt install -y make g++ git bison flex gperf libreadline-dev libbz2-dev autoconf python3-venv
+        python3 -m venv .venv
+        . .venv/bin/activate
+        pip install --upgrade pip
+        pip install -r Documentation/requirements.txt
 
     - name: Build, check and install
       run: |
+        CONFIG_OPTS="--enable-libveriuser"
+        if [ "${{ matrix.libvvp }}" = "true" ]; then
+            CONFIG_OPTS="$CONFIG_OPTS --enable-libvvp"
+        fi
+        if [ "${{ matrix.suffix }}" = "true" ]; then
+            CONFIG_OPTS="$CONFIG_OPTS --enable-suffix"
+        fi
         autoconf
-        ./configure
+        ./configure $CONFIG_OPTS
-        make check
+        make -j$(nproc) check
         sudo make install
 
     - name: Test
-      run: ./.github/test.sh
+      run:
+        make check-installed
 
     - name: Documentation
       run: |
+        . .venv/bin/activate
         cd Documentation
         make html
 
@@ -75,11 +98,14 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        include: [
+        msystem: [MINGW64, UCRT64, CLANG64]
-          { msystem: MINGW64, arch: x86_64 },
+        # libvvp: [false, true]
-          { msystem: MINGW32, arch: i686 }
+        # suffix: [false, true]
-        ]
+        include:
-    name: 🟪 ${{ matrix.msystem}} · ${{ matrix.arch }}
+          - { msystem: MINGW64, env: x86_64 }
+          - { msystem: UCRT64,  env: ucrt-x86_64 }
+          - { msystem: CLANG64, env: clang-x86_64 }
+    name: 🟪 ${{ matrix.msystem }}${{ matrix.libvvp && ' +libvvp' || '' }}${{ matrix.suffix && ' +suffix' || '' }}
     defaults:
       run:
         shell: msys2 {0}
@@ -90,7 +116,7 @@ jobs:
     - run: git config --global core.autocrlf input
       shell: bash
 
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v6
 
     - uses: msys2/setup-msys2@v2
       with:
@@ -99,21 +125,37 @@ jobs:
         install: >
           git
           base-devel
-          gperf
+          python-pip
-          mingw-w64-${{ matrix.arch }}-toolchain
+          mingw-w64-${{ matrix.env }}-perl
+
+    - uses: actions/setup-python@v6
+      with:
+        python-version: '>=3.5'
 
     - name: Build and check
       run: |
         cd msys2
+        CONFIG_OPTS=""
+        if [ ${{ matrix.msystem }} != "CLANG64" ] ; then
+            CONFIG_OPTS="$CONFIG_OPTS --enable-libveriuser"
+        fi
+        if [ "${{ matrix.libvvp }}" = "true" ] ; then
+            CONFIG_OPTS="$CONFIG_OPTS --enable-libvvp"
+        fi
+        if [ "${{ matrix.suffix }}" = "true" ]; then
+            CONFIG_OPTS="$CONFIG_OPTS --enable-suffix"
+        fi
+        export IVL_CONFIG_OPTIONS="$CONFIG_OPTS"
         makepkg-mingw --noconfirm --noprogressbar -sCLf
 
     - name: Install
       run: pacman -U --noconfirm msys2/*.zst
 
     - name: Test
-      run: ./.github/test.sh
+      run: |
+        make check-installed
 
-    - uses: actions/upload-artifact@v2
+    - uses: actions/upload-artifact@v7
       with:
-        name: ${{ matrix.msystem }}-${{ matrix.arch }}
+        name: 🟪 ${{ matrix.msystem }}${{ matrix.libvvp && ' +libvvp' || '' }}
         path: msys2/*.zst

.gitignore

@@ -8,6 +8,10 @@
 *.swp
 *~
 
+# Virtual environments
+.conda/
+.venv/
+
 # Top level generic files
 tags
 TAGS
@@ -17,6 +21,7 @@ cscope.*
 
 # Object files and libraries
 *.[oa]
+*.so
 
 gmon*.out
 gmon*.txt
@@ -30,16 +35,19 @@ Makefile
 /_pli_types.h
 config.h
 /tgt-pcb/pcb_config.h
-/tgt-pcb/fp.cc
-/tgt-pcb/fp.h
-/tgt-pcb/fp.output
-/tgt-pcb/fp_lex.cc
 /tgt-vvp/vvp_config.h
 /tgt-vhdl/vhdl_config.h
+/vhdlpp/vhdlpp_config.h
 /vpi/vpi_config.h
 stamp-*-h
-/version.h
 /version_tag.h
+/version_base.h
+
+/driver-vpi/iverilog-vpi.man
+/driver-vpi/res.rc
+/driver/iverilog.man
+/vvp/libvvp.pc
+/vvp/vvp.man
 
 # Directories
 autom4te.cache
@@ -51,8 +59,6 @@ dep
 *.vpi
 /cadpli/cadpli.vpl
 
-/tgt-blif/Makefile
-
 # lex, yacc and gperf output
 /driver/cflexor.c
 /driver/cfparse.c
@@ -61,14 +67,6 @@ dep
 
 /ivlpp/lexor.c
 
-/vhdlpp/lexor.cc
-/vhdlpp/lexor_keyword.cc
-/vhdlpp/parse.cc
-/vhdlpp/parse.h
-/vhdlpp/parse.output
-/vhdlpp/vhdlpp_config.h
-/vhdlpp/vhdlpp
-
 /lexor.cc
 /lexor_keyword.cc
 /parse.cc
@@ -77,6 +75,17 @@ dep
 /syn-rules.cc
 /syn-rules.output
 
+/tgt-pcb/fp.cc
+/tgt-pcb/fp.h
+/tgt-pcb/fp.output
+/tgt-pcb/fp_lex.cc
+
+/vhdlpp/lexor.cc
+/vhdlpp/lexor_keyword.cc
+/vhdlpp/parse.cc
+/vhdlpp/parse.h
+/vhdlpp/parse.output
+
 /vpi/sdf_lexor.c
 /vpi/sdf_parse.c
 /vpi/sdf_parse.h
@@ -96,17 +105,13 @@ dep
 # Program created files
 /vvp/tables.cc
 
-/iverilog-vpi.man
-/driver-vpi/res.rc
-/driver/iverilog.man
-/vvp/vvp.man
-
 # The executables.
 *.exe
 /driver/iverilog
-/iverilog-vpi
+/driver-vpi/iverilog-vpi
 /ivl
 /ivlpp/ivlpp
+/vhdlpp/vhdlpp
 /vvp/vvp
 
 /ivl.exp
@@ -114,3 +119,4 @@ dep
 
 # Check output
 /check.vvp
+/driver/top.vvp

AStatement.h

@@ -1,7 +1,7 @@
 #ifndef IVL_AStatement_H
 #define IVL_AStatement_H
 /*
- * Copyright (c) 2008-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 2008-2026 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -40,10 +40,13 @@ class AContrib : public Statement {
 
     public:
       AContrib(PExpr*lval, PExpr*rval);
-      ~AContrib();
+      ~AContrib() override;
 
-      virtual void dump(std::ostream&out, unsigned ind) const;
+      AContrib(const AContrib&) = delete;
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
+      AContrib& operator=(const AContrib&) = delete;
+
+      virtual void dump(std::ostream&out, unsigned ind) const override;
+      virtual NetProc* elaborate(Design*des, NetScope*scope) const override;
 
     private:
       PExpr*lval_;
@@ -61,7 +64,7 @@ class AProcess : public LineInfo {
       AProcess(ivl_process_type_t t, Statement*st)
       : type_(t), statement_(st) { }
 
-      ~AProcess();
+      ~AProcess() override;
 
       bool elaborate(Design*des, NetScope*scope) const;
 

BUGS.txt

@@ -1,174 +0,0 @@
-
-HOW TO REPORT BUGS
-
-Before I can fix an error, I need to understand what the problem
-is. Try to explain what is wrong and why you think it is wrong. Please
-try to include sample code that demonstrates the problem. Include a
-description of what Icarus Verilog does that is wrong, and what you
-expect should happen. And include the command line flags passed to the
-compiler to make the error happen. (This is often overlooked, and
-sometimes important.)
-
-* The Compiler Doesn't Compile
-
-If Icarus Verilog doesn't compile, I need to know about the
-compilation tools you are using. Specifically, I need to know:
-
-	- Operating system and processor type,
-	- Compiler w/ version,
-	- Versions of any libraries being linked, and
-	- anything else you think relevant.
-
-Be aware that I do not have at my disposal a porting lab. I have the
-workstation on my desk, a Mac laptop, and the Linux/Intel box with a
-logic analyzer and 'scope hanging off it.
-
-* The Compiler Crashes
-
-No compiler should crash, no matter what kind of garbage is fed to
-it. If the compiler crashes, you definitely found a bug and I need to
-know about it.
-
-Icarus Verilog internally checks its state while it works, and if it
-detects something wrong that it cannot recover from, it will abort
-intentionally. The "assertion failure" message that the program
-prints in the process of dying is very important. It tells me where in
-the source the bad thing happened. Include that message in the bug
-report.
-
-If there are no assertion messages, I need to know that as well.
-
-I also need a complete test program that demonstrates the crash.
-
-* It Doesn't Like My Perfectly Valid Program(tm)
-
-I need to know what you think is right that Icarus Verilog gets
-wrong. Does it reject your "Perfectly Valid Program(tm)" or does it
-compile it but give incorrect results? The latter is the most
-insidious as it doesn't scream out to be fixed unless someone is
-watching closely. However, if I get a sample program from you, and I
-can compile it, and I run it and nuclear junk doesn't fall from the
-sky, I'm moving on to the next problem.
-
-So, if your program doesn't compile, tell me so, tell me where the
-error occurs, and include a complete Perfectly Valid Test Program(tm).
-You tell me that it fails to compile for you, and I find that it
-compiles for me, then hooray I fixed it. It can happen, you
-know. What's on my disk is more recent than the latest snapshot.
-
-If your program does compile, but generates incorrect output, I need
-to know what it says and what you think it should say. From this I can
-take your sample program and work on Icarus Verilog until it gets the
-proper results. For this to work, of course, I first need to know what
-is wrong with the output. Spell it out, because I've been known to
-miss the obvious. Compiler writers often get buried in the details of
-the wrong problem.
-
-* It Generates Incorrect Target Code
-
-As Icarus Verilog adds target code generators, there will be cases
-where errors in the output netlist format occur. This is a tough nut
-because I might not have all the tools to test the target format you
-are reporting problems with. However, if you clearly explain what is
-right and wrong about the generated output, I will probably be able
-to fix the problem. It may take a few iterations.
-
-In this case, if possible include not only the sample Verilog program,
-but the generated netlist file(s) and a clear indication of what went
-wrong or what is expected. If it is not clear to me, I will ask for
-clarification.
-
-* The Output is Correct, But Less Than Ideal
-
-If the output is strictly correct, but just not good enough for
-practical use, I would like to know. These sorts of problems are
-likely to be more subjective than a core dump, but are worthy of
-consideration. However, realize that outright errors will get more
-attention than missed optimizations.
-
-THE MAKING OF A GOOD TEST PROGRAM
-
-If at all possible, please submit a complete source file that
-demonstrates the problem. If the error occurs after elaboration,
-please include a top level module in the program that is suitable for
-the target format. If I have to write the module myself, I might not
-write it in a way that tickles the bug. So please, send all the
-Verilog source that I need to invoke the error.
-
-Also, include the command line you use to invoke the compiler. For
-example:
-
-	iverilog -o foo.out -tvvp foo.v
-	iverilog foo.vl -s starthere
-
-If the error occurs with the null target (``-tnull'') then a top level
-module may not be needed as long as the ``-s <name>'' switch is
-given.
-
-So when you send a test case, ask yourself "Can poor overworked Steve
-invoke the error without any Verilog other than what is included?" And
-while we are at it, please place a copyright notice in your test
-program and include a GPL license statement if you can. Your test
-program may find its way into the test suite, and the notices will
-make it all nice and legal. Please look at the existing tests in the
-test suite <http://sourceforge.net/ivtest> for examples of good test
-programs.
-
-RESEARCHING EXISTING/PAST BUGS, AND FILING REPORTS
-
-The URL <https://sourceforge.net/p/iverilog/bugs/> is the main
-bug tracking system, although some users have reported bugs at
-<https://github.com/steveicarus/iverilog/issues/>. Once you believe
-you have found a bug, you may browse the bugs database for existing
-bugs that may be related to yours. You might find that your bug has
-already been fixed in a later release or snapshot. If that's the case,
-then you are set. Also, consider if you are reporting a bug or really
-asking for a new feature, and use the appropriate tracker.
-
- system (although you will also find bug rep
-
-
-The bug database supports basic keyword searches, and you can
-optionally limit your search to active bugs, or fixed bugs. You may
-also browse the bug database, just to get an idea what is still
-broken. You may for example find a related bug that explains your
-symptom.
-
-The root page of the bug report database describes how to submit your
-completed bug report.
-
-HOW TO SEND PATCHES
-
-Bug reports with patches are very welcome, especially if they are
-formatted such that I can inspect them, decide that they are obviously
-correct, and apply them without worry.
-
-I prefer patches generated by the git source code tracking system. If
-you are editing the source, you really should be using the latest
-version from git. Please see the developer documentation for more
-detailed instructions -- <http://iverilog.wikia.com/wiki/>.
-
-When you make a patch, submit it to the "Patches" tracker at
-<https://sourceforge.net/p/iverilog/patches/>. Patches added to
-the "Patches" tracker enter the developer workflow, are checked,
-applied to the appropriate git branch, and are pushed. Then the
-tracker item is closed.
-
-If you send patches, *please* tell me what this patch is supposed to
-accomplish, which branch you intended to be patched, and if
-appropriate include a test program that demonstrates the efficacy of
-the patch. (If I have no idea what the patch is for, I will ask for
-clarification before applying it.)
-
-COPYRIGHT ISSUES
-
-Icarus Verilog is Copyright (c) 1998-2018 Stephen Williams except
-where otherwise noted. Minor patches are covered as derivative works
-(or editorial comment or whatever the appropriate legal term is) and
-folded into the rest of ivl. However, if a submission can reasonably
-be considered independently copyrightable, it's yours and I encourage
-you to claim it with appropriate copyright notices. This submission
-then falls under the "otherwise noted" category.
-
-I must insist that any copyright material submitted for inclusion
-include the GPL license notice as shown in the rest of the source.

Documentation/conf.py

@@ -20,7 +20,7 @@
 # -- Project information -----------------------------------------------------
 
 project = 'Icarus Verilog'
-copyright = '2022, Stephen Williams'
+copyright = '2024-2026, Stephen Williams'
 author = 'Stephen Williams'
 
 # The short X.Y version
@@ -58,7 +58,7 @@ master_doc = 'index'
 #
 # This is also used if you do content translation via gettext catalogs.
 # Usually you set "language" from the command line for these cases.
-language = None
+language = 'en'
 
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
@@ -68,24 +68,40 @@ exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
 # The name of the Pygments (syntax highlighting) style to use.
 pygments_style = 'sphinx'
 
+# If no language is specified, use none
+highlight_language = 'none'
 
 # -- Options for HTML output -------------------------------------------------
 
+# A dictionary of values to pass into the template engine's context for all pages.
+#
+html_context = {
+    # Edit this page
+    "source_type": "github",
+    "source_user": "steveicarus",
+    "source_repo": "iverilog",
+    "source_version": "master",
+    "source_docs_path": "/Documentation/",
+}
+
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
-html_theme = 'alabaster'
+html_theme = 'shibuya'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
 #
-# html_theme_options = {}
+html_theme_options = {
+    "github_url": "https://github.com/steveicarus/iverilog",
+}
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
+#html_static_path = ['_static']
+html_static_path = []
 
 # Custom sidebar templates, must be a dictionary that maps document names
 # to template names.
@@ -97,6 +113,7 @@ html_static_path = ['_static']
 #
 # html_sidebars = {}
 
+html_favicon = 'favicon.ico'
 
 # -- Options for HTMLHelp output ---------------------------------------------
 
@@ -138,7 +155,7 @@ latex_documents = [
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
 man_pages = [
-    (master_doc, 'icarusverilog', 'Icarus Verilog Documentation',
+    (master_doc, 'iverilog-docs', 'Icarus Verilog Documentation',
      [author], 1)
 ]
 
@@ -152,4 +169,4 @@ texinfo_documents = [
     (master_doc, 'IcarusVerilog', 'Icarus Verilog Documentation',
      author, 'IcarusVerilog', 'One line description of project.',
      'Miscellaneous'),
-]
+]

Documentation/developer/getting_started.rst

@@ -1,5 +1,5 @@
 
-Getting Started as a Contributer
+Getting Started as a Contributor
 ================================
 
 Icarus Verilog development is centered around the github repository at
@@ -103,6 +103,22 @@ 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).
 
+.. code-block:: none
+
+  --enable-libvvp
+
+The vvp program 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.
+
+.. code-block:: none
+
+  --enable-libveriuser
+
+PLI version 1 (the ACC and TF routines) were deprecated in IEEE 1364-2005.
+These are supported in Icarus Verilog by the libveriuser library and cadpli
+module. Starting with v13, these will only be built if this option is used.
+
 A debug options is:
 
 .. code-block:: none
@@ -111,7 +127,7 @@ A debug options is:
 
 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
-need when checking for basic errors with valgrind.
+needed when checking for basic errors with valgrind.
 
 Compiling on Linux
 ------------------
@@ -163,13 +179,21 @@ example:
 .. code-block:: console
 
   % cd ivtest
-  % ./vvp_reg.pl --strict
+  % ./vvp_reg.pl
+  % ./vvp_reg.py
+  % ./vpi_reg.pl
 
 will run all the regression tests for the simulation engine. (This is what
-most people will want to do.) You should rerun this test before submitting
+most people will want to do.) You should rerun these tests before submitting
 patches to the developers. Also, if you are adding a new feature, you should
 add test programs to the regression test suite to validate your new feature
-(or bug fix.)
+(or bug fix.). The python script is the preferred method to add new tests.
+
+All of these scripts take other options to test various configurations. What
+options are supported can be found by using the ``-h/--help`` argument. There
+is also a separate ``vlog95_reg.pl`` script for testing the vlog95 translation
+of the original tests. This is integrated into the existing Python test script
+for the new tests.
 
 Note that pull requests will be required to pass these regression tests before
 being merged.
@@ -218,8 +242,7 @@ first push the branch up to github:
 Then go to github.com to create your pull request. `Create your pull request
 against the "master" branch of the upstream repository
 <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork>`_,
-or the version branch that you are working on. Your pull reuqest will be run
+or the version branch that you are working on. Your pull request will be run
 through continuous integration, and reviewed by one of the main
 authors. Feedback may be offered to your PR, and once accepted, an approved
 individual will merge it for you. Then you are done.
-

Documentation/developer/glossary.rst

@@ -1,4 +1,7 @@
 
+Glossary
+========
+
 Throughout Icarus Verilog descriptions and source code, I use a
 variety of terms and acronyms that might be specific to Icarus
 Verilog, have an Icarus Verilog specific meaning, or just aren't
@@ -22,7 +25,7 @@ UDP     - User Defined Primitive
     syntax for defining them is described in the LRM.
 
 
-VPI     -
+VPI     - Verilog Procedural Interface
     This is the C API that is defined by the Verilog standard, and
     that Icarus Verilog partially implements. See also PLI.
 
@@ -34,6 +37,12 @@ VVM     - Verilog Virtual Machine
 
 VVP     - Verilog Virtual Processor
     This is the Icarus Verilog runtime that reads in custom code in a
-    form that I call "VVP Assembly". See the vvp/ directory for
+    form that I call "VVP Assembly".
-    documentation on that.
 
+LPM     - Library of Parameterized Modules
+    LPM (Library of Parameterized Modules) is EIS-IS standard 103-A. It is
+    a standard library of abstract devices that are designed to be close
+    enough to the target hardware to be easily translated, yet abstract
+    enough to support a variety of target technologies without excessive
+    constraints. Icarus Verilog uses LPM internally to represent idealized
+    hardware, especially when doing target neutral synthesis.

Documentation/developer/guide/cadpli/cadpli.rst

@@ -1,7 +1,6 @@
 
-CADENCE PLI1 MODULES
+Cadence PLI1 Modules
-
+====================
-   Copyright 2003 Stephen Williams
 
 With the cadpli module, Icarus Verilog is able to load PLI1
 applications that were compiled and linked to be dynamic loaded by
@@ -17,7 +16,7 @@ is invoked by the usual -m flag to iverilog or vvp. This module in
 turn scans the extended arguments, looking for +cadpli= arguments. The
 latter specify the share object and bootstrap function for running the
 module. For example, to run the module product.so, that has the
-bootstrap function "my_boot":
+bootstrap function "my_boot"::
 
     vvp -mcadpli a.out -cadpli=./product.so:my_boot
 

Documentation/developer/guide/index.rst

@@ -1,21 +1,24 @@
 
-Developer Quick Start for Icarus Verilog
+Developer Guide
+===============
 
-The documentation for getting, building and installing Icarus Verilog
+The developer guide is intended to give you a gross structure of the
-is kept and maintained at the iverilog documentation wiki at
-<http://iverilog.wikia.com>. See the Installation Guide for getting
-the current source from the git repository (and how to use the git
-repository) and see the Developer Guide for instructions on
-participating in the Icarus Verilog development process. That
-information will not be repeated here.
-
-What this documentation *will* cover is the gross structure of the
 Icarus Verilog compiler source. This will help orient you to the
 source code itself, so that you can find the global parts where you
 can look for even better detail.
 
+The documentation for getting, building and installing Icarus Verilog
+is kept and maintained at :doc:`Getting Started as a Contributor <../getting_started>`
 
-* Compiler Components
+See the Installation Guide for getting the current source from the git
+repository (and how to use the git repository) and see the Developer Guide
+for instructions on participating in the Icarus Verilog development process.
+That information will not be repeated here.
+
+Scroll down to a listing with further readings.
+
+Compiler Components
+-------------------
 
 - The compiler driver (driver/)
 
@@ -26,28 +29,29 @@ subcommands to perform the steps of compilation.
 - The preprocessor (ivlpp/)
 
 This implements the Verilog pre-processor. In Icarus Verilog, the
-compiler directives `define, `include, `ifdef and etc. are implemented
+compiler directives \`define, \`include, \`ifdef and etc. are implemented
 in an external program. The ivlpp/ directory contains the source for
 this program.
 
-- The core compiler (this directory)
+- The core compiler (root directory)
 
 The "ivl" program is the core that does all the Verilog compiler
 processing that is not handled elsewhere. This is the main core of the
 Icarus Verilog compiler, not the runtime. See below for more details
 on the core itself.
 
-- The loadable code generators (tgt-*/)
+- The loadable code generators (tgt-\*/)
 
 This core compiler, after it is finished with parsing and semantic
 analysis, uses loadable code generators to emit code for supported
-targets. The tgt-*/ directories contains the source for the target
+targets. The tgt-\*/ directories contains the source for the target
 code generators that are bundled with Icarus Verilog. The tgt-vvp/
 directory in particular contains the code generator for the vvp
 runtime.
 
 
-* Runtime Components
+Runtime Components
+------------------
 
 - The vvp runtime (vvp/)
 
@@ -75,7 +79,8 @@ PLI-1 code written for Verilog-XL. This directory contains the source
 for the module that provides the Cadence PLI interface.
 
 
-* The Core Compiler
+The Core Compiler
+-----------------
 
 The "ivl" binary is the core compiler that does the heavy lifting of
 compiling the Verilog source (including libraries) and generating the
@@ -147,3 +152,18 @@ parameters must be intermingled with the elaboration of scopes because
 the exact values of parameters may impact the scopes created (imagine
 generate schemes and instance arrays) and the created scopes in turn
 create new parameters that need override and evaluation.
+
+Further Reading
+---------------
+
+For further information on the individual parts of Icarus Verilog, see this listing:
+
+.. toctree::
+   :maxdepth: 2
+
+   ivl/index
+   vvp/index
+   tgt-vvp/tgt-vvp
+   vpi/index
+   cadpli/cadpli
+   misc/index

Documentation/developer/guide/ivl/attributes.rst

@@ -1,14 +1,19 @@
 
-ATTRIBUTE NAMING CONVENTIONS
+Icarus Verilog Attributes
+=========================
+
+Attribute Naming Conventions
+----------------------------
 
 Attributes that are specific to Icarus Verilog, and are intended to be
-of use to programmers, start with the prefix "ivl_".
+of use to programmers, start with the prefix "ivl\_".
 
 Attributes with the "_ivl_" prefix are set aside for internal
 use. They may be generated internally by the compiler. They need not
 be documented here.
 
-ATTRIBUTES TO CONTROL SYNTHESIS
+Attributes To Control Synthesis
+-------------------------------
 
 The following is a summary of Verilog attributes that Icarus Verilog
 understands within Verilog source files to control synthesis
@@ -23,7 +28,7 @@ warning.)
 
 * Attributes for "always" and "initial" statements
 
-(* ivl_combinational *)
+(\* ivl_combinational \*)
 
     This attribute tells the compiler that the statement models
     combinational logic. If the compiler finds that it cannot make
@@ -34,14 +39,14 @@ warning.)
     latches or flip-flops where the user intended combinational
     logic.
 
-(* ivl_synthesis_on *)
+(\* ivl_synthesis_on \*)
 
     This attribute tells the compiler that the marked always statement
     is synthesizable. The compiler will attempt to synthesize the
     code in the marked "always" statement. If it cannot in any way
     synthesize it, then it will report an error.
 
-(* ivl_synthesis_off *)
+(\* ivl_synthesis_off \*)
 
     If this value is attached to an "always" statement, then the
     compiler will *not* synthesize the "always" statement. This can be
@@ -50,7 +55,7 @@ warning.)
 
 * Attributes for modules
 
-(* ivl_synthesis_cell *)
+(\* ivl_synthesis_cell \*)
 
     If this value is attached to a module during synthesis, that
     module will be considered a target architecture primitive, and
@@ -60,7 +65,7 @@ warning.)
 
 * Attributes for signals (wire/reg/integer/tri/etc.)
 
-(* PAD = "<pad assignment list>" *)
+(\* PAD = "<pad assignment list>" \*)
 
     If this attribute is attached to a signal that happens to be a
     root module port, then targets that support it will use the string
@@ -73,9 +78,10 @@ warning.)
 [ none defined yet ]
 
 
-MISC
+Misc
+----
 
-(* _ivl_schedule_push *)
+(\* _ivl_schedule_push \*)
 
     If this attribute is attached to a thread object (always or
     initial statement) then the vvp code generator will generate code

Documentation/developer/guide/ivl/index.rst

@@ -0,0 +1,12 @@
+
+IVL - The Core Compiler
+=======================
+
+.. toctree::
+   :maxdepth: 1
+
+   netlist
+   attributes
+   ivl_target
+   lpm
+   t-dll

Documentation/developer/guide/ivl/ivl_target.rst

@@ -1,6 +1,6 @@
 
-Loadable Target API (ivl_target.h)
+Loadable Target API (ivl_target)
-==================================
+================================
 
 In addition to the standard VPI API, Icarus Verilog supports a non-standard
 loadable target module API. This API helps C programmers write modules that
@@ -104,3 +104,28 @@ Installing the Target Module
 Finally, the "empty.conf", the "empty-s.conf" and the "empty.tgt" files need
 to be installed. Where they go depends on your system, but in Linux they are
 normally installed in "/usr/lib/ivl".
+
+
+LPM Devices
+-----------
+
+All LPM devices support a small set of common LPM functions, as
+described in the ivl_target header file. The ivl_lpm_t object has a
+type enumerated by ivl_lpm_type_t, and that type is accessible via the
+ivl_lpm_type function.
+
+The following are type specific aspects of LPM devices.
+
+* IVL_LPM_UFUNC
+
+This LPM represents a user defined function. It is a way to connect
+behavioral code into a structural network. The UFUNC device has a
+vector output and a set of inputs. The ivl_lpm_define function returns
+the definition as an ivl_scope_t object.
+
+The output vector is accessible through the ivl_lpm_q, and the output
+has the width defined by ivl_lpm_width. This similar to most every
+other LPM device with outputs.
+
+There are ivl_lpm_size() input ports, each with the width
+ivl_lpm_data2_width(). The actual nexus is indexed by ivl_lpm_data2().

Documentation/developer/guide/ivl/lpm.rst

@@ -1,5 +1,6 @@
 
-WHAT IS LPM
+What Is LPM
+===========
 
 LPM (Library of Parameterized Modules) is EIS-IS standard 103-A. It is
 a standard library of abstract devices that are designed to be close
@@ -13,11 +14,12 @@ generates, because the LPM devices are translated into technology
 specific devices by the final code generator or target specific
 optimizers.
 
-INTERNAL USES OF LPM
+Internal Uses Of LPM
+--------------------
 
 Internally, Icarus Verilog uses LPM devices to represent the design in
 abstract, especially when synthesizing such functions as addition,
-flip-flops, etc. The ``synth'' functor generates LPM modules when
+flip-flops, etc. The `synth` functor generates LPM modules when
 interpreting procedural constructs. The functor generates the LPM
 objects needed to replace a behavioral description, and uses
 attributes to tag the devices with LPM properties.

Documentation/developer/guide/ivl/netlist.rst

@@ -1,27 +1,6 @@
-/*
- * Copyright (c) 1998-1999 Stephen Williams (steve@icarus.com)
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
- */
 
-
+Netlist Format
-Note that the netlist.h header contains detailed descriptions of how
+==============
-things work. This is just an overview.
-
-NETLIST FORMAT
 
 The output from the parse and elaboration steps is a "netlist" rooted
 in a Design object. Parsing translates the design described in the
@@ -35,7 +14,8 @@ translating it to a (hopefully) better netlist after each step. The
 complete netlist is then passed to the code generator, the emit
 function, where the final code (in the target format) is produced.
 
-STRUCTURAL ITEMS: NetNode and NetNet
+Structural Items: NetNode and NetNet
+------------------------------------
 
 Components and wires, memories and registers all at their base are
 either NetNode objects or NetNet objects. Even these classes are
@@ -56,7 +36,8 @@ destructors for nets and nodes automatically arrange for pins to be
 disconnected when the item is deleted, so that the netlist can be
 changed during processing.
 
-STRUCTURAL LINKS
+Structural Links
+----------------
 
 The NetNode and NetNet classes contain arrays of Link objects, one
 object per pin. Each pin is a single bit. The Link objects link to all
@@ -88,12 +69,13 @@ Currently, a link has 3 possible direction properties:
 		   three-state.)
 
 
-BEHAVIORAL ITEMS: NetProcTop, NetProc and derived classes
+Behavioral Items: NetProcTop, NetProc and derived classes
+---------------------------------------------------------
 
 Behavioral items are not in general linked to the netlist. Instead,
 they represent elaborated behavioral statements. The type of the object
 implies what the behavior of the statement does. For example, a
-NetCondit object represents an ``if'' statement, and carries a
+NetCondit object represents an `if` statement, and carries a
 condition expression and up to two alternative sub-statements.
 
 At the root of a process is a NetProcTop object. This class carries a
@@ -104,7 +86,8 @@ tree is the NetProcTop object. The Design class keeps a list of the
 elaborated NetProcTop objects. That list represents the list of
 processes in the design.
 
-INTERACTION OF BEHAVIORAL AND STRUCTURAL: NetAssign_
+Interaction Of Behavioral And Structural: NetAssign\_
+-----------------------------------------------------
 
 The behavioral statements in a Verilog design effect the structural
 aspects through assignments to registers. Registers are structural
@@ -113,26 +96,27 @@ statement through pins. This implies that the l-value of an assignment
 is structural. It also implies that the statement itself is
 structural, and indeed it is derived from NetNode.
 
-The NetAssign_ class is also derived from the NetProc class because
+The NetAssign\_ class is also derived from the NetProc class because
 what it does is brought on by executing the process. By multiple
 inheritance we have therefore that the assignment is both a NetNode
-and a NetProc. The NetAssign_ node has pins that represent the l-value
+and a NetProc. The NetAssign\_ node has pins that represent the l-value
 of the statement, and carries behavioral expressions that represent
 the r-value of the assignment.
 
-MEMORIES
+Memories
+--------
 
 The netlist form includes the NetMemory type to hold the content of a
 memory. Instances of this type represent the declaration of a memory,
 and occur once for each memory. References to the memory are managed
-by the NetEMemory and NetAssignMem_ classes.
+by the NetEMemory and NetAssignMem\_ classes.
 
 An instance of the NetEMemory class is created whenever a procedural
 expression references a memory element. The operand is the index to
 use to address (and read) the memory.
 
-An instance of the NetAssignMem_ class is created when there is a
+An instance of the NetAssignMem\_ class is created when there is a
-procedural assignment to the memory. The NetAssignMem_ object
+procedural assignment to the memory. The NetAssignMem\_ object
 represents the l-value reference (a write) to the memory. As with the
 NetEMemory class, this is a procedural reference only.
 
@@ -143,13 +127,14 @@ unconnected for now, because memories cannot appear is l-values of
 continuous assignments. However, the synthesis functor may connect
 signals to the write control lines to get a fully operational RAM.
 
-By the time elaboration completes, there may be many NetAssignMem_,
+By the time elaboration completes, there may be many NetAssignMem\_,
 NetEMemory and NetRamDq objects referencing the same NetMemory
 object. Each represents a port into the memory. It is up to the
 synthesis steps (and the target code) to figure out what to do with
 these ports.
 
-EXPRESSIONS
+Expressions
+-----------
 
 Expressions are represented as a tree of NetExpr nodes. The NetExpr
 base class contains the core methods that represent an expression
@@ -168,7 +153,8 @@ However, typical expressions the behavioral description are
 represented as a tree of NetExpr nodes. The derived class of the node
 encodes what kind of operator the node represents.
 
-EXPRESSION BIT WIDTH
+Expression Bit Width
+--------------------
 
 The expression (represented by the NetExpr class) has a bit width that
 it either explicitly specified, or implied by context or contents.
@@ -200,14 +186,17 @@ determined and please adapt. If the expression cannot reasonably
 adapt, it will return false. Otherwise, it will adjust bit widths and
 return true.
 
-XXXX I do not yet properly deal with cases where elaboration knows for
+::
-XXXX certain that the bit width does not matter. In this case, I
-XXXX really should tell the expression node about it so that it can
-XXXX pick a practical (and optimal) width.
 
-INTERACTION OF EXPRESSIONS AND STRUCTURE: NetESignal
+    I do not yet properly deal with cases where elaboration knows for
+    certain that the bit width does not matter. In this case, I
+    really should tell the expression node about it so that it can
+    pick a practical (and optimal) width.
 
-The NetAssign_ class described above is the means for processes to
+Interaction Of Expressions And Structure: NetESignal
+----------------------------------------------------
+
+The NetAssign\_ class described above is the means for processes to
 manipulate the net, but values are read from the net by NetESignal
 objects. These objects are class NetExpr because they can appear in
 expressions (and have width). They are not NetNode object, but hold
@@ -215,7 +204,8 @@ pointers to a NetNet object, which is used to retrieve values with the
 expression is evaluated.
 
 
-HIERARCHY IN NETLISTS
+Hierarchy In Netlists
+---------------------
 
 The obvious hierarchical structure of Verilog is the module. The
 Verilog program may contain any number of instantiations of modules in
@@ -236,7 +226,8 @@ boundaries. This makes coding of netlist transform functions such as
 constant propagation more effective and easier to write.
 
 
-SCOPE REPRESENTATION IN NETLISTS
+Scope Representation In Netlists
+--------------------------------
 
 In spite of the literal flattening of the design, scope information is
 preserved in the netlist, with the NetScope class. The Design class
@@ -258,7 +249,8 @@ scope. Overrides are managed during the scan, and once the scan is
 complete, defparam overrides are applied.
 
 
-TASKS IN NETLISTS
+Tasks In Netlists
+-----------------
 
 The flattening of the design does not include tasks and named
 begin-end blocks. Tasks are behavioral hierarchy (whereas modules are
@@ -268,7 +260,8 @@ recurse. (The elaboration process does reserve the right to flatten
 some task calls. C++ programmers recognize this as inlining a task.)
 
 
-TIME SCALE IN NETLISTS
+Time Scale In Netlists
+----------------------
 
 The Design class and the NetScope classes carry time scale and
 resolution information of the elaborated design. There is a global

Documentation/developer/guide/ivl/t-dll.rst

@@ -1,5 +1,6 @@
 
-LOADABLE TARGETS
+Loadable Targets
+================
 
 Icarus Verilog supports dynamically loading code generator modules to
 perform the back-end processing of the completed design. The user
@@ -12,24 +13,28 @@ compiler calls to pass the design to it, and the module in turn uses a
 collection of functions in the core (the API) to access details of the
 design.
 
-LOADING TARGET MODULES
+Loading Target Modules
+----------------------
 
 The target module loader is invoked with the ivl flag "-tdll". That
 is, the DLL loader is a linked in target type. The name of the target
 module to load is then specified with the DLL flag, i.e. "-fDLL=<path>".
 
-COMPILING TARGET MODULES
+Compiling Target Modules
+------------------------
 
 <write me>
 
-LOADABLE TARGET MODULE API
+Loadable Target Module Api
+--------------------------
 
 The target module API is defined in the ivl_target.h header file. This
 declares all the type and functions that a loadable module needs to
 access the design.
 
 
-ABOUT SPECIFIC EXPRESSION TYPES
+About Specific Expression Types
+-------------------------------
 
 In this section find notes about the various kinds of expression
 nodes. The notes here are in addition to the more general

Documentation/developer/guide/misc/ieee1364-notes.rst

@@ -1,9 +1,6 @@
 
-NOTE: THE CONTENTS OF THIS FILE ARE BEING MOVED TO THE DOCUMENTATION
+IEEE1364 Notes
-WIKI AT http://iverilog.wikia.com. PLEASE ADD NEW ENTRIES THERE.
+==============
-
-                Icarus Verilog vs. IEEE1364
-                Copyright 2000 Stephen Williams
 
 The IEEE1364 standard is the bible that defines the correctness of the
 Icarus Verilog implementation and behavior of the compiled
@@ -19,7 +16,8 @@ and common to write programs that produce different results when run
 by different Verilog implementations.
 
 
-STANDARDIZATION ISSUES
+Standardization Issues
+----------------------
 
 These are some issues where the IEEE1364 left unclear, unspecified or
 simply wrong. I'll try to be precise as I can, and reference the
@@ -29,19 +27,19 @@ affect the language.
 
 * OBJECTS CAN BE DECLARED ANYWHERE IN THE MODULE
 
-Consider this module:
+Consider this module::
 
     module sample1;
         initial foo = 1;
-	reg foo;
+    reg foo;
-	wire tmp = bar;
+    wire tmp = bar;
-	initial #1 $display("foo = %b, bar = %b", foo, tmp);
+    initial #1 $display("foo = %b, bar = %b", foo, tmp);
     endmodule
 
-Notice that the ``reg foo;'' declaration is placed after the first
+Notice that the `reg foo;` declaration is placed after the first
 initial statement. It turns out that this is a perfectly legal module
 according to the -1995 and -2000 versions of the standard. The
-statement ``reg foo;'' is a module_item_declaration which is in turn a
+statement `reg foo;` is a module_item_declaration which is in turn a
 module_item. The BNF in the appendix of IEEE1364-1995 treats all
 module_item statements equally, so no order is imposed.
 
@@ -53,12 +51,12 @@ textually before they are referenced." Such statements simply do not
 exist. (Personally, I think it is fine that they don't.)
 
 The closest is the rules for implicit declarations of variables that
-are otherwise undeclared. In the above example, ``bar'' is implicitly
+are otherwise undeclared. In the above example, `bar` is implicitly
-declared and is therefore a wire. However, although ``initial foo = 1;''
+declared and is therefore a wire. However, although `initial foo = 1;`
 is written before foo is declared, foo *is* declared within the
 module, and declared legally by the BNF of the standard.
 
-Here is another example:
+Here is another example::
 
     module sample2;
 	initial x.foo = 1;
@@ -80,7 +78,7 @@ Icarus Verilog interprets both of these examples according to "The
 Standard As I Understand It." However, commercial tools in general
 break down with these programs. In particular, the first example
 may generate different errors depending on the tool. The most common
-error is to claim that ``foo'' is declared twice, once (implicitly) as
+error is to claim that `foo` is declared twice, once (implicitly) as
 a wire and once as a reg.
 
 So the question now becomes, "Is the standard broken, or are the tools
@@ -107,7 +105,7 @@ ordering, by requiring that modules that are used be first defined.
 * TASK AND FUNCTION PARAMETERS CANNOT HAVE EXPLICIT TYPES
 
 Consider a function negate that wants to take a signed integer value
-and return its negative:
+and return its negative::
 
 	function integer negate;
 	    input [15:0] val;
@@ -123,7 +121,7 @@ the bit pattern of a 16bit number, but that is not the point. What's
 needed is clarification on whether an input can be declared in the
 port declaration as well as in the contained block declaration.
 
-As I understand the situation, this should be allowed:
+As I understand the situation, this should be allowed::
 
 	function integer negate;
 	    input [15:0] val;
@@ -152,10 +150,10 @@ commercial tools seem to work similarly.
 
 * ROUNDING OF TIME
 
-When the `timescale directive is present, the compiler is supposed to
+When the \`timescale directive is present, the compiler is supposed to
 round fractional times (after scaling) to the nearest integer. The
 confusing bit here is that it is apparently conventional that if the
-`timescale directive is *not* present, times are rounded towards zero
+\`timescale directive is *not* present, times are rounded towards zero
 always.
 
 
@@ -173,12 +171,12 @@ take it that x is allowed, as that is what Verilog-XL does.
 
 * REPEAT LOOPS vs. REPEAT EVENT CONTROL
 
-There seems to be ambiguity in how code like this should be parsed:
+There seems to be ambiguity in how code like this should be parsed::
 
 	repeat (5) @(posedge clk) <statement>;
 
 There are two valid interpretations of this code, from the
-IEEE1364-1995 standard. One looks like this:
+IEEE1364-1995 standard. One looks like this::
 
     procedural_timing_control_statement ::=
           delay_or_event_control  statement_or_null
@@ -189,7 +187,7 @@ IEEE1364-1995 standard. One looks like this:
 
 If this interpretation is used, then the statement <statement> should
 be executed after the 5th posedge of clk. However, there is also this
-interpretation:
+interpretation::
 
     loop_statement ::=
          repeat ( expression ) statement
@@ -218,7 +216,7 @@ compiler may just as easily choose another width limit, for example
 However, it is not *required* that an implementation truncate at 32
 bits, and in fact Icarus Verilog does not truncate at all. It will
 make the unsized constant as big as it needs to be to hold the value
-accurately. This is especially useful in situations like this;
+accurately. This is especially useful in situations like this::
 
 	    reg [width-1:0] foo = 17179869183;
 
@@ -237,7 +235,7 @@ truncation point.
 
 * UNSIZED EXPRESSIONS AS PARAMETERS TO CONCATENATION {}
 
-The Verilog standard clearly states in 4.1.14:
+The Verilog standard clearly states in 4.1.14::
 
 	"Unsized constant numbers shall not be allowed in
 	concatenations. This is because the size of each
@@ -257,7 +255,7 @@ simple unsized constant is accepted there, even if all the operands of
 all the operators that make up the expression are unsized integers.
 
 This is a semantic problem. Icarus Verilog doesn't limit the size of
-integer constants. This is valid as stated in 2.5.1 Note 3:
+integer constants. This is valid as stated in 2.5.1 Note 3::
 
 	"The number of bits that make up an unsized number
 	(which is a simple decimal number or a number without
@@ -268,6 +266,8 @@ Icarus Verilog will hold any integer constant, so the size will be as
 large as it needs to be, whether that is 64bits, 128bits, or
 more. With this in mind, what is the value of these expressions?
 
+::
+
 	{'h1_00_00_00_00}
 	{'h1 << 32}
 	{'h0_00_00_00_01 << 32}
@@ -301,7 +301,7 @@ generate appropriate error messages.
 
 * MODULE INSTANCE WITH WRONG SIZE PORT LIST
 
-A module declaration like this declares a module that takes three ports:
+A module declaration like this declares a module that takes three ports::
 
 	module three (a, b, c);
 	  input a, b, c;
@@ -309,7 +309,7 @@ A module declaration like this declares a module that takes three ports:
 	endmodule
 
 This is fine and obvious. It is also clear from the standard that
-these are legal instantiations of this module:
+these are legal instantiations of this module::
 
 	three u1 (x,y,z);
 	three u2 ( ,y, );
@@ -320,7 +320,7 @@ In some of the above examples, there are unconnected ports. In the
 case of u4, the pass by name connects only port b, and leaves a and c
 unconnected. u2 and u4 are the same thing, in fact, but using
 positional or by-name syntax. The next example is a little less
-obvious:
+obvious::
 
 	three u4 ();
 
@@ -331,7 +331,7 @@ positional list, then the wrong number of ports is given, but if it is
 an empty by-name list, it is an obviously valid instantiation. So it
 is fine to accept this case as valid.
 
-These are more doubtful:
+These are more doubtful::
 
 	three u5(x,y);
 	three u6(,);
@@ -351,7 +351,7 @@ other.
 
 * UNKNOWN VALUES IN L-VALUE BIT SELECTS
 
-Consider this example:
+Consider this example::
 
 	reg [7:0] vec;
 	wire [4:0] idx = <expr>;
@@ -375,7 +375,7 @@ assignment will have no effect.
 
 The interaction between blocking assignments in procedural code and
 logic gates in gate-level code and expressions is poorly defined in
-Verilog. Consider this example:
+Verilog. Consider this example::
 
    reg a;
    reg b;
@@ -438,7 +438,7 @@ bit and part selects.
 
 * EDGES OF VECTORS
 
-Consider this example:
+Consider this example::
 
    reg [ 5:0] clock;
    always @(posedge clock) [do stuff]
@@ -446,7 +446,7 @@ Consider this example:
 The IEEE1364 standard clearly states that the @(posedge clock) looks
 only at the bit clock[0] (the least significant bit) to search for
 edges. It has been pointed out by some that Verilog XL instead
-implements it as "@(posedge |clock)": it looks for a rise in the
+implements it as `@(posedge |clock)`: it looks for a rise in the
 reduction or of the vector. Cadence Design Systems technical support
 has been rumored to claim that the IEEE1364 specification is wrong,
 but NC-Verilog behaves according to the specification, and thus
@@ -462,7 +462,7 @@ matter.
 The IEEE1364 standard clearly states that in VCD files, the $dumpoff
 section checkpoints all the dumped variables as X values. For reg and
 wire bits/vectors, this obviously means 'bx values. Icarus Verilog
-does this, for example:
+does this, for example::
 
     $dumpoff
     x!
@@ -475,7 +475,7 @@ section of the VCD file. Verilog-XL dumps "r0 !" to set the real
 variables to the dead-zone value of 0.0, whereas other tools, such as
 ModelTech, ignore real variables in this section.
 
-For example (from XL):
+For example (from XL)::
 
     $dumpoff
     r0 !
@@ -485,7 +485,7 @@ For example (from XL):
 Icarus Verilog dumps NaN values for real variables in the
 $dumpoff-$end section of the VCD file. The NaN value is the IEEE754
 equivalent of an unknown value, and so better reflects the unknown
-(during the dead zone) status of the variable, like this:
+(during the dead zone) status of the variable, like this::
 
     $dumpoff
     rNaN !

Documentation/developer/guide/misc/index.rst

@@ -0,0 +1,10 @@
+
+Miscellaneous
+=============
+
+.. toctree::
+   :maxdepth: 1
+
+   ieee1364-notes
+   swift
+   xilinx-hint

Documentation/developer/guide/misc/swift.rst

@@ -1,7 +1,8 @@
 
-SWIFT MODEL SUPPORT FOR Icarus Verilog (PRELIMINARY)
+Swift Model Support (Preliminary)
+=================================
 
-    Copyright 2003 Stephen Williams
+    Copyright 2003-2024 Stephen Williams
 
   NOTE: SWIFT support does not work yet, these are provisional
   instructions, intended to show what's supposed to happen when I get
@@ -24,7 +25,7 @@ When compiling your Verilog design to include a SWIFT model, you need
 to include wrappers for the model you intend to use. You may choose to
 use ncverilog or verilogxl compatible wrappers, they work the
 same. Locate your smartmodel directory, and include it in your command
-file like so:
+file like so::
 
      +libdir+.../smartmodel/sol/wrappers/verilogxl
 
@@ -42,11 +43,11 @@ support for your model.
 * Execution
 
 After your simulation is compiled, run the simulation with the vvp
-command, like this:
+command, like this::
 
       % vvp -mcadpli a.out -cadpli=$LMC_HOME/lib/x86_linux.lib/swiftpli.so:swift_boot
 
-What this command line means is:
+What this command line means is::
 
 	-mcadpli
 	   Include the cadpli compatibility module

Documentation/developer/guide/misc/xilinx-hint.rst

@@ -0,0 +1,113 @@
+
+Xilinx Hint
+===========
+
+For those of you who wish to use Icarus Verilog, in combination with
+the Xilinx back end (Foundation or Alliance), it can be done.  I have
+run some admittedly simple (2300 equivalent gates) designs through this
+setup, targeting a Spartan XCS10.
+
+Verilog:
+--------
+
+Older versions of Icarus Verilog (like 19990814) couldn't synthesize
+logic buried in procedural (flip-flop) assignment.  Newer versions
+(like 20000120) don't have this limitation.
+
+Procedural assignments have to be given one at a time, to be
+"found" by xnfsyn.  Say
+
+::
+
+   always @ (posedge Clk) Y = newY;
+   always @ (posedge Clk) Z = newZ;
+
+rather than
+
+::
+
+   always @ (posedge Clk) begin
+       Y = newY;
+       Z = newZ;
+   end
+
+Steve's xnf.txt covers most buffer and pin constructs, but I had reason
+to use a global clock net not connected to an input pin.  The standard
+Verilog for a buffer, combined with a declaration to turn that into a
+BUFG, is::
+
+   buf BUFG( your_output_here, your_input_here );
+   $attribute(BUFG,"XNF-LCA","BUFG:O,I")
+
+I use post-processing on my .xnf files to add "FAST" attributes to
+output pins.
+
+Running ivl:
+------------
+
+The -F switches are important.  The following order seems to robustly
+generate valid XNF files, and is used by "verilog -X"::
+
+  -Fsynth -Fnodangle -Fxnfio
+
+Generating .pcf files:
+----------------------
+
+The ngdbuild step seems to lose pin placement information that ivl
+puts in the XNF file.  Use xnf2pcf to extract this information to
+a .pcf file, which the Xilinx place-and-route software _will_ pay
+attention to.  Steve says he now makes that information available
+in an NCF file, with -fncf=<path>, but I haven't tested that.
+
+Running the Xilinx back end:
+
+You can presumably use the GUI, but that doesn't fit in Makefiles :-).
+Here is the command sequence in pseudo-shell-script::
+
+  ngdbuild -p $part $1.xnf $1.ngd
+  map -p $part -o map.ncd $1.ngd
+  xnf2pcf <$1.xnf >$1.pcf    # see above
+  par -w -ol 2 -d 0 map.ncd $1.ncd $1.pcf
+  bitgen_flags = -g ConfigRate:SLOW -g TdoPin:PULLNONE -g DonePin:PULLUP \
+                 -g CRC:enable -g StartUpClk:CCLK -g SyncToDone:no \
+                 -g DoneActive:C1 -g OutputsActive:C3 -g GSRInactive:C4 \
+                 -g ReadClk:CCLK -g ReadCapture:enable -g ReadAbort:disable
+  bitgen $1.ncd -l -w $bitgen_flags
+
+The Xilinx software has diarrhea of the temp files (14, not including
+.xnf, .pcf, .ngd, .ncd, and .bit), so this sequence is best done in a
+dedicated directory.  Note in particular that map.ncd is a generic name.
+
+I had reason to run this remotely (and transparently within a Makefile)
+via ssh.  I use the gmake rule::
+
+    %.bit : %.xnf
+        ssh -x -a -o 'BatchMode yes' ${ALLIANCE_HOST} \
+               remote_alliance ${REMOTE_DIR} $(basename $@) 2>&1 < $<
+    scp ${ALLIANCE_HOST}:${REMOTE_DIR}/$@ .
+
+and the remote_alliance script (on ${ALLIANCE_HOST})::
+
+    /bin/csh
+    cd $1
+    cat >! $2.xnf
+    xnf2pcf <$2.xnf >! $2.pcf
+    ./backend $2
+
+There is now a "Xilinx on Linux HOWTO" at http://www.polybus.com/xilinx_on_linux.html
+I haven't tried this yet, it looks interesting.
+
+Downloading:
+------------
+
+I use the XESS (http://www.xess.com/) XSP-10 development board, which
+uses the PC parallel (printer) port for downloading and interaction
+with the host.  They made an old version of their download program
+public domain, posted it at http://www.xess.com/FPGA/xstools.zip ,
+and now there is a Linux port at ftp://ftp.microux.com/pub/pilotscope/xstools.tar.gz .
+
+The above hints are based on my experience with Foundation 1.5 on NT
+(gack) and Alliance 2.1i on Solaris.  Your mileage may vary.  Good luck!
+
+ - Larry Doolittle   <LRDoolittle@lbl.gov>   August 19, 1999
+                                    updated February 1, 2000

Documentation/developer/guide/tgt-vvp/tgt-vvp.rst

@@ -1,7 +1,9 @@
 
-THE VVP TARGET
+The VVP Target
+==============
 
-SYMBOL NAME CONVENTIONS
+Symbol Name Conventions
+-----------------------
 
 There are some naming conventions that the vvp target uses for
 generating symbol names.
@@ -18,7 +20,8 @@ this case the symbol is attached to a functor that is the output of
 the logic device.
 
 
-GENERAL FUNCTOR WEB STRUCTURE
+General Functor Web Structure
+-----------------------------
 
 The net of gates, signals and resolvers is formed from the input
 design. The basic structure is wrapped around the nexus, which is

Documentation/developer/guide/vpi/index.rst

@@ -0,0 +1,9 @@
+
+VPI in Icarus Verilog
+=====================
+
+.. toctree::
+   :maxdepth: 1
+
+   vpi
+   va_math

Documentation/developer/guide/vpi/va_math.rst

@@ -1,17 +1,14 @@
 
-The following is from the README.va_math that was included with the
+Verilog-A math library
-initial contribution of the va_math module. I've removed the parts
+======================
-that are obviously not applicable, i.e. how to compile the library, to
-this bundled version of the library.
 
---------
 License.
 --------
 
   Verilog-A math library built for Icarus Verilog
-  http://www.icarus.com/eda/verilog/
+  https://github.com/steveicarus/iverilog/
 
-  Copyright (C) 2007-2010  Cary R. (cygcary@yahoo.com)
+  Copyright (C) 2007-2024  Cary R. (cygcary@yahoo.com)
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
@@ -27,15 +24,13 @@ License.
   with this program; if not, write to the Free Software Foundation, Inc.,
   51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-
-------------------------------------------
 Standard Verilog-A Mathematical Functions.
 ------------------------------------------
 
 The va_math VPI module implements all the standard math functions provided
 by Verilog-A as Verilog-D system functions. The names are the same except
 like all Verilog-D system functions the name must be prefixed with a '$'.
-For reference the functions are:
+For reference the functions are::
 
   $ln(x)       --  Natural logarithm
   $log10(x)    --  Decimal logarithm
@@ -68,8 +63,6 @@ any other limits placed on the arguments. Most libraries return +-Inf or
 NaN for results that cannot be represented with real numbers. All functions
 return a real result.
 
-
-------------------------------------------
 Standard Verilog-A Mathematical Constants.
 ------------------------------------------
 
@@ -77,7 +70,7 @@ The Verilog-A mathematical constants can be accessed by including the
 "constants.vams" header file. It is located in the standard include
 directory. Recent version of Icarus Verilog (0.9.devel) automatically
 add this directory to the end of the list used to find include files.
-For reference the mathematical constants are:
+For reference the mathematical constants are::
 
   `M_PI        --  Pi
   `M_TWO_PI    --  2*Pi
@@ -94,22 +87,14 @@ For reference the mathematical constants are:
   `M_SQRT2     --  sqrt(2)
   `M_SQRT1_2   --  1/sqrt(2)
 
-
-------------------
 Using the Library.
 ------------------
 
 Just add "-m va_math" to your iverilog command line/command file and
-`include the "constants.vams" file as needed.
+\`include the "constants.vams" file as needed.
 
-------
 Thanks
 ------
 
 I would like to thank Larry Doolittle for his suggestions and
 Stephen Williams for developing Icarus Verilog.
-
-
---------
-The End.
---------

Documentation/developer/guide/vpi/vpi.rst

@@ -1,5 +1,6 @@
 
-HOW IT WORKS
+VPI Modules in Icarus Verilog
+================================
 
 The VPI interface for Icarus Verilog works by creating from a
 collection of PLI applications a single vpi module. The vpi module
@@ -28,16 +29,18 @@ include implementations of the standard system tasks/functions. The
 additional special module names "vhdl_sys.vpi" and "vhdl_textio.vpi"
 include implementations of private functions used to support VHDL.
 
-COMPILING A VPI MODULE
+Compiling A VPI Module
+----------------------
 
-See the iverilog-vpi documentation.
+See the documentation under: :doc:`Using VPI <../../../usage/vpi>`
 
-TRACING VPI USE
+Tracing VPI Use
+---------------
 
 The vvp command includes the ability to trace VPI calls. This is
 useful if you are trying to debug a problem with your code. To
 activate tracing simply set the VPI_TRACE environment variable, with
-the path to a file where trace text gets written. For example:
+the path to a file where trace text gets written. For example::
 
 	setenv VPI_TRACE /tmp/foo.txt
 

Documentation/developer/guide/vvp/debug.rst

@@ -1,5 +1,6 @@
 
-DEBUG AIDS FOR VVP
+Debug Aids For VVP
+==================
 
 Debugging vvp can be fiendishly difficult, so there are some built in
 debugging aids. These are enabled by setting the environment variable
@@ -9,7 +10,7 @@ tools can be enabled as described below.
 * .resolv
 
 The .resolv can print debug information along with a label by
-specifying the debug output label on the .resolv line:
+specifying the debug output label on the .resolv line::
 
    .resolv tri$<label>
 

Documentation/developer/guide/vvp/index.rst

@@ -0,0 +1,13 @@
+
+VVP - Verilog Virtual Processor
+===============================
+
+.. toctree::
+   :maxdepth: 1
+
+   vvp
+   opcodes
+   vpi
+   vthread
+   debug
+

Documentation/developer/guide/vvp/opcodes.rst

@@ -1,11 +1,5 @@
-/*
+Executable Instruction Opcodes
- * Copyright (c) 2001-2021 Stephen Williams (steve@icarus.com)
+==============================
- *
- */
-
-
-
-EXECUTABLE INSTRUCTION OPCODES
 
 Instruction opcodes all start with a % character and have 0 or more
 operands. In no case are there more than 3 operands. This chapter
@@ -32,7 +26,8 @@ experience of implementing it for strings, I'll want to change other
 types around to using this method as well. Keep this in mind whenever
 considering adding new instructions to vvp.
 
-FLAGS
+Flags
+-----
 
 There are up to 16 bits in each thread that are available for
 flags. These are used as destinations for operations that return
@@ -302,7 +297,7 @@ The results of the comparison go into flags 4, 5, 6 and 7:
 The eeq bit is set to 1 if all the bits in the vectors are exactly the
 same, or 0 otherwise. The eq bit is true if the values are logically
 the same. That is, x and z are considered equal. In other words the eq
-bit is the same as ``=='' and the eeq bit ``===''.
+bit is the same as `==` and the eeq bit `===`.
 
 The lt bit is 1 if the left vector is less than the right vector, or 0
 if greater than or equal to the right vector. It is the equivalent of
@@ -534,7 +529,9 @@ an arbitrary value to the event to trigger the event.
 This command emits the provided file and line information along with
 the description when it is executed. The output is sent to stderr and
 the format of the output is:
+
    <file>:<line>: <description>
+
 <file> is the unsigned numeric file index.
 <line> is the unsigned line number.
 <description> is a string, if string is 0 then the following default
@@ -815,6 +812,10 @@ result is pushed back on the vec4 stack.
 
 This opcode multiplies two real words together.
 
+* %neg/wr
+
+This opcode negates the real value on top of the real stack.
+
 * %nand
 
 Perform the bitwise NAND of two vec4 vectors, and push the result. Each
@@ -1338,22 +1339,23 @@ table for the xor is:
 	1 xor 1 --> 0
 	otherwise   x
 
+::
 
-/*
+    /*
- * Copyright (c) 2001-2017 Stephen Williams (steve@icarus.com)
+     * Copyright (c) 2001-2024 Stephen Williams (steve@icarus.com)
- *
+     *
- *    This source code is free software; you can redistribute it
+     *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
+     *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
+     *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
+     *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
+     *    any later version.
- *
+     *
- *    This program is distributed in the hope that it will be useful,
+     *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
+     *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+     *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
+     *    GNU General Public License for more details.
- *
+     *
- *    You should have received a copy of the GNU General Public License
+     *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
+     *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+     *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
- */
+     */

Documentation/developer/guide/vvp/vpi.rst

@@ -1,10 +1,6 @@
-/*
- * Copyright (c) 2001 Stephen Williams (steve@icarus.com)
- *
- */
 
-
+VPI Within VVP
-VPI WITHIN VVP
+==============
 
 System tasks and functions in Verilog are implemented in Icarus
 Verilog by C routines written with VPI. This implies that the vvp
@@ -19,7 +15,8 @@ vvp only implements the ones it needs. The VPI web is added into the
 design using special pseudo-ops that create the needed objects.
 
 
-LOADING VPI MODULES
+Loading VPI Modules
+-------------------
 
 The vvp runtime loads VPI modules at runtime before the parser reads
 in the source files. This gives the modules a chance to register tasks
@@ -38,7 +35,8 @@ the system tasks and functions. The %vpi_call instruction, once compiled,
 carries the vpiHandle of the system task.
 
 
-SYSTEM TASK CALLS
+System Task Calls
+-----------------
 
 A system task call invokes a VPI routine, and makes available to that
 routine the arguments to the system task. The called routine gets
@@ -61,7 +59,8 @@ instruction then only needs to be a %vpi_call with the single parameter
 that is the vpiHandle for the call.
 
 
-SYSTEM FUNCTION CALLS
+System Function Calls
+---------------------
 
 System function calls are similar to system tasks. The only
 differences are that all the arguments are input only, and there is a
@@ -75,7 +74,8 @@ writing a wrapper thread that calls the function when inputs change,
 and that writes the output into the containing expression.
 
 
-SYSTEM TASK/FUNCTION ARGUMENTS
+System Task/Function Arguments
+------------------------------
 
 The arguments to each system task or call are not stored in the
 instruction op-code, but in the vpiSysTfCall object that the compiler
@@ -91,7 +91,8 @@ all this is done, an array of vpiHandles is passed to code to create a
 vpiSysTfCall object that has all that is needed to make the call.
 
 
-SCOPES
+Scopes
+------
 
 VPI can access scopes as objects of type vpiScope. Scopes have names
 and can also contain other sub-scopes, all of which the VPI function
@@ -99,7 +100,7 @@ can access by the vpiInternalScope reference. Therefore, the run-time
 needs to form a tree of scopes into which other scoped VPI objects are
 placed.
 
-A scope is created with a .scope directive, like so:
+A scope is created with a .scope directive, like so::
 
 	<label> .scope "name" [, <parent>];
 		.timescale <units>;
@@ -122,7 +123,7 @@ Objects that place themselves in a scope place themselves in the
 current scope. The current scope is the one that was last mentioned by
 a .scope directive. If the wrong scope is current, the label on a
 scope directive can be used to resume a scope. The syntax works like
-this:
+this::
 
 		.scope <symbol>;
 
@@ -131,7 +132,8 @@ and is used to identify the scope to be resumed. A scope resume
 directive cannot have a label.
 
 
-VARIABLES
+Variables
+---------
 
 Reg vectors (scalars are vectors of length 1) are created by .var
 statements in the source. The .var statement includes the declared
@@ -145,21 +147,23 @@ The VPI interface to variable (vpiReg objects) uses the MSB and LSB
 values that the user defined to describe the dimensions of the
 object.
 
-/*
+::
- * Copyright (c) 2001 Stephen Williams (steve@icarus.com)
+
- *
+    /*
- *    This source code is free software; you can redistribute it
+     * Copyright (c) 2001-2024 Stephen Williams (steve@icarus.com)
- *    and/or modify it in source code form under the terms of the GNU
+     *
- *    General Public License as published by the Free Software
+     *    This source code is free software; you can redistribute it
- *    Foundation; either version 2 of the License, or (at your option)
+     *    and/or modify it in source code form under the terms of the GNU
- *    any later version.
+     *    General Public License as published by the Free Software
- *
+     *    Foundation; either version 2 of the License, or (at your option)
- *    This program is distributed in the hope that it will be useful,
+     *    any later version.
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
+     *
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+     *    This program is distributed in the hope that it will be useful,
- *    GNU General Public License for more details.
+     *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *
+     *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    You should have received a copy of the GNU General Public License
+     *    GNU General Public License for more details.
- *    along with this program; if not, write to the Free Software
+     *
- *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+     *    You should have received a copy of the GNU General Public License
- */
+     *    along with this program; if not, write to the Free Software
+     *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+     */

Documentation/developer/guide/vvp/vthread.rst

@@ -1,13 +1,8 @@
-/*
- * Copyright (c) 2001 Stephen Williams (steve@icarus.com)
- *
- */
 
+Thread Details
+==============
 
-
+Thread objects in vvp are created by `.thread` statements in the
-THREAD DETAILS
-
-Thread objects in vvp are created by ``.thread'' statements in the
 input source file.
 
 A thread object includes a program counter and private bit
@@ -47,21 +42,23 @@ that use these registers document which register is used, and what the
 numeric value is used for. Registers 0-3 are often given fixed
 meanings to instructions that need an integer value.
 
-/*
+::
- * Copyright (c) 2001 Stephen Williams (steve@icarus.com)
+
- *
+    /*
- *    This source code is free software; you can redistribute it
+     * Copyright (c) 2001-2024 Stephen Williams (steve@icarus.com)
- *    and/or modify it in source code form under the terms of the GNU
+     *
- *    General Public License as published by the Free Software
+     *    This source code is free software; you can redistribute it
- *    Foundation; either version 2 of the License, or (at your option)
+     *    and/or modify it in source code form under the terms of the GNU
- *    any later version.
+     *    General Public License as published by the Free Software
- *
+     *    Foundation; either version 2 of the License, or (at your option)
- *    This program is distributed in the hope that it will be useful,
+     *    any later version.
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
+     *
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+     *    This program is distributed in the hope that it will be useful,
- *    GNU General Public License for more details.
+     *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *
+     *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    You should have received a copy of the GNU General Public License
+     *    GNU General Public License for more details.
- *    along with this program; if not, write to the Free Software
+     *
- *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+     *    You should have received a copy of the GNU General Public License
- */
+     *    along with this program; if not, write to the Free Software
+     *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+     */

Documentation/developer/guide/vvp/vvp.rst

@@ -1,9 +1,6 @@
-/*
- * Copyright (c) 2001-2021 Stephen Williams (steve@icarus.com)
- *
- */
 
-VVP SIMULATION ENGINE
+VVP Simulation Engine
+=====================
 
 The VVP simulator takes as input source code not unlike assembly
 language for a conventional processor. It is intended to be machine
@@ -12,7 +9,8 @@ compiler, so the syntax, though readable, is not necessarily
 convenient for humans.
 
 
-GENERAL FORMAT
+General Format
+--------------
 
 The source file is a collection of statements. Each statement may have
 a label, an opcode, and operands that depend on the opcode. For some
@@ -21,7 +19,7 @@ required.
 
 Every statement is terminated by a semicolon. The semicolon is also
 the start of a comment line, so you can put comment text after the
-semicolon that terminates a statement. Like so:
+semicolon that terminates a statement. Like so::
 
 	Label .functor and, 0x5a, x, y  ; This is a comment.
 
@@ -31,7 +29,8 @@ Statements may span multiple lines, as long as there is no text (other
 then the first character of a label) in the first column of the
 continuation line.
 
-HEADER SYNTAX
+Header Syntax
+-------------
 
 Before any other non-commentary code starts, the source may contain
 some header statements. These are used for passing parameters or
@@ -57,9 +56,10 @@ expressed as a power of 10. For example, +0 is 1 second, and -9 is 1
 nanosecond. If the record is left out, then the precision is taken to
 be +0.
 
-LABELS AND SYMBOLS
+Labels and Symbols
+------------------
 
-Labels and symbols consist of the characters:
+Labels and symbols consist of the characters::
 
 	a-z
 	A-Z
@@ -88,14 +88,16 @@ There are some special symbols that in certain contexts have special
 meanings. As inputs to functors, the symbols "C<0>", "C<1>", "C<x>"
 and "C<z>" represent a constant driver of the given value.
 
-NUMBERS:
+Numbers
+-------
 
 decimal number tokens are limited to 64bits, and are unsigned. Some
 contexts may constrain the number size further.
 
-SCOPE STATEMENTS:
+Scope Statements
+----------------
 
-The syntax of a scope statement is:
+The syntax of a scope statement is::
 
 	<label> .scope <type>, <name> <type-name> <file> <lineno> ;
 
@@ -125,13 +127,14 @@ The <is-cell> flag is only useful for module instances. It is true
 
 The short form of the scope statement is only used for root scopes.
 
-PARAMETER STATEMENTS:
+Parameter Statements
+--------------------
 
 Parameters are named constants within a scope. These parameters have a
 type and value, and also a label so that they can be referenced as VPI
 objects.
 
-The syntax of a parameter is:
+The syntax of a parameter is::
 
 	<label> .param/str <name> <local-flag> <file-idx> <lineno>, <value>;
 	<label> .param/l <name> <local-flag> <file-idx> <lineno>, <value>;
@@ -139,13 +142,13 @@ The syntax of a parameter is:
 
 The <name> is a string that names the parameter. The name is placed in
 the current scope as a vpiParameter object. The .param suffix
-specifies the parameter type.
+specifies the parameter type::
 
 	.param/str    -- The parameter has a string value
 	.param/l      -- The parameter has a logic vector value
 	.param/r      -- The parameter has a real value
 
-The value, then, is appropriate for the data type. For example:
+The value, then, is appropriate for the data type. For example::
 
 	P_123 .param/str "hello", "Hello, World.";
 
@@ -153,14 +156,15 @@ The boolean and logic values can also be signed or not. If signed, the
 value is preceded by a '+' character. (Note that the value is 2s
 complement, so the '+' says only that it is signed, not positive.)
 
-FUNCTOR STATEMENTS:
+Functor Statements
+------------------
 
-A functor statement is a statement that uses the ``.functor''
+A functor statement is a statement that uses the `.functor`
 opcode. Functors are the basic structural units of a simulation, and
 include a type (in the form of a truth table) and up to four inputs. A
 label is required for functors.
 
-The general syntax of a functor is:
+The general syntax of a functor is::
 
 	<label> .functor <type>, symbol_list ;
 	<label> .functor <type> [<drive0> <drive1>], symbol_list ;
@@ -187,17 +191,20 @@ combining up to four inputs down to one output.
 
 - MUXZ
 
+::
+
      Q | A  B  S  n/a
      --+-------------
      A | *  *  0
      B | *  *  1
 
 
-DFF AND LATCH STATEMENTS:
+DFF and Latch Statements
+------------------------
 
 The Verilog language itself does not have a DFF primitive, but post
 synthesis readily creates DFF devices that are best simulated with a
-common device. Thus, there is the DFF statement to create DFF devices:
+common device. Thus, there is the DFF statement to create DFF devices::
 
         <label> .dff/p <width> <d>, <clk>, <ce>;
         <label> .dff/n <width> <d>, <clk>, <ce>;
@@ -218,7 +225,7 @@ propagate, and disables the clock until the aynchronous input is
 deasserted. Thus, they implement DFF with asynchronous clr or set.
 
 Similarly, synthesis creates D-type latches, so there is the LATCH
-statement to support this:
+statement to support this::
 
         <label> .latch <width> <d>, <en>;
 
@@ -227,7 +234,8 @@ type of datum at all. The device will transfer the input to the output
 whenever <en> is a logic 1.
 
 
-UDP STATEMENTS:
+UDP Statements
+--------------
 
 A UDP statement either defines a User Defined Primitive, or
 instantiates a previously defined UDP by creating a UDP functor.  A
@@ -254,6 +262,8 @@ UDPs may also have "-": no change.
 
 An input or current output state can be
 
+::
+
 	"1": 1
 	"0": 0
 	"x": x
@@ -265,6 +275,8 @@ An input or current output state can be
 For Sequential UDPs, at most one input state specification may be
 replaced by an edge specification.  Valid edges are:
 
+::
+
 	"*": (??)	"_": (?0)	"+": (?1)	"%": (?x)
 	"P": (0?)			"r": (01)	"Q": (0x)
 	"N": (1?)	"f": (10)			"M": (1x)
@@ -273,13 +285,13 @@ replaced by an edge specification.  Valid edges are:
 	"n": (1?) | (?0)
 	"p": (0?) | (?1)
 
-A combinatorial UDP is defined like this:
+A combinatorial UDP is defined like this::
 
 	<type> .udp/comb "<name>", <number>, "<row0>", "<row1>", ... ;
 
 <type> is a label that identifies the UDP.  <number> is the number of
 inputs.  "<name>" is there for public identification.  Sequential UDPs
-need an additional initialization value:
+need an additional initialization value::
 
 	<type> .udp/sequ "<name>", <number>, <init>, "<row0>", "<row1>", ... ;
 
@@ -287,7 +299,7 @@ need an additional initialization value:
 provide initial values for individual instances.  <init> must be a
 number 0, 1, or 2 (for 1'bx).
 
-A UDP functor instance is created so:
+A UDP functor instance is created so::
 
 	<label> .udp  <type>, <symbol_list> ;
 
@@ -296,11 +308,12 @@ defined earlier, and <symbol_list> is a list of symbols, one for each
 input of the UDP.
 
 
-VARIABLE STATEMENTS:
+Variable Statements
+-------------------
 
 A variable is a bit vector that can be written by behavioral code (so
 has no structural input) and propagates its output to a functor. The
-general syntax of a variable is:
+general syntax of a variable is::
 
 	<label> .var   "name", <msb> <lsb>; Unsigned logic variable
 	<label> .var/s "name", <msb> <lsb>; Signed logic variable
@@ -336,12 +349,13 @@ Behavioral code may also invoke %force/v statements that write to port-2
 to invoke force mode. This overrides continuous assign mode until a
 long(2) is written to port-3 to disable force mode.
 
-NET STATEMENTS:
+Net Statements
+--------------
 
 A net is similar to a variable, except that a thread cannot write to
 it (unless it uses a force) and it is given a different VPI type
 code. The syntax of a .net statement is also similar to but not
-exactly the same as the .var statement:
+exactly the same as the .var statement::
 
 	<label> .net      "name", <msb>, <lsb>, <symbol>;
 	<label> .net/s    "name", <msb>, <lsb>, <symbol>;
@@ -375,11 +389,12 @@ The .alias statements do not create new nodes, but instead create net
 names that are aliases of an existing node. This handles special cases
 where a net has different names, possibly in different scopes.
 
-CAST STATEMENTS:
+Cast Statements
+---------------
 
 Sometimes nets need to be cast from a real valued net to a bit based
 net or from a bit based net to a real valued net. These statements
-are used to perform that operation:
+are used to perform that operation::
 
 	<label> .cast/int <width>, <symbol>;
 	<label> .cast/2 <width>, <symbol>;
@@ -394,7 +409,8 @@ For .cast/real the output <label> is a real valued net. The input
 <symbol> is expected to put bit based values and for .cast/real.s
 the bits will be interpreted as a signed value.
 
-DELAY STATEMENTS:
+Delay Statements
+----------------
 
 Delay nodes are structural net delay nodes that carry and manage
 propagation delays. Delay nodes can have fixed delays or variable
@@ -403,6 +419,8 @@ delayed. The delay amount is given on the node line. Variable delay
 nodes have three extra inputs to receive the rise, fall and decay
 times that are used for delay.
 
+::
+
 	.delay <width> ( <rise>, <fall>, <decay> ) <input> ;
 	.delay <width> <input>, <rise>, <fall>, <decay> ;
 
@@ -412,20 +430,24 @@ inputs, with the first being the value to delay, and the remaining to
 be the delay values to use. <width> specifies the bit width of the
 input net, with a width of 0 used to identify a real valued net.
 
-MODULE PATH DELAY STATEMENTS:
+Module Path Delay Statements
+----------------------------
 
 A module path delay takes data from its input, then a list of module
 path delays. The <src> for each possible delay set is a trigger that
 activates the delay.
 
+::
+
         .modpath <width> <input> , [ <src> (<delays> [? <condition>]) ] ;
 
 <width> specifies the bit width of the input net.
 
-ARRAY INDEX STATEMENTS:
+Array Index Statements
+----------------------
 
 Variables can be collected into arrays. The words of the array are
-declared separately, this statement collects them together:
+declared separately, this statement collects them together::
 
 	<label> .array "name", <last> <first> ;
 
@@ -436,15 +458,18 @@ The syntax below is different, in that it creates an alias for an
 existing array. The dimensions and storage are taken from the .array
 at <src>.
 
+::
+
         <label> .array "name", <src> ;
 
 
-EVENT STATEMENTS
+Event Statements
+----------------
 
 Threads need to interact with the functors of a netlist synchronously,
 as well as asynchronously. There are cases where the web of functors
 needs to wake up a waiting thread. The web of functors signals threads
-through .event objects, that are declared like so:
+through .event objects, that are declared like so::
 
 	<label> .event <type>, <symbols_list>;
 	<label> .event "name";
@@ -470,7 +495,7 @@ events of the same edge in an event OR expression, the compiler may
 combine up to 4 into a single event.
 
 If many more events need to be combined together (for example due to
-an event or expression in the Verilog) then this form can be used:
+an event or expression in the Verilog) then this form can be used::
 
 	<label> .event/or <symbols_list>;
 
@@ -479,13 +504,16 @@ to trigger this event. Only one of the input events needs to trigger
 to make this one go.
 
 
-RESOLVER STATEMENTS:
+Resolver Statements
+-------------------
 
 Resolver statements are strength-aware functors with 4 inputs, but
 their job typically is to calculate a resolved output using strength
 resolution. The type of the functor is used to select a specific
 resolution function.
 
+::
+
 	<label> .resolv tri,  <symbols_list>;
 	<label> .resolv tri0, <symbols_list>;
 	<label> .resolv tri1, <symbols_list>;
@@ -494,13 +522,16 @@ The output from the resolver is vvp_vector8_t value. That is, the
 result is a vector with strength included.
 
 
-PART SELECT STATEMENTS:
+Part Select Statements
+----------------------
 
 Part select statements are functors with three inputs. They take in at
 port-0 a vector, and output a selected (likely smaller) part of that
 vector. The other inputs specify what those parts are, as a canonical
 bit number, and a width. Normally, those bits are constant values.
 
+::
+
 	<label> .part <symbol>, <base>, <wid>;
 	<label> .part/pv <symbol>, <base>, <wid>, <vector_wid>;
 	<label> .part/v <symbol>, <symbol>, <wid>;
@@ -520,13 +551,16 @@ The .part/v variation takes a vector (or long) input on port-1 as the
 base of the part select. Thus, the part select can move around. The
 .part/v.s variation treats the vector as a signed value.
 
-PART CONCATENATION STATEMENTS:
+Part Concatenation Statements
+-----------------------------
 
 The opposite of the part select statement is the part concatenation
 statement. The .concat statement is a functor node that takes at input
 vector values and produces a single vector output that is the
 concatenation of all the inputs.
 
+::
+
         <label> .concat [W X Y Z], <symbols_list> ;
 
 The "[" and "]" tokens surround a set of 4 numbers that are the
@@ -541,11 +575,12 @@ propagated, the bits are placed in the correct place in the output
 vector value, and a new output value is propagated.
 
 
-REPEAT VECTOR STATEMENTS:
+Repeat Vector Statements
+------------------------
 
 The repeat vector statement is similar to the concatenation statement,
 expect that the input is repeated a constant number of times. The
-format of the repeat vector statement is:
+format of the repeat vector statement is::
 
         <label> .repeat <wid>, <rept count>, <symbol> ;
 
@@ -554,15 +589,16 @@ the *output* vector. The <rept count> is the number of time the input
 vector value is repeated to make the output width. The input width is
 implicit from these numbers. The <symbol> is then the input source.
 
-SUBSTITUTION STATEMENTS:
+Substitution Statements
+-----------------------
 
 The substitution statement doesn't have a direct analog in Verilog, it
-only turns up in synthesis. It is a shorthand for forms like this:
+only turns up in synthesis. It is a shorthand for forms like this::
 
    foo = <a>;
    foo[n] = <s>;
 
-The format of the substitute statement is:
+The format of the substitute statement is::
 
         <label> .substitute <wid>, <soff> <swid>, <symbol>, <symbol> ;
 
@@ -570,11 +606,14 @@ The first <symbol> must have the width <wid>, and is passed through,
 except for the bits within [<soff> +: <swid>]. The second <symbol>
 collects a vector that goes into that part.
 
-REDUCTION LOGIC
+Reduction Logic
+---------------
 
 The reduction logic statements take in a single vector, and propagate
 a single bit.
 
+::
+
         <label> .reduce/and  <symbol> ;
         <label> .reduce/or   <symbol> ;
         <label> .reduce/xor  <symbol> ;
@@ -586,22 +625,28 @@ the device has a single input, which is a vector of any width. The
 device performs the logic on all the bits of the vector (a la Verilog)
 and produces and propagates a single bit width vector.
 
-EXPANSION LOGIC
+Expansion Logic
+---------------
 
 Sign extension nodes are the opposite of reduction logic, in that they
 take a narrow vector, or single bit, and pad it out to a wider
 vector.
 
+::
+
         <label> .expand/s <wid>, <symbol> ;
 
 The .expand/s node takes an input symbol and sign-extends it to the
 given width.
 
-FORCE STATEMENTS (old method - remove me):
+Force Statements (old method - remove me)
+-----------------------------------------
 
 A force statement creates functors that represent a Verilog force
 statement.
 
+::
+
 	<label>	.force <signal>, <symbol_list>;
 
 The symbol <signal> represents the signal which is to be forced.  The
@@ -610,7 +655,7 @@ forced on the <signal>.  The <label> identifies the force functors.
 There will be as many force functors as there are symbols in the
 <symbol_list>.
 
-To activate and deactivate a force on a single bit, use:
+To activate and deactivate a force on a single bit, use::
 
 	%force	<label>, <width>;
 	%release <signal>;
@@ -619,13 +664,14 @@ To activate and deactivate a force on a single bit, use:
 <signal> is the label of the functor that drives the signal that is
 being forced.
 
-FORCE STATEMENTS (new method - implement me):
+Force Statements (new method - implement me)
+--------------------------------------------
 
 A %force instruction, as described in the .var section, forces a
 constant value onto a .var or .net, and the matching %release releases
 that value. However, there are times when the value of a functor
 (i.e. another .net) needs to be forced onto a .var or .net. For this
-task, the %force/link instruction exists:
+task, the %force/link instruction exists::
 
 	%force/link <dst>, <src> ;
 	%release/link <dst> ;
@@ -638,20 +684,23 @@ node. The matching %release/link instruction removes the link (a
 releases the last %force/link, no matter where the link is from. A new
 %force/link will remove a previous link.
 
-The instructions:
+The instructions::
 
 	%cassign/link <dst>, <src> ;
 	%deassign/link <dst> ;
 
 are the same concept, but for the continuous assign port.
 
-STRUCTURAL ARITHMETIC STATEMENTS:
+Structural Arithmetic Statements
+--------------------------------
 
-The various Verilog arithmetic operators (+-*/%) are available to
+The various Verilog arithmetic operators (`+-*/%`) are available to
 structural contexts as two-input functors that take in vectors. All of
 these operators take two inputs and generate a fixed width output. The
 input vectors will be padded if needed to get the desired output width.
 
+::
+
 	<label> .arith/sub  <wid>, <A>, <B>;
 	<label> .arith/sum  <wid>, <A>, <B>;
 	<label> .arith/mult <wid>, <A>, <B>;
@@ -667,12 +716,13 @@ output. I have not decided how to handle this.
 These devices support .s and .r suffixes. The .s means the node is a
 signed vector device, the .r a real valued device.
 
-STRUCTURAL COMPARE STATEMENTS:
+Structural Compare Statements
+-----------------------------
 
 The arithmetic statements handle various arithmetic operators that
 have wide outputs, but the comparators have single bit output, so they
 are implemented a bit differently. The syntax, however, is very
-similar:
+similar::
 
 	<label> .cmp/eeq <wid>, <A>, <B>;
 	<label> .cmp/nee <wid>, <A>, <B>;
@@ -691,10 +741,11 @@ versions do unsigned comparison, but the ".s" versions to signed
 comparisons. (Equality doesn't need to care about sign.)
 
 
-STRUCTURAL SHIFTER STATEMENTS:
+Structural Shifter Statements
+-----------------------------
 
 Variable shifts in structural context are implemented with .shift
-statements:
+statements::
 
 	<label> .shift/l <wid>, <data symbol>, <shift symbol>;
 	<label> .shift/r <wid>, <data symbol>, <shift symbol>;
@@ -706,15 +757,18 @@ data to be shifted and must have exactly the width of the output. The
 input to port 1 is the amount to shift.
 
 
-STRUCTURAL FUNCTION CALLS:
+Structural Function Calls
+-------------------------
 
 The .ufunc statements define a call to a user defined function.
 
+::
+
 	<label> .ufunc/real <flabel>, <wid>,
-            <isymbols> ( <psymbols> ) <ssymbol>;
+            [<isymbols> ( <psymbols> )] <ssymbol>;
 
 	<label> .ufunc/vec4 <flabel>, <wid>,
-            <isymbols> ( <psymbols> ) <ssymbol>;
+            [<isymbols> ( <psymbols> )] <ssymbol>;
 
 	<label> .ufunc/e <flabel>, <wid>, <trigger>,
             <isymbols> ( <psymbols> ) <ssymbol>;
@@ -742,12 +796,15 @@ before calling the function.
 
 The <ssymbol> is the function scope name.
 
-THREAD STATEMENTS:
+Thread Statements
+-----------------
 
 Thread statements create the initial threads for a simulation. These
 represent the initial and always blocks, and possibly other causes to
 create threads at startup.
 
+::
+
 	.thread <symbol> [, <flag>]
 
 This statement creates a thread with a starting address at the
@@ -756,7 +813,7 @@ created for the .thread statement, and it starts at the <symbol>
 addressed instruction.
 
 The <flag> modifies the creation/execution behavior of the
-thread. Supported flags are:
+thread. Supported flags are::
 
 	$push -- Cause the thread to be pushed in the scheduler. This
 		 only effects startup (time 0) by arranging for pushed
@@ -766,7 +823,7 @@ thread. Supported flags are:
 * Threads in general
 
 Thread statements create the initial threads of a design. These
-include the ``initial'' and ``always'' statements of the original
+include the `initial` and `always` statements of the original
 Verilog, and possibly some other synthetic threads for various
 purposes. It is also possible to create transient threads from
 behavioral code. These are needed to support such constructs as
@@ -815,7 +872,7 @@ words have a distinct address space from the bits.
 
 * Threads and scopes
 
-The Verilog ``disable'' statement deserves some special mention
+The Verilog `disable` statement deserves some special mention
 because of how it interacts with threads. In particular, threads
 throughout the design can affect (end) other threads in the design
 using the disable statement.
@@ -838,10 +895,11 @@ by the fork atomically joins that scope. Once the transient thread
 joins the scope, it stays there until it ends. Threads never change
 scopes, not even transient threads.
 
-VPI TASK/FUNCTION CALLS
+Vpi Task/Function Calls
+-----------------------
 
 Threads call vpi tasks with the %vpi_call or %vpi_func
-instructions. The formats are:
+instructions. The formats are::
 
    %vpi_call <file-index> <lineno> <name>, <args>... ;
    %vpi_call/w <file-index> <lineno> <name>, <args>... ;
@@ -870,7 +928,7 @@ value returned by a system function called as a task.
 * The &A<> argument
 
 The &A<> argument is a reference to the word of a variable array. The
-syntax is:
+syntax is::
 
    &A '<' <symbol> , <number> '>'
    &A '<' <symbol> , <base_symbol> '>'
@@ -884,7 +942,7 @@ starting at <base>). The base value may be signed or unsigned.
 
 * The &PV<> argument
 
-The &PV<> argument is a reference to part of a signal. The syntax is:
+The &PV<> argument is a reference to part of a signal. The syntax is::
 
    &PV '<' <symbol> , <base> , <width> '>'
    &PV '<' <symbol> , <base_symbol> , <width> '>'
@@ -897,7 +955,8 @@ or &A<>/&PV<> select. The third form retrieves the <base> from thread
 space using <twid> bits starting at <tbase>. The base value may be
 signed or unsigned.
 
-TRUTH TABLES
+Truth Tables
+------------
 
 The logic that a functor represents is expressed as a truth table. The
 functor has four inputs and one output. Each input and output has one
@@ -910,7 +969,7 @@ implement the logic.
 
 To implement the truth table, we need to assign 2-bit encodings for
 the 4-value signals. I choose, pseudo-randomly, the following
-encoding:
+encoding::
 
 	1'b0  : 00
 	1'b1  : 01
@@ -919,11 +978,12 @@ encoding:
 
 The table is an array of 64 bytes, each byte holding 4 2-bit
 outputs. Construct a 6-bit byte address with inputs 1, 2 and 3 like
-so:
+so::
+
 	 332211
 
 The input 0 2-bits can then be used to select which of the 4 2-bit
-pairs in the 8-bit byte are the output:
+pairs in the 8-bit byte are the output::
 
 	MSB -> zzxx1100 <- LSB
 
@@ -934,7 +994,8 @@ none needs to be given by the programmer. It is sufficient to name the
 type to get that truth table.
 
 
-EXECUTABLE INSTRUCTIONS
+Executable Instructions
+-----------------------
 
 Threads run executable code, much like a processor executes machine
 code. VVP has a variety of opcodes for executable instructions. All of
@@ -947,7 +1008,8 @@ The opcodes.txt file has a more detailed description of all the
 various instructions.
 
 
-THE RELATIONSHIP BETWEEN FUNCTORS, THREADS AND EVENTS
+The Relationship Between Functors, Threads And Events
+-----------------------------------------------------
 
 Given the above summary of the major components of vvp, some
 description of their relationship is warranted. Functors provide a
@@ -966,7 +1028,7 @@ it is connected to, and those functors in turn create new events if
 needed.
 
 Assignment events (the second of three types of events) are created
-by non-blocking assignments in behavioral code. When the ``<='' is
+by non-blocking assignments in behavioral code. When the `<=` is
 executed (a %assign in vvp) an assign event is created, which includes
 the vvp_ipoint_t pointer to the functor input to receive the value,
 as well as the value. These are distinct from propagation events because:
@@ -991,7 +1053,7 @@ the right kind of code to cause things to happen in the design. If the
 event is a propagate or assignment event, the network of functors is
 tickled; if the event is a thread schedule, then a thread is run. The
 implementation of the event queue is not important, but currently is
-implemented as a ``skip list''. That is, it is a sorted singly linked
+implemented as a `skip list`. That is, it is a sorted singly linked
 list with skip pointers that skip over delta-time events.
 
 The functor net and the threads are distinct. They communicate through
@@ -1000,7 +1062,8 @@ is concerned, the functor net is a blob of structure that it pokes and
 prods via certain functor access instructions.
 
 
-VVP COMPILATION AND EXECUTION
+VVP Compilation And Execution
+-----------------------------
 
 The vvp program operates in a few steps:
 
@@ -1023,7 +1086,7 @@ The vvp program operates in a few steps:
 
 
 The initialization step is performed by the compile_init() function in
-compile.cc. This function in turn calls all the *_init() functions in
+compile.cc. This function in turn calls all the \*_init() functions in
 other parts of the source that need initialization for compile. All
 the various sub-init functions are called <foo>_init().
 
@@ -1044,7 +1107,8 @@ the schedule_simulate() function. This does any final setup and starts
 the simulation running and the event queue running.
 
 
-HOW TO GET FROM THERE TO HERE
+How To Get From There To Here
+-----------------------------
 
 The vvp simulation engine is designed to be able to take as input a
 compiled form of Verilog. That implies that there is a compiler that
@@ -1055,22 +1119,22 @@ compiles Verilog into a form that the vvp engine can read.
 
 Gates like AND, OR and NAND are implemented simply and obviously by
 functor statements. Any logic up to 4 inputs can be implemented with a
-single functor. For example:
+single functor. For example::
 
 	and gate (out, i1, i2, i3);
 
-becomes:
+becomes::
 
 	gate	.functor and, i1, i2, i3;
 
 Notice the first parameter of the .functor is the type. The type
 includes a truth table that describes the output with a given
 input. If the gate is wider than four inputs, then cascade
-functors. For example:
+functors. For example::
 
 	and gate (out, i1, i2, i3, i4, i5, i6, i7, i8);
 
-becomes:
+becomes::
 
 	gate.0	.functor and, i1, i2, i3, i4;
 	gate.1	.functor and, i5, i6, i7, i8;
@@ -1079,16 +1143,16 @@ becomes:
 
 * reg and other variables
 
-Reg and integer are cases of what Verilog calls ``variables.''
+Reg and integer are cases of what Verilog calls `variables`.
 Variables are, simply put, things that behavioral code can assign
-to. These are not the same as ``nets,'' which include wires and the
+to. These are not the same as `nets`, which include wires and the
 like.
 
-Each bit of a variable is created by a ``.var'' statement. For example:
+Each bit of a variable is created by a `.var` statement. For example::
 
 	reg a;
 
-becomes:
+becomes::
 
 	a	.var "a", 0, 0;
 
@@ -1097,16 +1161,17 @@ becomes:
 
 Events in general are implemented as functors, but named events in
 particular have no inputs and only the event output. The way to
-generate code for these is like so:
+generate code for these is like so::
 
 	a  .event "name";
 
 This creates a functor and makes it into a mode-2 functor. Then the
-trigger statement, "-> a", cause a ``%set a, 0;'' statement be
+trigger statement, "-> a", cause a `%set a, 0;` statement be
 generated. This is sufficient to trigger the event.
 
 
-AUTOMATICALLY ALLOCATED SCOPES
+Automatically Allocated Scopes
+------------------------------
 
 If a .scope statement has a <type> of autofunction or autotask, the
 scope is flagged as being an automatically allocated scope. The functor
@@ -1159,21 +1224,23 @@ variable or event, the associated functor indirects through the
 current read or write context of the running thread, using its
 stored context index.
 
-/*
+::
- * Copyright (c) 2001-2009 Stephen Williams (steve@icarus.com)
+
- *
+    /*
- *    This source code is free software; you can redistribute it
+     * Copyright (c) 2001-2024 Stephen Williams (steve@icarus.com)
- *    and/or modify it in source code form under the terms of the GNU
+     *
- *    General Public License as published by the Free Software
+     *    This source code is free software; you can redistribute it
- *    Foundation; either version 2 of the License, or (at your option)
+     *    and/or modify it in source code form under the terms of the GNU
- *    any later version.
+     *    General Public License as published by the Free Software
- *
+     *    Foundation; either version 2 of the License, or (at your option)
- *    This program is distributed in the hope that it will be useful,
+     *    any later version.
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
+     *
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+     *    This program is distributed in the hope that it will be useful,
- *    GNU General Public License for more details.
+     *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *
+     *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    You should have received a copy of the GNU General Public License
+     *    GNU General Public License for more details.
- *    along with this program; if not, write to the Free Software
+     *
- *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+     *    You should have received a copy of the GNU General Public License
- */
+     *    along with this program; if not, write to the Free Software
+     *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+     */

Documentation/developer/index.rst

@@ -9,5 +9,7 @@ Icarus Verilog.
    :maxdepth: 1
 
    getting_started
+   regression_tests
    version_stamps
-
+   guide/index
+   glossary

Documentation/developer/regression_tests.rst

@@ -0,0 +1,129 @@
+
+The Regression Test Suite
+=========================
+
+Icarus Verilog development includes a regression test suite that is included
+along with the source. The "ivtest" directory contains the regression test
+suite, and this suite is used by the github actions as continuous integration
+to make sure the code is always going forward.
+
+NOTE: There are scripts written in perl to run the regression tests, but they
+are being gradually replaced with a newer set of scripts. It is the newer
+method that is described here.
+
+Test Descriptions
+-----------------
+
+Regression tests are listed in the regress-vvp.list file. Each line lists the
+name of the test and the path to the dest description. The list file is
+therefore pretty simple, and all the description of the test is in the
+description file:
+
+.. code-block:: console
+
+  macro_str_esc  vvp_tests/macro_str_esc.json
+
+The "name" is a simple name, and the test-description-file is the path (relative
+the ivtest directory) to the description file. A simple test description file
+is a JSON file, like this:
+
+.. code-block:: java
+
+  {
+    "type"   : "normal",
+    "source" : "macro_str_esc.v",
+    "gold"   : "macro_str_esc"
+  }
+
+This description file contains all the information that the vvp_reg.py script
+needs to run the regression test. The sections below describe the keys and
+values in the description file dictionary.
+
+source (required)
+^^^^^^^^^^^^^^^^^
+This specifies the name of the source file. The file is actually to be found
+in the ivltests/ directory.
+
+
+type (required)
+^^^^^^^^^^^^^^^
+
+This describes the kind of test to run. The valid values are:
+
+* **normal** - Compile the source using the iverilog compiler vvp target, and if
+  that succeeds execute it using the vvp command. If there is no gold file
+  specified, then look for an output line with the "PASSED" string.
+
+* **NI** - Mark the test as not implemented. The test will be skipped without
+  running or reporting an error.
+
+* **CE** - Compile, but expect the compiler to fail. This means the compiler
+  command process must return an error exit.
+
+* **EF** - Compile and run, but expect the run time to fail. This means the
+  run time program must return an error exit.
+
+* **TE** - This is specific to testing the vlog95 conversion and indicates the
+  translated code failed to compile.
+
+gold (optional)
+^^^^^^^^^^^^^^^
+
+If this is specified, it replaces the "Passed" condition with a comparison of
+the output with a gold file. The argument is the name of the gold file set,
+which will be found in the "gold/" directory. The name here is actually the
+basename of the gold files, with separate actual gold files for the iverilog
+and vvp stderr and stdout. For example, if a "normal" test includes a gold
+file, then the program is compiled and run, and the outputs are compared with
+the gold file to make sure it ran properly.
+
+The way the regression suite works, there are 4 log files created for each
+test:
+
+* foo-iverilog-stdout.log
+* foo-iverilog-stderr.log
+* foo-vvp-stdout.log
+* foo-vvp-stderr.log
+
+The "gold" value is the name of the gold file set. If the gold value is "foo",
+Then the actual gold files are called:
+
+* gold/foo-iverilog-stdout.gold
+* gold/foo-iverilog-stderr.gold
+* gold/foo-vvp-stdout.gold
+* gold/foo/vvp-stderr.gold
+
+If any of those files is empty, then the gold file doesn't need to be
+present at all. The log files and the gold files are compared byte for
+byte, so if the output you are getting is correct, then copy the log to
+the corresponding gold, and you're done.
+
+If the run type is "CE" or "RE", then the gold files still work, and can
+be used to check that the error message is correct. If the gold file setting
+is present, the error return is required, and also the gold files must match.
+
+iverilog-args (optional)
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+If this is specified, it is a list of strings that are passed as arguments to
+the iverilog command line.
+
+vvp-args (optional)
+^^^^^^^^^^^^^^^^^^^^
+
+If this is specified, it is a list of strings that are passed as arguments to
+the vvp command. These arguments go before the vvp input file that is to be
+run.
+
+vvp-args-extended (optional)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If this is specified, it is a lost of strings that are passed as arguments to
+the vvp command. These are extended arguments, and are placed after the vvp
+input file that is being run. This is where you place things like plusargs.
+
+strict, force-sv or vlog95 (optional)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Any of these can be used to create overrides for the type, gold or
+iverilog-args when the given test type is run.

Documentation/developer/version_stamps.rst

@@ -9,21 +9,24 @@ These are the only files that have version information in them:
 * verilog.spec      -- Used to stamp RPM packages
 
 When versions are changed, the above files need to be edited to account for
-the new version information. The following used to have verion information in
+the new version information. The following used to have version information in
 them, but now their version information is generated:
 
-Replaced with version_base.h, which is edited manually, and
+The version_tag.h file is generated from git tag information using
-version_tag.h which is generated from git tag information.
+the "make version" target, or automatically if the version_tag.h
+file doesn't exist at all. This implies that a "make version" is
+something worth doing when you do a "git pull" or create commits.
 
-* version-base.in     -- Most compiled code gets version from here
+The files below are now edited by the Makefile:
-
-These are now edited by the makefile and the version.exe program.
 
 * iverilog-vpi.man    -- The .TH tag has a version string
 * driver/iverilog.man -- The .TH tag has a version string
 * driver-vpi/res.rc   -- Used to build Windows version stamp
 * vvp/vvp.man         -- The .TH tag has a version string
 
-This now includes version_base.h to get the version
+This now includes version_base.h to get the version:
 
 * vpi/vams_simparam.c -- Hard coded result to simulatorVersion query
+
+The test suite no longer has version specific files since it tracks along with
+the code/branch.

Documentation/index.rst

@@ -12,6 +12,7 @@ Welcome to the documentation for Icarus Verilog.
    :maxdepth: 2
    :caption: Contents:
 
+   releases/index
    usage/index
    targets/index
    developer/index

Documentation/releases/index.rst

@@ -0,0 +1,10 @@
+Icarus Verilog Release Notes
+============================
+
+This section contains the release notes for all releases after and including
+V13.0. Older release notes can be found here: `<https://iverilog.fandom.com/wiki/User_Guide>`__
+
+.. toctree::
+   :maxdepth: 1
+
+   v13-0-release-note

Documentation/releases/v13-0-release-note.rst

@@ -0,0 +1,98 @@
+🎉 Release V13.0
+================
+
+The Icarus Verilog development team is pleased to announce **Release V13** of Icarus Verilog.
+
+Release V13 builds on the V12 series with a focus on correctness, runtime stability, improved
+diagnostics, and incremental standard conformance improvements.
+
+----
+
+🐞 Bug Fix Summary
+------------------
+
+Release V13 resolves numerous issues reported against V12, including:
+
+* Incorrect signed constant handling.
+* Generate block naming collisions.
+* Elaboration-time assertion failures.
+* Runtime crashes in malformed corner cases.
+* Memory management issues during elaboration and simulation.
+
+
+----
+
+🔄 Major Changes in V13
+=======================
+
+🧠 Language & Elaboration Fixes
+-------------------------------
+
+Release V13 includes multiple fixes to elaboration and expression handling:
+
+* Resolved generate block scope resolution issues affecting nested and conditional generate constructs.
+* Corrected signed arithmetic corner cases, including shift and width propagation behavior.
+* Fixed constant expression evaluation inconsistencies during parameter elaboration.
+* Improved handling of packed and unpacked arrays in assignments and port binding corner cases.
+* Addressed elaboration-time assertion failures triggered by malformed or ambiguous constructs.
+* Corrected several source-location reporting issues for elaboration errors.
+
+These changes improve standards conformance and eliminate behavioral inconsistencies observed in the V12 series.
+
+----
+
+⚙️ Simulator (vvp) Improvements
+-------------------------------
+
+The `vvp` runtime engine has received internal stability and correctness updates:
+
+* Improved event scheduling behavior in zero-delay and non-blocking assignment scenarios.
+* Fixed race-condition corner cases uncovered by expanded regression testing.
+* Eliminated memory leaks affecting long-running or large simulations.
+* Resolved crash conditions caused by invalid internal state transitions.
+* Improved robustness of `$dumpvars` handling in large hierarchical designs.
+* General runtime consistency and determinism improvements.
+
+`vvp` continues to enforce version matching between the runtime and generated bytecode. Designs
+must be recompiled after upgrading.
+
+----
+
+🔌 VPI Updates
+--------------
+
+Fixes improve VPI reliability and conformance:
+
+* Corrected hierarchical object lookup behavior in specific corner cases.
+* Improved stability of callback registration during startup and shutdown.
+* Fixed invalid handle dereference scenarios that could result in segmentation faults.
+* Addressed inconsistencies in VPI object property reporting.
+
+----
+
+🛠 Diagnostics & Toolchain
+--------------------------
+
+* Improved clarity and consistency of error and warning messages.
+* Better reporting of width mismatches and implicit net declarations.
+* More accurate diagnostic source locations.
+* Build system updates for compatibility with modern compiler toolchains.
+* Regression suite expansion and CI validation improvements.
+
+----
+
+📦 Upgrade Notes
+----------------
+
+* Recompile all designs when upgrading from V12 or any other prior version.
+* Review warnings carefully; improved diagnostics may expose previously silent issues.
+* The only known breaking change is that wires must now be declared before use; which is required in the standard (see `gh1287 <https://github.com/steveicarus/iverilog/issues/1287>`__).
+
+----
+
+🙏 Acknowledgments
+------------------
+
+We thank all contributors who reported issues, submitted patches, expanded regression coverage, and
+improved documentation. Release 13 reflects continued community effort toward improving correctness,
+stability, and maintainability.

Documentation/requirements.txt

@@ -0,0 +1,2 @@
+sphinx==8.1.3
+shibuya==2026.1.9

Documentation/targets/index.rst

@@ -3,16 +3,21 @@ The Icarus Verilog Targets
 ==========================
 
 Icarus Verilog elaborates the design, then sends to the design to code
-generates (targets) for processing. new code generators can be added by
+generates (targets) for processing. New code generators can be added by
 external packages, but these are the code generators that are bundled with
 Icarus Verilog. The code generator is selected by the "-t" command line flag.
 
 .. toctree::
    :maxdepth: 1
 
-   vvp
+   tgt-vvp
-   stub
+   tgt-stub
-   null
+   tgt-null
-   vhdl
+   tgt-vhdl
-   verilog95
+   tgt-vlog95
-   pcb
+   tgt-pcb
+   tgt-fpga
+   tgt-pal
+   tgt-sizer
+   tgt-verilog
+   tgt-blif

Documentation/targets/stub.rst

@@ -1,7 +0,0 @@
-
-The stub Code Generator (-tstub)
-================================
-
-The stub code generator is a debugging aid for the Icarus Verilog compiler
-itself. It outputs a text dump of the elaborated design as it is passed to
-code generators.

Documentation/targets/tgt-blif.rst

@@ -1,6 +1,6 @@
 
-BLIF TARGET
+The BLIF Code Generator (-tblif)
------------
+================================
 
 The BLIF code generator supports emitting the design to a blif format
 file as accepted by:
@@ -17,9 +17,9 @@ USAGE
 -----
 
 This code generator is intended to process structural Verilog source
-code. To convert a design to blif, use this command:
+code. To convert a design to blif, use this command::
 
-    iverilog -tblif -o<path>.blif  <source files>...
+  % iverilog -tblif -o<path>.blif  <source files>...
 
 The source files can be Verilog, SystemVerilog, VHDL, whatever Icarus
 Verilog supports, so long as it elaborates down to the limited subset

Documentation/targets/tgt-fpga.rst

@@ -1,7 +1,9 @@
 
-FPGA LOADABLE CODE GENERATOR FOR Icarus Verilog
+The FPGA Code Generator (-tfpga)
+================================
 
-  Copyright 2001 Stephen Williams
+.. warning::
+    This code generator is currently not included in Icarus Verilog.
 
 The FPGA code generator supports a variety of FPGA devices, writing
 XNF or EDIF depending on the target. You can select the architecture
@@ -10,6 +12,7 @@ select library primitives, and the detailed part name is written into
 the generated file for the use of downstream tools.
 
 INVOKING THE FPGA TARGET
+------------------------
 
 The code generator is invoked with the -tfpga flag to iverilog. It
 understands the part= and the arch= parameters, which can be set with
@@ -61,6 +64,7 @@ Virtex-II and Virtex-II Pro devices. It uses the VIRTEX2 library, but
 is very similar to the Virtex target.
 
 XNF ROOT PORTS
+--------------
 
   NOTE: As parts are moved over to EDIF format, XNF support will be
   phased out. Current Xilinx implementation tools will accept EDIF
@@ -76,6 +80,8 @@ signal. If the signal is one bit wide, then the pin name is exactly
 the module port name. If the port is a vector, then the pin number is
 given as a vector. For example, the module:
 
+.. code-block::
+
 	module main(out, in);
 	    output out;
 	    input [2:0] in;
@@ -84,6 +90,8 @@ given as a vector. For example, the module:
 
 leads to these SIG, records:
 
+.. code-block::
+
 	SIG, main/out, PIN=out
 	SIG, main/in<2>, PIN=in2
 	SIG, main/in<1>, PIN=in1
@@ -91,6 +99,7 @@ leads to these SIG, records:
 
 
 EDIF ROOT PORTS
+---------------
 
 The EDIF format is more explicit about the interface into an EDIF
 file. The code generator uses that control to generate an explicit
@@ -108,6 +117,7 @@ However, since the ports are single bit ports, the name of vectors
 includes the string "[0]" where the number is the bit number. For
 example, the module:
 
+.. code-block::
 
 	module main(out, in);
 	    output out;
@@ -117,6 +127,8 @@ example, the module:
 
 creates these ports:
 
+.. code-block::
+
 	out   OUTPUT
 	in[0] INPUT
 	in[1] INPUT
@@ -128,6 +140,7 @@ when presenting the vector to the user.
 
 
 PADS AND PIN ASSIGNMENT
+-----------------------
 
 The ports of a root module may be assigned to specific pins, or to a
 generic pad. If a signal (that is a port) has a PAD attribute, then
@@ -135,14 +148,14 @@ the value of that attribute is a list of locations, one for each bit
 of the signal, that specifies the pin for each bit of the signal. For
 example:
 
+.. code-block::
+
 	module main( (* PAD = "P10" *)         output out,
 		     (* PAD = "P20,P21,P22" *) input [2:0] in);
-
 	    [...]
-
 	endmodule
 
-In this example, port ``out'' is assigned to pin 10, and port ``in''
+In this example, port `out` is assigned to pin 10, and port `in`
 is assigned to pins 20-22. If the architecture supports it, a pin
 number of 0 means let the back end tools choose a pin. The format of
 the pin number depends on the architecture family being targeted, so
@@ -156,6 +169,7 @@ driver to the port. An error.
 
 
 SPECIAL DEVICES
+---------------
 
 The code generator supports the "cellref" attribute attached to logic
 devices to cause specific device types be generated, instead of the
@@ -176,12 +190,12 @@ device pins are connected.
 
 
 COMPILING WITH XILINX FOUNDATION
+--------------------------------
 
-Compile a single-file design with command line tools like so:
+Compile a single-file design with command line tools like so::
-
-	% iverilog -parch=virtex -o foo.edf foo.vl
-	% edif2ngd foo.edf foo.ngo
-	% ngdbuild -p v50-pq240 foo.ngo foo.ngd
-	% map -o map.ncd foo.ngd
-	% par -w map.ncd foo.ncd
 
+  % iverilog -parch=virtex -o foo.edf foo.vl
+  % edif2ngd foo.edf foo.ngo
+  % ngdbuild -p v50-pq240 foo.ngo foo.ngd
+  % map -o map.ncd foo.ngd
+  % par -w map.ncd foo.ncd

Documentation/targets/tgt-pal.rst

@@ -0,0 +1,8 @@
+
+The PAL Code Generator (-tpal)
+==============================
+
+.. warning::
+    This code generator is currently not included in Icarus Verilog.
+
+The PAL target generates JEDEC output for a Programmable Array Logic.

Documentation/targets/tgt-pcb.rst

@@ -1,6 +1,6 @@
 
-Using the PCB code generator
+The PCB Code Generator (-tpcb)
-============================
+==============================
 
 The PCB target code generator is designed to allow a user to enter a netlist
 in Verilog format, then generate input files for the GNU PCB layout program.
@@ -55,7 +55,7 @@ Verilog parameter override syntax. Parameters have preferred types.
   is written into the description field of the PCB Element.
 
 * value (string, default="")
-  
+
   The "value" is a text tring that describes some value for the black
   box. Like the description, the code generator does not interpret this value,
   other then to write it to the appropriate field in the PCB Element."

Documentation/targets/tgt-sizer.rst

@@ -0,0 +1,49 @@
+
+The sizer Code Analyzer (-tsizer)
+=================================
+
+The sizer target does not generate any code. Instead it will print statistics about the Verilog code.
+
+It is important to synthesize the Verilog code before invoking the sizer. This can be done with the `-S` flag passed to iverilog. Note, that behavioral code can not be synthesized and will generate a warning when passed to the sizer.
+
+Example command::
+
+    % iverilog -o sizer.txt -tsizer -S -s top input.v
+
+With this example code:
+
+.. code-block:: verilog
+
+    module top (
+        input clock,
+        input reset,
+        output blink
+    );
+        reg out;
+
+        always @(posedge clock) begin
+            if (reset) begin
+                out = 1'b0;
+            end else begin
+                out <= !out;
+            end
+        end
+
+        assign blink = out;
+
+    endmodule
+
+The resulting `sizer.txt` will contain::
+
+    **** module/scope: top
+         Flip-Flops   : 1
+         Logic Gates  : 3
+         MUX[2]: 1 slices
+         LOG[13]: 1 unaccounted
+         LOG[14]: 1 unaccounted
+    **** TOTALS
+         Flip-Flops   : 1
+         Logic Gates  : 3
+         MUX[2]: 1 slices
+         LOG[13]: 1 unaccounted
+         LOG[14]: 1 unaccounted

Documentation/targets/tgt-stub.rst

@@ -0,0 +1,30 @@
+
+The stub Code Generator (-tstub)
+================================
+
+The stub code generator is a debugging aid for the Icarus Verilog compiler
+itself. It outputs a text dump of the elaborated design as it is passed to
+code generators.
+
+Example command::
+
+    % iverilog -o stub.txt -tstub -s top input.v
+
+With this example code:
+
+.. code-block:: verilog
+
+    module top;
+        initial $display("Hello World!");
+    endmodule
+
+The resulting `stub.txt` will contain::
+
+    root module = top
+    scope: top (0 parameters, 0 signals, 0 logic) module top time units = 1e0
+     time precision = 1e0
+    end scope top
+    # There are 0 constants detected
+    initial
+        Call $display(1 parameters); /* hello_world.v:2 */
+            <string="Hello World!", width=96, type=bool>

Documentation/targets/tgt-verilog.rst

@@ -0,0 +1,6 @@
+
+The Verilog Code Generator (-tverilog)
+======================================
+
+.. warning::
+    This code generator is currently not included in Icarus Verilog.

Documentation/targets/tgt-vlog95.rst

@@ -1,6 +1,6 @@
 
-Using The Verilog '95 Code Generator
+The Verilog '95 Code Generator (-tvlog95)
-====================================
+=========================================
 
 Icarus Verilog contains a code generator to emit 1995 compliant Verilog from
 the input Verilog netlist. This allows Icarus Verilog to function as a Verilog
@@ -42,21 +42,21 @@ Structures that cannot be converted to 1995 compatible Verilog
 The following Verilog constructs are not translatable to 1995 compatible Verilog:
 
 * Automatic tasks or functions.
-  
+
 * The power operator (**). Expressions of the form (2**N)**<variable> (where N
   is a constant) can be converter to a shift.
-  
+
 * Some System Verilog constructs (e.g. final blocks, ++/-- operators,
   etc.). 2-state variables are converted to 4-state variables.
 
 Icarus extensions that cannot be translated:
 
 * Integer constants greater than 32 bits.
-  
+
 * Real valued nets.
-  
+
 * Real modulus.
-  
+
 * Most Verilog-A constructs.
 
 

Documentation/targets/tgt-vvp.rst

@@ -0,0 +1,63 @@
+
+The vvp Code Generator (-tvvp)
+==============================
+
+The vvp target generates code for the "vvp" run time. This is the most
+commonly used target for Icarus Verilog, as it is the main simulation engine.
+
+Example command::
+
+    %  iverilog -o top.vvp -s top hello_world.v
+
+Equivalent command::
+
+    %  iverilog -o top.vvp -tvvp -s top hello_world.v
+
+With this example code in `hello_world.v`:
+
+.. code-block:: verilog
+
+    module top;
+        initial $display("Hello World!");
+    endmodule
+
+The resulting `top.vvp` will contain something similar to::
+
+    #! /usr/local/bin/vvp
+    :ivl_version "13.0 (devel)" "(s20221226-119-g8cb2e1a05-dirty)";
+    :ivl_delay_selection "TYPICAL";
+    :vpi_time_precision + 0;
+    :vpi_module "/usr/local/lib/ivl/system.vpi";
+    :vpi_module "/usr/local/lib/ivl/vhdl_sys.vpi";
+    :vpi_module "/usr/local/lib/ivl/vhdl_textio.vpi";
+    :vpi_module "/usr/local/lib/ivl/v2005_math.vpi";
+    :vpi_module "/usr/local/lib/ivl/va_math.vpi";
+    S_0x563c3c5d1540 .scope module, "top" "top" 2 1;
+     .timescale 0 0;
+        .scope S_0x563c3c5d1540;
+    T_0 ;
+        %vpi_call 2 2 "$display", "Hello World!" {0 0 0};
+        %end;
+        .thread T_0;
+    # The file index is used to find the file name in the following table.
+    :file_names 3;
+        "N/A";
+        "<interactive>";
+        "hello_world.v";
+
+The first line contains the shebang. If this file is executed, the shebang tells the shell to use vvp for the execution of this file.
+
+To run the simulation, execute::
+
+    %  ./top.vvp
+
+Or you can call vvp directly::
+
+    %  vvp top.vvp
+
+Next are some directives. The first one, `:ivl_version` specifies which version of iverilog this file was created with. Next is the delay selection with "min:typical:max" values and the time precision, which we did not set specifically, so the default value is used. The next lines tell vvp which VPI modules to load and in which order. The next lines tell vvp which VPI modules to load and in what order. Next, a new scope is created with the `.scope` directive and the timescale is set with `.timescale`. A thread `T_0` is created that contains two instructions: `%vpi_call` executes the VPI function `$display` with the specified arguments, and `%end` terminates the simulation.
+
+Opcodes
+-------
+
+The various available opcodes can be seen in :doc:`Opcodes <../developer/guide/vvp/opcodes>`

Documentation/targets/vvp.rst

@@ -1,6 +0,0 @@
-
-The vvp Code Generator (-tvvp)
-==============================
-
-The vvp target generates code for the "vvp" run time. This is the most
-commonly used target for Icarus Verilog, as it is the main simulation engine.

Documentation/usage/command_files.rst

@@ -124,7 +124,7 @@ list of the special records with their meaning.
   have multiple directories, separated by "+" characters.
 
 * +libdir-nocase+dir-path
-  
+
   This is the same as "+libdir+", but when searching "nocase" libraries for
   module files, case will not be taken as significant. This is useful when the
   library is on a case insensitive file system.
@@ -136,7 +136,7 @@ list of the special records with their meaning.
   variety of naming conventions.
 
 * -y dir-path
-  
+
   This is like "+libdir+" but each line takes only one path. Like "+libdir+"
   there can be multiple "-y" records to declare multiple library
   directories. This is similar to the "-y" flag on the iverilog command line.
@@ -151,19 +151,19 @@ list of the special records with their meaning.
   in releases and snapshots made after that date.
 
 * +incdir+*include-dir-path*
-  
+
   Declare a directory or list of directories to search for files included by
   the "include" compiler directive. The directories are searched in
   order. This is similar to the "-I" flag on the iverilog command line.
 
 * +define+*name=value*
-  
+
   Define the preprocessor symbol "name" to have the string value "value". If
   the value (and the "=") are omitted, then it is assumed to be the string
   "1". This is similar to the "-D" on the iverilog command line.
 
 * +timescale+*units/precision*
-  
+
   Define the default timescale. This is the timescale that is used if there is
   no other timescale directive in the Verilog source. The compiler default
   default is "+timescale+1s/1s", which this command file setting can
@@ -171,7 +171,7 @@ list of the special records with their meaning.
   timescale directive in the verilog source.
 
 * +toupper-filename
-  
+
   This token causes file names after this in the command file to be translated
   to uppercase. this helps with situations where a directory has passed
   through a DOS machine (or a FAT file system) and in the process the file
@@ -179,11 +179,11 @@ list of the special records with their meaning.
   emergencies.
 
 * +tolower-filename
-  
+
   The is the lowercase version of "+toupper-filename".
 
 * +parameter+*name=value*
-  
+
   This token causes the compiler to override a parameter value for a top-level
   module. For example, if the module main has the parameter WIDTH, set the
   width like this "+parameter+main.WIDTH=5". Note the use of the complete
@@ -191,7 +191,7 @@ list of the special records with their meaning.
   (top level) modules and a defparam may override the command file value.
 
 * +vhdl-work+*path*
-  
+
   When compiling VHDL, this token allows control over the directory to use for
   holding working package declarations. For example, "+vhdl-work+workdir" will
   cause the directory "workdir" to be used as a directory for holding working

Documentation/usage/command_line_flags.rst

@@ -14,17 +14,17 @@ General
 These flags affect the general behavior of the compiler.
 
 * -c <cmdfile>
-  
+
   This flag selects the command file to use. The command file is an
   alternative to writing a long command line with a lot of file names and
   compiler flags. See the Command File Format page for more information.
 
 * -d <flag>
-  
+
   Enable compiler debug output. These are aids for debugging Icarus Verilog,
   and this flag is not commonly used.
   The flag is one of these debug classes:
-  
+
   * scope
   * eval_tree
   * elaborate
@@ -40,15 +40,15 @@ These flags affect the general behavior of the compiler.
   The supported flags are:
 
   * 1995
-    
+
     This flag enables the IEEE1364-1995 standard.
 
   * 2001
-    
+
     This flag enables the IEEE1364-2001 standard.
 
   * 2001-noconfig
-    
+
     This flag enables the IEEE1364-2001 standard with config file support
     disabled. This eliminates the config file keywords from the language and
     so helps some programs written to older 2001 support compile.
@@ -64,17 +64,27 @@ These flags affect the general behavior of the compiler.
     support is ongoing.
 
   * 2012
-    
+
     This flag enables the IEEE1800-2012 standard, which includes
     SystemVerilog.
 
+  * 2017
+
+    This flag enables the IEEE1800-2017 standard, which includes
+    SystemVerilog.
+
+  * 2023
+
+    This flag enables the IEEE1800-2023 standard, which includes
+    SystemVerilog.
+
   * verilog-ams
-    
+
     This flag enables Verilog-AMS features that are supported by Icarus
     Verilog. (This is new as of 5 May 2008.)
 
   * assertions/supported-assertions/no-assertions
-    
+
     Enable or disable SystemVerilog assertions. When enabled, assertion
     statements are elaborated. When disabled, assertion statements are parsed
     but ignored. The supported-assertions option only enables assertions that
@@ -131,6 +141,18 @@ These flags affect the general behavior of the compiler.
     containing an unsized constant number, and unsized constant numbers are
     not truncated to integer width.
 
+  * strict-declaration/no-strict-declaration
+
+  * strict-net-var-declaration/no-strict-net-var-declaration
+
+  * strict-parameter-declaration/no-strict-parameter-declaration
+
+    The standards require that nets, variables, and parameters must be
+    declared lexically before they are used.  Using -gno-strict-declaration
+    will allow using a data object before declaration, with a warning. The
+    warning can be suppressed with -Wno-declaration-after-use.  The option
+    can be applied for nets and variables and for parameters separately.
+
   * shared-loop-index/no-shared-loop-index
 
     Enable or disable the exclusion of for-loop control variables from
@@ -260,6 +282,7 @@ These flags affect the general behavior of the compiler.
       -Wanachronisms
       -Wimplicit
       -Wimplicit-dimensions
+      -Wdeclaration-after-use
       -Wmacro-replacement
       -Wportbind
       -Wselect-range
@@ -278,7 +301,7 @@ These flags affect the general behavior of the compiler.
     will print a warning at its first use.
 
   * implicit-dimensions
-    
+
     This enables warnings for the case where a port declaration or a var/net
     declaration for the same name is missing dimensions. Normally, Verilog
     allows you to do this (the undecorated declaration gets its dimensions
@@ -288,41 +311,50 @@ These flags affect the general behavior of the compiler.
     This flag is supported in release 10.1 or master branch snapshots after
     2016-02-06.
 
+  * declaration-after-use
+
+    This enables warnings for declarations after use, when those are not
+    flagged as errors (enabled by default). Use no-declaration-after-use
+    to disable this.
+
+    This flag was added in version 14.0 or later (and is in the master branch
+    as of 2026-03-21).
+
   * macro-redefinition
-    
+
     This enables warnings when a macro is redefined, even if the macro text
     remains the same.
 
     NOTE: The "macro-redefinition" flag was added in v11.0.
 
   * macro-replacement
-    
+
     This enables warnings when a macro is redefined and the macro text
     changes. Use no-macro-redefinition to disable this,
 
     NOTE: The "macro-replacement" flag was added in v11.0.
 
   * portbind
-    
+
     This enables warnings for ports of module instantiations that are not
     connected properly, but probably should be. Dangling input ports, for
     example, will generate a warning.
 
   * select-range
-    
+
     This enables warnings for constant out-of-bound selects. This includes
     partial or fully out-of-bound select as well as a select containing a 'bx
     or 'bz in the index.
 
   * timescale
-    
+
     This enables warnings for inconsistent use of the timescale directive. It
     detects if some modules have no timescale, or if modules inherit timescale
     from another file. Both probably mean that timescales are inconsistent,
     and simulation timing can be confusing and dependent on compilation order.
 
   * infloop
-    
+
     This enables warnings for always statements that may have runtime infinite
     loops (i.e. has paths with zero or no delay). This class of warnings is
     not included in -Wall and hence does not have a no- variant. A fatal error
@@ -352,7 +384,7 @@ These flags affect the general behavior of the compiler.
     is large.
 
   * floating-nets
-    
+
     This enables warnings for nets that are present but have no drivers.
 
     This flag was added in version 11.0 or later (and is in the master branch
@@ -389,7 +421,7 @@ flags for the typical "C" compiler, so C programmers will find them familiar.
   for other tools. For example, this command::
 
     % iverilog -E -ofoo.v -DKEY=10 src1.v src2.v
-    
+
   runs the preprocessor on the source files src1.v and src2.v and produces the
   single output file foo.v that has all the preprocessing (including header
   includes and ifdefs) processed.
@@ -421,7 +453,7 @@ Elaboration Flags
 These are flags that pass information to the elaboration steps.
 
 * -P<symbol>=<value>
-  
+
   Define a parameter using the defparam behavior to override a parameter
   values. This can only be used for parameters of root module instances.
 

Documentation/usage/getting_started.rst

@@ -23,7 +23,7 @@ World program.
 .. code-block:: verilog
 
   module hello;
-    initial 
+    initial
       begin
         $display("Hello, World");
         $finish ;
@@ -65,21 +65,21 @@ example, the counter model in counter.v
 
 .. code-block:: verilog
 
-  module counter(output, clk, reset);
+  module counter(out, clk, reset);
 
     parameter WIDTH = 8;
 
-    output [WIDTH-1 : 0] output;
+    output [WIDTH-1 : 0] out;
-    input 	       clk, reset;
+    input	       clk, reset;
 
     reg [WIDTH-1 : 0]   out;
-    wire 	       clk, reset;
+    wire	       clk, reset;
 
     always @(posedge clk or posedge reset)
       if (reset)
-        output <= 0;
+        out <= 0;
       else
-        output <= output + 1;
+        out <= out + 1;
 
   endmodule // counter
 

Documentation/usage/icarus_verilog_extensions.rst

@@ -0,0 +1,173 @@
+
+Icarus Verilog Extensions
+=========================
+
+Icarus Verilog supports certain extensions to the baseline IEEE 1364
+standard. Some of these are picked from extended variants of the
+language, such as SystemVerilog, and some are expressions of internal
+behavior of Icarus Verilog, made available as a tool debugging aid.
+
+Don't use any of these extensions if you want to keep your code portable
+across other Verilog compilers.
+
+System Functions
+----------------
+
+``$is_signed(<expr>)``
+^^^^^^^^^^^^^^^^^^^^^^
+
+This function returns 1 if the expression contained is signed, or 0 otherwise.
+This is mostly of use for compiler regression tests.
+
+``$bits(<expr>)``, ``$sizeof(<expr>)``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``$bits`` system function returns the size in bits of the expression that
+is its argument. The result of this function is undefined if the argument
+doesn't have a self-determined size.
+
+The ``$sizeof`` system function is deprecated in favour of ``$bits``, which is
+the same thing, but included in the SystemVerilog definition.
+
+``$simtime()``
+^^^^^^^^^^^^^^
+
+This returns as a 64bit value the simulation time, unscaled by the time units
+of the local scope. This is different from the ``$time`` and ``$stime``
+functions which return the scaled times. This function is added for regression
+testing of the compiler and run time, but can be used by applications who
+really want the simulation time.
+
+Note that the simulation time can be confusing if there are lots of different
+```timescales`` within a design. It is not in general possible to predict
+what the simulation precision will turn out to be.
+
+``$mti_random()``, ``$mti_dist_uniform``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These functions are similar to the IEEE 1364 standard ``$random`` functions,
+but they use the Mersenne Twister (MT19937) algorithm. This is considered an
+excellent random number generator, but does not generate the same sequence as
+the standardized ``$random``.
+
+System Tasks
+------------
+
+``$readmempath``
+^^^^^^^^^^^^^^^^
+
+The ``$readmemb`` and ``$readmemh`` system tasks read text files that contain
+data values to populate memories. Normally, those files are found in a current
+working directory. The ``$readmempath()`` system task can be used to create a
+search path for those files. For example:
+
+.. code-block:: verilog
+
+  reg [7:0] mem [0:7];
+  initial begin
+    $readmemh("datafile.txt", mem);
+  end
+
+This assumes that "datafile.txt" is in the current working directory where
+the ``vvp`` command is running. But with the ``$readmempath``, one can specify
+a search path:
+
+.. code-block:: verilog
+
+  reg [7:0] mem [0:7];
+  initial begin
+    $readmempath(".:alternative:/global/defaults");
+    $readmemh("datafile.txt", mem);
+  end
+
+In this example, "datafile.txt" is searched for in each of the directories
+in the above list (separated by ":" characters). The first located instance
+is the one that is used. So for example, if "./datafile.txt" exists, then it
+is read instead of "/global/defaults/datafile.txt" even if the latter exists.
+
+``$finish_and_return(code)``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This task operates the same as the ``$finish`` system task, but adds the
+feature of specifying an exit code for the interpreter. This can be useful in
+automated test environments to indicate whether the simulation finished with
+or without errors.
+
+Extended Verilog Data Types
+---------------------------
+
+This feature is turned on by the generation flag "-gxtypes" and turned
+off by the generation flag "-gno-xtypes". It is turned on by default.
+
+Icarus Verilog adds support for extended data types. This extended
+type syntax is based on a proposal by Cadence Design Systems,
+originally as an update to the IEEE 1364 standard. Icarus Verilog
+currently only takes the new primitive types from the proposal.
+
+SystemVerilog provides the same functionality using somewhat different
+syntax. This extension is maintained for backwards compatibility.
+
+- Types
+
+Extended data types separates the concept of net/variable from the
+data type. Both nets and variables can declared with any data
+type. The primitive types available are::
+
+    logic  - The familiar 0, 1, x and z, optionally with strength.
+    bool   - Limited to only 0 and 1
+    real   - 64-bit real values
+
+Nets with logic type may have multiple drivers with strength, and the
+value is resolved the usual way. Only logic values may be driven to
+logic nets, so bool values driven onto logic nets are implicitly
+converted to logic.
+
+Nets with any other type may not have multiple drivers. The compiler
+should detect the multiple drivers and report an error.
+
+- Declarations
+
+The declaration of a net is extended to include the type of the wire,
+with the syntax::
+
+    wire <type> <wire-assignment-list>... ;
+
+The <type>, if omitted, is taken to be logic. The "wire" can be any of
+the net keywords. Wires can be logic, bool, real, or vectors of logic
+or bool. Some valid examples::
+
+    wire real foo = 1.0;
+    tri logic bus[31:0];
+    wire bool addr[23:0];
+    ... and so on.
+
+The declarations of variables is similar. The "reg" keyword is used to
+specify that this is a variable. Variables can have the same data
+types as nets.
+
+- Ports
+
+Module and task ports in standard Verilog are restricted to logic
+types. This extension removes that restriction, allowing any of
+the above types to pass through the port consistent with the
+continuous assignment connectivity that is implied by the type.
+
+- Expressions
+
+Expressions in the face of real values is covered by the baseline
+Verilog standard.
+
+The bool type supports the same operators as the logic type, with the
+obvious differences imposed by the limited domain.
+
+Comparison operators (not case compare) return logic if either of
+their operands is logic. If both are bool or real (including mix of
+bool and real) then the result is bool. This is because comparison of
+bools and reals always return exactly true or false.
+
+Case comparison returns bool. This differs from baseline Verilog,
+which strictly speaking returns a logic, but only 0 or 1 values.
+
+Arithmetic operators return real if either of their operands is real,
+otherwise they return logic if either of their operands is logic. If
+both operands are bool, they return bool.

Documentation/usage/icarus_verilog_quirks.rst

@@ -0,0 +1,438 @@
+
+Icarus Verilog Quirks
+=====================
+
+This is a list of known quirks that are presented by Icarus Verilog. The idea
+of this chapter is to call out ways that Icarus Verilog differs from the
+standard, or from other implementations.
+
+This is NOT AN EXHAUSTIVE LIST. If something is missing from this list, let us
+know and we can add documentation.
+
+Unsized Numeric Constants are Not Limited to 32 Bits
+----------------------------------------------------
+
+The Verilog standard allows Verilog implementations to limit the size of
+unsized constants to a bit width of at least 32. That means that a constant
+17179869183 (``36'h3_ffff_ffff``) may overflow some compilers. In fact, it
+is common to limit these values to 32 bits. However, a compiler may just as
+easily choose another width limit, for example 64 bits. That value is
+equally good.
+
+However, it is not required that an implementation truncate at 32 bits, and
+in fact Icarus Verilog does not truncate at all. It will make the unsized
+constant as big as it needs to be to hold the value accurately. This is
+especially useful in situations like this;
+
+.. code-block:: verilog
+
+ reg [width-1:0] foo = 17179869183;
+
+The programmer wants the constant to take on the width of the reg, which in
+this example is parameterized. Since constant sizes cannot be parameterized,
+the programmer ideally gives an unsized constant, which the compiler then
+expands/contracts to match the l-value.
+
+Also, by choosing to not ever truncate, Icarus Verilog can handle code written
+for a 64 bit compiler as easily as for a 32 bit compiler. In particular, any
+constants that the user does not expect to be arbitrarily truncated by their
+compiler will also not be truncated by Icarus Verilog, no matter what that
+other compiler chooses as a truncation point.
+
+Unsized Expressions
+-------------------
+
+Icarus Verilog classes any expression containing an unsized numeric constant
+or unsized parameter value that is not part of a self-determined operand as
+an unsized expression. When calculating the bit width of an unsized expression,
+it extends the width of the expression to avoid arithmetic overflow or
+underflow; in other words, the expression width will be made large enough to
+represent any possible arithmetic result of the expression. If the expression
+contains operations that do not follow the normal rules of arithmetic (e.g. an
+explicit or implicit cast between signed and unsigned values), the expression
+width will be extended to at least the width of an integer.
+
+An exception to the above is made if the expression contains a shift or power
+operator with a right hand operand that is a non-constant unsized expression.
+In this case any expansion of the expression width due to that operation is
+limited to the width of an integer, to avoid excessive expression widths
+(without this, an expression such as ``2**(i-1)``, where ``i`` is an integer,
+would be expanded to 2\**33 bits).
+
+The above behaviour is a deviation from the Verilog standard, which states
+that when calculating an expression width, the width of an unsized constant
+number is the same as the width of an integer. If you need strict standard
+compliance (for compatibility with other EDA tools), then the compiler has
+a command line option, ``-gstrict-expr-width``, which disables the special
+treatment of unsized expressions. With this option, the compiler will output
+a warning message if an unsized numeric constant is encountered that cannot
+be represented in integer-width bits and will truncate the value.
+
+If you are simulating synthesisable code, it is recommended that the
+``-gstrict-expr-width`` option is used, as this eliminates a potential
+source of synthesis vs. simulation mismatches.
+
+Unsized Parameters
+------------------
+
+Icarus Verilog classes any parameter declaration that has no explicit or
+implicit range specification as an unsized parameter declaration. When
+calculating the bit width of the final value expression for the parameter,
+it follows the same rules as it does for unsized expressions, regardless of
+whether or not the expression contains any unsized numeric constants.
+
+If the final value expression for an unsized parameter is an unsized
+expression (i.e. does contain unsized numeric constants), any subsequent use
+of that parameter will be treated as if it was an unsized numeric constant.
+If not, it will be treated as if it was a numeric constant of the appropriate
+size. For example, with the declarations:
+
+.. code-block:: verilog
+
+  localparam Value1 =  'd3 +  'd2;
+  localparam Value2 = 2'd3 + 2'd2;
+
+any subsequent use of ``Value1`` will be treated as if the programmer had
+written ``'d5`` and any subsequent use of ``Value2`` will be treated as if
+the programmer had written ``3'd5``. In particular, note that ``Value2`` can
+be used as a concatenation operand, but ``Value1`` cannot.
+
+The above behaviour is a deviation from the Verilog standard. As for
+unsized expressions, if you need strict standard compliance. use the
+``-gstrict-expr-width`` compiler option.
+
+Unsized Expressions as Arguments to Concatenation
+-------------------------------------------------
+
+The Verilog standard clearly states in 4.1.14:
+
+  "Unsized constant numbers shall not be allowed in  concatenations. This
+  is because the size of each  operand in the concatenation is needed to
+  calculate the complete size of the concatenation."
+
+So for example the expression ``{1'b0, 16}`` is clearly illegal. It also stands
+to reason that ``{1'b0, 15+1}`` is illegal, for exactly the same justification.
+What is the size of the expression (15+1)? Furthermore, it is reasonable to
+expect that (16) and (15+1) are exactly the same so far as the compiler is
+concerned.
+
+Unfortunately, Cadence seems to feel otherwise. In particular, it has been
+reported that although ``{1'b0, 16}`` causes an error, ``{1'b0, 15+1}`` is
+accepted. Further testing shows that any expression other than a simple
+unsized constant is accepted there, even if all the operands of all the
+operators that make up the expression are unsized integers.
+
+This is a semantic problem. Icarus Verilog doesn't limit the size of integer
+constants. This is valid as stated in 2.5.1 Note 3:
+
+  "The number of bits that make up an unsized number (which is a simple
+  decimal number or a number without the size specification) shall be
+  **at least** 32." [emphasis added]
+
+Icarus Verilog will hold any integer constant, so the size will be as large as
+it needs to be, whether that is 64 bits, 128 bits, or more. With this in mind,
+what is the value of these expressions?
+
+.. code-block:: verilog
+
+  {'h1_00_00_00_00}
+  {'h1 << 32}
+  {'h0_00_00_00_01 << 32}
+  {'h5_00_00_00_00 + 1}
+
+These examples show that the standard is justified in requiring that the
+operands of concatenation have size. The dispute is what it takes to cause
+an expression to have a size, and what that size is. Verilog-XL claims that
+(16) does not have a size, but (15+1) does. The size of the expression (15+1)
+is the size of the adder that is created, but how wide is the adder when
+adding unsized constants?
+
+One might note that the quote from section 4.1.14 says "Unsized constant
+numbers shall not be allowed." It does not say "Unsized expressions...", so
+arguably accepting (15+1) or even (16+0) as an operand to a concatenation is
+not a violation of the letter of the law. However, the very next sentence of
+the quote expresses the intent, and accepting (15+1) as having a more defined
+size then (16) seems to be a violation of that intent.
+
+Whatever a compiler decides the size is, the user has no way to predict it,
+and the compiler should not have the right to treat (15+1) any differently
+then (16). Therefore, Icarus Verilog takes the position that such expressions
+are unsized and are not allowed as operands to concatenations. Icarus Verilog
+will in general assume that operations on unsized numbers produce unsized
+results. There are exceptions when the operator itself does define a size,
+such as the comparison operators or the reduction operators. Icarus Verilog
+will generate appropriate error messages.
+
+Scope of Macro Defines Doesn't Extend into Libraries
+----------------------------------------------------
+
+Icarus Verilog does preprocess modules that are loaded from libraries via the
+``-y`` mechanism to substitute macros and load includes. However, the only
+macros defined during compilation of an automatically loaded library module
+file are those that it defines itself (or includes) or that are defined on the
+command line or in the command file. Specifically, macros defined in the non-
+library source files are not remembered when the library module is loaded, and
+macros defined in a library module do not escape into the rest of the design.
+This is intentional. If it were otherwise, then compilation results might vary
+depending on the order that libraries are loaded, and that is unacceptable.
+
+For example, given sample library module ``a.v``:
+
+.. code-block:: verilog
+
+  `define MACRO_A 1
+  module a(input x);
+    always @(x) $display("x=",x);
+  endmodule
+
+and sample library module ``b.v``:
+
+.. code-block:: verilog
+
+  module b(input y);
+  `ifdef MACRO_A
+    always @(y) $display("MACRO_A is defined",,y);
+ `else
+    always @(y) $display("MACRO_A is NOT defined",,y);
+  `endif
+  endmodule
+
+If a program instantiates both of these modules, there is no way to know
+which will be loaded first by the compiler, so if the definition of
+``MACRO_A`` in ``a.v`` were to escape, then there is no way to predict or
+control whether ``MACRO_A`` is defined when ``b.v`` is processed. So the
+preprocessor processes automatic library module files as if they are in
+their own compilation unit, and you can know that ``MACRO_A`` will not be
+defined in ``b.v`` unless it is defined on the command line (a ``-D`` flag)
+or in the command file (a ``+define+`` record.)
+
+Of course if ``a.v`` and ``b.v`` were listed in the command file or on the
+command line, then the situation is different; the order is clear. The files
+are processed as if they were concatenated in the order that they are listed
+on the command line. The non-library modules are all together in a main
+compilation unit, and they are all processed before any library modules are
+loaded.
+
+It is said that some commercial compilers do allow macro definitions to span
+library modules. That's just plain weird. However, there is a special case
+that Icarus Verilog does handle. Preprocessor definitions that are made in
+files explicitly listed on the command line or in the command file, do pass
+into implicitly loaded library files. For example, given the source file
+``x.v``:
+
+.. code-block:: verilog
+
+  module main;
+    reg foo;
+    b dut(foo);
+  endmodule
+  `define MACRO_A
+
+and the library module file ``b.v`` described above, the situation is well
+defined, assuming the ``x.v`` file is listed on the command line or in the
+command file. The library module will receive the ``MACRO_A`` definition
+from the last explicitly loaded source file. The position of the define of
+``MACRO_A`` in the explicitly loaded source files does not matter, as all
+explicitly loaded source files are preprocessed before any library files
+are loaded.
+
+Continuous Assign L-Values Can Implicit-Define Wires
+----------------------------------------------------
+
+The IEEE 1364-2001 standard, Section 3.5, lists the cases where nets may be
+implicitly created. These include:
+
+- identifier is a module port
+- identifier is passed as a port to a primitive or module
+
+This does not seem to include continuous assignment l-values (or r-values)
+so the standard does not justify allowing implicit declarations of nets by
+continuous assignment.
+
+However, it has been reported that many Verilog compilers, including the big
+name tools, do allow this. So, Icarus Verilog will allow it as well, as an
+extension. If ``-gxtypes`` (the default) is used, this extension is enabled.
+To turn off this behavior, use the ``-gno-xtypes`` flag.
+
+Dumping Array Words (``$dumpvars``)
+-----------------------------------
+
+Icarus has the ability to dump individual array words. They are only dumped
+when explicitly passed to $dumpvars. They are not dumped by default. For
+example given the following:
+
+.. code-block:: verilog
+
+  module top;
+    reg [7:0] array [2:0];
+    initial begin
+      $dumpvars(0, array[0], array[1]);
+      ...
+    end
+  endmodule
+
+``array[0]`` and ``array[1]`` will be dumped whenever they change value. They
+will be displayed as an escaped identifier and GTKWave fully supports this.
+Note that this is an implicitly created escaped identifier that could conflict
+with an explicitly created escaped identifier. You can automate adding the
+array word by adding an index definition
+
+.. code-block:: verilog
+
+  integer idx;
+
+and replacing the previous $dumpvars statement with
+
+.. code-block:: verilog
+
+  for (idx = 0; idx < 2; idx = idx + 1) $dumpvars(0, array[idx]);
+
+This will produce the same results as the previous example, but it is much
+easier to specify/change which elements are to be dumped. One important note
+regarding this syntax. Most system tasks/functions keep the variable selection
+(for this case it is a variable array word selection) context. If ``$dumpvars``
+did this then all callback created would point to this element and would use
+the same index which for the example above would have the value 2. This is
+certainly not what is desired and for this special case when ``$dumpvars``
+executes it uses the current index value to create a constant array selection
+and that is monitored instead of the original variable selection.
+
+Referencing Declarations Within an Unnamed Generate Block
+---------------------------------------------------------
+
+The IEEE 1364-2005 standard permits generate blocks to be unnamed, but states:
+
+  "If the generate block selected for instantiation is not named, it still
+  creates a scope; but the declarations within it cannot be referenced using
+  hierarchical names other than from within the hierarchy instantiated by the
+  generate block itself."
+
+The standard later defines a scheme for automatically naming the unnamed
+scopes for use with external interfaces.
+
+Icarus Verilog implements the defined automatic naming scheme, but does not
+prevent the automatically generated names being used in a hierarchical
+reference. This behaviour is harmless - the automatically generated names are
+guaranteed to be unique within the enclosing scope, so there is no possibility
+of confusion with explicit scope names. However, to maintain code portability,
+it is recommended that this behavior is not exploited.
+
+``%g/%G`` Format Specifiers
+---------------------------
+
+In the IEEE 1364-2001 standard there is a general statement that the real
+number format specifiers will use the full formatting capabilities of C.
+This is then followed by an example that describes ``%10.3g``. The example
+description would be correct for the ``%e`` format specifier which should
+always have three fractional digits, but the ``%g`` format specifier does
+not work that way. For it the ``.3`` specifies that there will be three
+significant digits. What this means is that ``%g`` will always produce one
+less significant digit than ``%e`` and will only match the output from ``%f``
+for certain values. For example:
+
+.. code-block:: verilog
+
+  module top_level;
+    real rval;
+    initial begin
+      rval = 1234567890;
+      $display("This is g and e: %10.3g, %10.3e.", rval, rval);
+      rval = 0.1234567890;
+      $display("This is g and f: %10.3g, %10.3f.", rval, rval);
+      rval = 1.234567890;
+      $display("This is more g and f: %10.3g, %10.3f.", rval, rval);
+    end
+  endmodule // top_level
+
+will produce the following output:
+
+.. code-block:: verilog
+
+ This is g and e:   1.23e+09,  1.235e+09.
+ This is g and f:      0.123,      0.123.
+ This is more g and f:       1.23,      1.235.
+
+``%t`` Time Format Specifier Can Specify Width
+----------------------------------------------
+
+Standard Verilog does not allow width fields in the ``%t`` formats of display
+strings. For example, this is illegal:
+
+.. code-block:: verilog
+
+  $display("Time is %0t", $time);
+
+Standard Verilog instead relies on the ``$timeformat`` to completely specify
+the format.
+
+Icarus Verilog allows the programmer to specify the field width. The ``%t``
+format in Icarus Verilog works exactly as it does in standard Verilog.
+However, if the programmer chooses to specify a minimum width (i.e., ``%5t``),
+then for that display Icarus Verilog will override the ``$timeformat`` minimum
+width and use the explicit minimum width.
+
+``%v`` Format Specifier Can Display Vectors
+-------------------------------------------
+
+The IEEE 1364-2005 standard limits the ``%v`` specifier in display strings to
+work only with a single bit. Icarus Verilog extends that to support displaying
+the strength of vectors. The output is a strength specifier for each bit of the
+vector, with underscore characters separating each bit, e.g. ``St0_St1_Pu1_HiZ``.
+Most other tools will just print the strength of the least significant bit of
+a vector, so this may give different output results for code that otherwise
+works fine.
+
+Assign/Deassign and Force/Release of Bit/Part Selects
+-----------------------------------------------------
+
+Icarus Verilog allows as an extension the assign/deassign and force/release
+of variable bit and part selects in certain cases. This allows the Verilog
+test bench writer to assign/deassign for example single bits of a variable
+(register, etc.). Other tools will report this as an error.
+
+``repeat`` Statement is Sign Aware
+----------------------------------
+
+The standard does not specify what to do for this case, but it does say what
+a repeat event control should do. In Icarus Verilog the ``repeat`` statement
+is consistent with the repeat event control definition. If the argument is
+signed and is a negative value this will be treated the same as an argument
+value of 0.
+
+Built-in System Functions May Be Evaluated at Compile Time
+----------------------------------------------------------
+
+Certain of the system functions have well-defined meanings, so can
+theoretically be evaluated at compile-time, instead of using runtime VPI
+code. Doing so means that VPI cannot override the definitions of functions
+handled in this manner. On the other hand, this makes them synthesizable,
+and also allows for more aggressive constant propagation. The functions
+handled in this manner are:
+
+- ``$bits``
+- ``$signed``
+- ``$sizeof``
+- ``$unsigned``
+
+Implementations of these system functions in VPI modules will be ignored.
+
+``vpiScope`` Iterator on ``vpiScope`` Objects
+---------------------------------------------
+
+In the VPI, the normal way to iterate over ``vpiScope`` objects contained
+within a ``vpiScope`` object, is the ``vpiInternalScope`` iterator. Icarus
+Verilog adds support for the ``vpiScope`` iterator of a ``vpiScope`` object,
+that iterates over *everything* that is contained in the current scope. This
+is useful in cases where one wants to iterate over all the objects in a scope
+without iterating over all the contained types explicitly.
+
+Time 0 Race Resolution
+----------------------
+
+Combinational logic is routinely modelled using always blocks. However, this
+can lead to race conditions if the inputs to the combinational block are
+initialized in initial statements. Icarus Verilog slightly modifies time 0
+scheduling by arranging for always statements with ANYEDGE sensitivity lists
+to be scheduled before any other threads. This causes combinational always
+blocks to be triggered when the values in the sensitivity list are initialized
+by initial threads.

Documentation/usage/index.rst

@@ -2,8 +2,7 @@
 Icarus Verilog Usage
 ====================
 
-This section contains documents to help support developers who contribute to
+This section contains documents to help support Icarus Verilog users.
-Icarus Verilog.
 
 .. toctree::
    :maxdepth: 1
@@ -14,9 +13,13 @@ Icarus Verilog.
    command_line_flags
    command_files
    verilog_attributes
+   ivlpp_flags
    vvp_flags
-   gtkwave
    vvp_debug
+   vvp_library
+   vhdlpp_flags
+   waveform_viewer
    vpi
-   ivl_target
+   icarus_verilog_extensions
+   icarus_verilog_quirks
    reporting_issues

Documentation/usage/installation.rst

@@ -2,34 +2,36 @@
 Installation Guide
 ==================
 
-Icarus Verilog may be installed from source code, or from pre-packaged binary
+Icarus Verilog may be installed from source code (either from ``git`` or a
-distributions. If you don't have need for the very latest, and prepackaged
+released `tar/zip` file), or from pre-packaged binary distributions. If you
-binaries are available, that would be the best place to start.
+don't have a need for the very latest, and prepackaged binaries are available,
+that is the easiest 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
+Windows systems using the `Cygwin/MSYS2` environments or `MinGW` compilers. The
-instructions are the common steps for obtaining the Icarus Verilog source,
+following instructions are the common steps for obtaining the Icarus Verilog
-compiling and installing. Note that there are precompiled and/or prepackaged
+source code, compiling, installing, and checking the compiled code is working
-versions for a variety of systems, so if you find an appropriate packaged
+properly. Note that there are pre-compiled and/or prepackaged versions for a
-version, then that is the easiest way to install.
+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
+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
+system. You can use ``git`` to get the latest development head or the latest of
-specific branch. Stable releases are placed on branches, and in particular v11
+a specific branch. Stable releases are placed on branches, and in particular V12
-stable releases are on the branch "v11-branch" To get the development version
+stable releases are on the branch "v12-branch" To get the development version
 of the code follow these steps::
 
-  % git config --global user.name "Your Name Goes Here"   
+  % git config --global user.name "Your Name Goes Here"
-  % git config --global user.email you@yourpublicemail.example.com   
+  % git config --global user.email you@yourpublicemail.example.com
   % 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
+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::
@@ -37,19 +39,26 @@ 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
+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
+the `v12-branch` (the branch where the latest V12 patches are) then you
-that branch with the command::
+checkout that branch with the command::
 
-  % git checkout --track -b v11-branch origin/v11-branch
+  % git checkout --track -b v12-branch origin/v12-branch
 
-This creates a local branch that tracks the v11-branch in the repository, and
+This creates a local branch that tracks the `v12-branch` in the repository, and
-switches you over to your new v11-branch. The tracking is important as it
+switches you over to your new `v12-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
+`v12-branch`. You always work on a local branch, then merge only when you
 push/pull from the remote repository.
 
+The choice between the development branch and the latest released branch
+depends on your stability requirements. The released branch will only get bug
+fixes. It will not get any enhancements or changes in the compiler output
+format. Unlike many project the development branch is fairly stable with only
+occasional periods of instability. We do most of our big changes in side
+branches and only merge them into the development branch when they are clean.
+
 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::
@@ -59,22 +68,33 @@ development source by using the git command::
 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::
+To build the `configure` script and hash files you need to run the
+following::
 
   % sh autoconf.sh
+  % cd ..
 
-The source is then compiled as appropriate for your system. See the specific
+This is not need for the released `tar/zip` files since they already contain
-build instructions below for your operation system for what to do next.
+these files. You only need to run this once after cloning. If you are missing
+``autoconf`` or ``gperf`` then the script will fail::
 
-You will need autoconf and gperf installed in order for the script to work.
+  Autoconf in root...
-If you get errors such as::
+  autoconf.sh: 10: autoconf: not found
-
+  Precompiling lexor_keyword.gperf
-  Autoconf in root...   
-  autoconf.sh: 10: autoconf: not found   
-  Precompiling lexor_keyword.gperf  
   autoconf.sh: 13: gperf: not found.
 
-You will need to install download and install the autoconf and gperf tools.
+You will need to install the ``autoconf`` and ``gperf`` tools before you can
+continue.
+
+The other way to get the source code is to download a released `tar/zip` file::
+
+  % tar -xvzf v13_0.tar.gz
+  or
+  % unzip v13_0.zip
+
+See the build instructions for your operation system below to know what to do
+next. Though first determine if there are any extra configuration option you
+may need.
 
 Icarus Specific Configuration Options
 -------------------------------------
@@ -93,37 +113,215 @@ 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). ::
+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
-need when checking for basic errors with valgrind.
+needed when checking for basic errors with valgrind and should not be used if
+you just intend to use ``iverilog`` as a simulator. ::
+
+  --enable-libvvp
+
+The vvp program 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. ::
+
+  --enable-libveriuser
+
+PLI version 1 (the ACC and TF routines) were deprecated in IEEE 1364-2005.
+These are supported in Icarus Verilog by the libveriuser library and cadpli
+module. Starting with V13, these will only be built if this option is used.
 
 Compiling on Linux/Unix
 -----------------------
 
-(Note: You will need to install bison, flex, g++ and gcc) This is probably the
+Note: For a gcc compile you will need to install ``bison``, ``flex``, ``g++``,
-easiest case. Given that you have the source tree from the above instructions,
+``gcc`` and preferably `bz2`, `zlib` and `readline` development packages. The
-the compile and install is generally as simple as::
+`bz2` and `zlib` development packages are required for the non-VCD waveform
+dumpers and the `readline` development package is needed to enable better
+terminal control in the ``vvp`` interactive mode.
 
-  % ./configure  
+If you are only compiling one variant then you can compile directly in the
-  % make  
+source tree. If you need multiple variants (optimized, debugging, multiple
-  (su to root)  
+compilers) then it is recommended you compile each in their own directory.
-  # make install
 
-The "make install" typically needs to be done as root so that it can install
+For multiple variants create a directory for each of the variants you intend
-in directories such as "/usr/local/bin" etc. You can change where you want to
+to create and in each run the following steps, adjusting the options in the
-install by passing a prefix to the "configure" command::
+configure stage to get the functionality you want. For a single build you can
+either build it with the source or in a separate build directory.
 
-  % ./configure --prefix=/my/special/directory
+The following is from a Ubuntu 22.04 machine using gcc (version 11.4)::
 
-This will configure the source for eventual installation in the directory that
+  % mkdir gcc
-you specify. Note that "rpm" packages of binaries for Linux are typically
+  % cd gcc
-configured with "--prefix=/usr" per the Linux File System Standard.
+  or
+  % cd iverilog
 
-Make sure you have the latest version of flex otherwise you will get an error
+You can also use ``clang/clang++``. I usual build optimized version for
+normal use and reserve debugging options for a valgrind or a separate
+debugging build. Make sure you have `sudo` permission if you are using a
+system prefix area, otherwise you need to use some place you have
+permission to install (e.g. ~/).::
+
+  % env CFLAGS=-O2 CXXFLAGS=-O2 LDFLAGS=-s CC=gcc CXX=g++ ../iverilog/configure --enable-suffix=-gcc --prefix=/usr/local
+
+This will generate the following (with some inline comments)::
+
+  checking build system type... x86_64-pc-linux-gnu
+  checking host system type... x86_64-pc-linux-gnu
+  checking for gcc... gcc
+  checking whether the C compiler works... yes
+  ...
+  checking for gperf... gperf       # required for git builds
+  checking for man... man           # you likely want manual pages
+  checking for ps2pdf... ps2pdf
+  checking for groff... groff
+  checking for git... git           # required for git builds
+  checking for flex... flex         # required
+  checking for bison... bison       # required
+  ...
+  checking for tputs in -ltermcap... yes
+  checking for readline in -lreadline... yes
+  checking for add_history in -lreadline... yes
+  checking for readline/readline.h... yes
+  checking for readline/history.h... yes           # you likely want this
+  ...
+  checking for pthread_create in -lpthread... yes
+  checking for gzwrite in -lz... yes
+  checking for gzwrite in -lz... (cached) yes
+  checking for BZ2_bzdopen in -lbz2... yes
+  checking for BZ2_bzdopen in -lbz2... (cached) yes     # you want these for fst dumping
+  ...
+  <Create all the parameterized Makefile and header files>
+
+Usually if ``configure`` fails there is some required dependency missing. I
+usually review all the output to make sure it makes sense (e.g. I requested
+``gcc`` and that's what is being used, other things match my expectation). If
+all the waveform dumpers are not enabled there could be a few test failures.
+
+Next we need to compile the code. Note: make sure you are using GNU make.
+It may be named gmake (e.g. GhostBSD)::
+
+  % make check >& make.log
+
+This is for a tcsh/csh shell. Bash/fish/zsh use ``&>`` instead of ``>&``.
+Once this has completed check the make.log for any errors. There should not
+be any! I also check for warnings. There are often some related to the
+output from bison. For example::
+
+  From: ./parse.cc
+  parse.cc:9462:18: warning: missing initializer for member ‘vlltype::lexical_pos’ [-Wmissing-field-initializers]
+   9462 |   = { 1, 1, 1, 1 }
+        |                  ^
+  parse.cc:9462:18: warning: missing initializer for member ‘vlltype::text’ [-Wmissing-field-initializers]
+
+and::
+
+  From: ./vvp/parse.cc
+  parse.cc:3242: warning: suspicious sequence in the output: m4_type [-Wother]
+  parse.cc:3248: warning: suspicious sequence in the output: m4_type [-Wother]
+
+Are common, but benign warnings. Different compilers or compiler versions may
+have other warnings.
+
+The expected last few lines of the make.log file and these indicate everything
+should be working as expected are::
+
+  ...
+  driver/iverilog -B. -BMvpi -BPivlpp -tcheck -ocheck.vvp ../iverilog/examples/hello.vl
+  vvp/vvp -M- -M./vpi ./check.vvp | grep 'Hello, World'
+  Hello, World
+
+If everything is good to this point and you are installing into a system
+prefix; install using ``sudo`` as shown below. If you are installing into a
+personal location skip the ``sudo``::
+
+  % sudo make install
+
+Now you should verify the regression test suite is working as expected::
+
+  % cd ../iverilog/ivtest
+  % ./vvp_reg.pl --suffix=-gcc
+
+This is the original test script and should give no failures::
+
+  Running compiler/VVP tests for Icarus Verilog version: 13, suffix: -gcc.
+  ----------------------------------------------------------------------------
+              macro_with_args: Passed.
+                         mcl1: Passed.
+                        pr622: Passed.
+                        pr639: Passed.
+                           ...
+                     ssetclr2: Passed.
+                     ssetclr3: Passed.
+             synth_if_no_else: Passed.
+                  ufuncsynth1: Passed.
+  ============================================================================
+  Test results:
+    Total=3018, Passed=3013, Failed=0, Not Implemented=2, Expected Fail=3
+
+Next run the new test script::
+
+  % ./vvp_reg.py --suffix=-gcc
+
+This should also give no failures::
+
+  Running compiler/VVP tests for Icarus Verilog version: 13, suffix: -gcc
+  Using list(s): regress-vvp.list
+  ----------------------------------------------------------------------------
+                      always4A: Passed - CE.
+                      always4B: Passed - CE.
+                       analog1: Not Implemented.
+                       analog2: Not Implemented.
+                            ...
+                vvp_quiet_mode: Passed.
+               warn_opt_sys_tf: Passed - EF.
+                         wreal: Passed.
+              writemem-invalid: Passed - EF.
+  ============================================================================
+  Test results: Ran 284, Failed 0.
+
+Finally you can check that the VPI is working properly using::
+
+  % ./vpi_reg.pl --suffix=-gcc
+
+The output for this should have no failures::
+
+  Running VPI tests for Icarus Verilog version: 13, suffix: -gcc.
+  ----------------------------------------------------------------------------
+            br_gh59: Passed.
+           br_gh73a: Passed.
+           br_gh73b: Passed.
+           br_gh117: Passed.
+                 ...
+   value_change_cb2: Passed.
+   value_change_cb3: Passed.
+   value_change_cb4: Passed.
+        vpi_control: Passed.
+  ============================================================================
+  Test results: Total=77, Passed=77, Failed=0, Not Implemented=0
+
+You can uninstall everything using the following. If needed skip the ``sudo``
+as described in the install description above.::
+
+  % sudo make uninstall
+
+You can cleanup the compile directory using::
+
+  % make clean
+  or
+  % make distclean
+
+The first just cleans up just the compiled files, etc. The later cleans up
+the compiled file along with all the files generated in the ``configure``
+phase.
+
+Note that "rpm" packages of binaries for Linux are typically configured with
+"--prefix=/usr" per the Linux File System Standard.
+
+Make sure you have a recent version of flex otherwise you will get an error
 when parsing lexor.lex.
 
 Compiling on Macintosh OS X
@@ -144,3 +342,36 @@ be updated to version 3. ::
 
 Icarus Verilog is also available through the Homebrew package manager: "brew
 install icarus-verilog".
+
+Cross-Compiling for Windows
+---------------------------
+
+The `Cygwin` and `MSYS2` environments can compile Icarus Verilog as described
+above for `Linux/Unix`. There is a `MSYS2` build recipe which can be found in
+the `msys2/` directory. The accompanying README file provides further details.
+`MSYS2` is typically preferred over `Cygwin` since ``GTKWave`` and Icarus
+Verilog are both provided as pre-compiled packages.
+
+What follows are older 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. The
+configure script should have gotten all that right.

Documentation/usage/ivlpp_flags.rst

@@ -1,23 +1,6 @@
 
-   Copyright (c) 1999 Stephen Williams (steve@icarus.com)
+IVLPP - IVL Preprocessor
-
+========================
-      This source code is free software; you can redistribute it
-      and/or modify it in source code form under the terms of the GNU
-      General Public License as published by the Free Software
-      Foundation; either version 2 of the License, or (at your option)
-      any later version.
-
-      This program is distributed in the hope that it will be useful,
-      but WITHOUT ANY WARRANTY; without even the implied warranty of
-      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-      GNU General Public License for more details.
-
-      You should have received a copy of the GNU General Public License
-      along with this program; if not, write to the Free Software
-      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-
-THE IVL PREPROCESSOR
 
 The ivlpp command is a Verilog preprocessor that handles file
 inclusion and macro substitution. The program runs separate from the
@@ -33,49 +16,58 @@ The <file> parameter is the name of the file to be read and
 preprocessed. The resulting output is sent to standard output. The
 valid options include:
 
-	-Dname[=value]
+* -Dname[=value]
-	    Predefine the symbol ``name'' to have the specified
+
-	    value. If the value is not specified, then ``1'' is
+	    Predefine the symbol `name` to have the specified
+	    value. If the value is not specified, then `1` is
 	    used. This is mostly of use for controlling conditional
 	    compilation.
 
-	    This option does *not* override existing `define
+	    This option does *not* override existing \`define
 	    directives in the source file.
 
-	-F <path>
+* -F <path>
+
 	    Read ivlpp options from a FLAGS FILE. This is not the same
 	    as a file list. This file contains flags, not source
 	    files. There may be multiple flags files.
 
-	-f <path>
+* -f <path>
+
 	    Read ivlpp input files from a file list. There can be no
 	    more than one file list.
 
-	-I <dir>
+* -I <dir>
+
 	    Add a directory to the include path. Normally, only "." is
 	    in the search path. The -I flag causes other directories
 	    to be searched for a named file. There may be as many -I
 	    flags as needed.
 
-	-L
+* -L
-	    Generate `line directives. The ivl compiler understands
+
+	    Generate \`line directives. The ivl compiler understands
 	    these directives and uses them to keep track of the
 	    current line of the original source file. This makes error
 	    messages more meaningful.
 
-	-o <file>
+* -o <file>
+
 	    Send the output to the named file, instead of to standard
 	    output.
 
-	-v
+* -v
+
 	    Print version and copyright information before processing
 	    input files.
 
-	-V
+* -V
+
 	    Print version and copyright information, then exit WITHOUT
 	    processing any input files.
 
-FLAGS FILE
+Flags File
+----------
 
 A flags file contains flags for use by ivlpp. This is a convenient way
 for programs to pass complex sets of flags to the ivlpp program.
@@ -84,44 +76,50 @@ Blank lines and lines that start with "#" are ignored. The latter can
 be used as comment lines. All other lines are flag lines. Leading and
 trailing white space are removed before the lines are interpreted.
 
-Other lines have the simple format:
+Other lines have the simple format::
 
   <key>:<value>
 
 The colon character separates a key from the value. The supported
 keys, with their corresponding values, are:
 
-   D:name=<value>
+* D:name=<value>
+
       This is exactly the same as the "-Dname=<value>" described above.
 
-   I:<dir>
+* I:<dir>
+
       This is exactly the same as "-I<dir>".
 
-   relative include:<flag>
+* relative include:<flag>
+
       The <flag> can be "true" or "false". This enables "relative
       includes" nesting behavior.
 
-   vhdlpp:<path>
+* vhdlpp:<path>
+
       Give the path to the vhdlpp program. This program is used to
       process VHDL input files.
 
-LOCATING INCLUDED FILES
+Locating Included Files
+-----------------------
 
-The ivlpp preprocessor implements the `include directives by
+The ivlpp preprocessor implements the \`include directives by
 substituting the contents of the included file in place of the line
-with the `include directive. The name that the programmer specifies is
+with the \`include directive. The name that the programmer specifies is
 a file name. Normally, the preprocessor looks in the current working
-directory for the named file. However, the ``-I'' flags can be used to
+directory for the named file. However, the `-I` flags can be used to
 specify a path of directories to search for named include files. The
 current directory will be searched first, followed by all the include
 directories in the order that the -I flag appears.
 
 The exception to this process is include files that have a name that
-starts with the '/' character. These file names are ``rooted names''
+starts with the '/' character. These file names are `rooted names`
 and must be in the rooted location specified.
 
 
-GENERATED LINE DIRECTIVES
+Generated Line Directives
+-------------------------
 
 Compilers generally try to print along with their error messages the
 file and line number where the error occurred. Icarus Verilog is no
@@ -130,19 +128,19 @@ and opening files, then the line numbers counted by the compiler
 proper will not reflect the actual line numbers in the source file.
 
 To handle this situation, the preprocessor can generate line
-directives. These directives are lines of the form:
+directives. These directives are lines of the form::
 
 	`line <num> <name> <level>
 
 where <name> is the file name in double-quotes and <num> is the line
 number in the file. The parser changes the filename and line number
 counters in such a way that the next line is line number <num> in
-the file named <name>. For example:
+the file named <name>. For example::
 
 	`line 6 "foo.vl" 0
 	// I am on line 6 in file foo.vl.
 
-The preprocessor generates a `line directive every time it switches
+The preprocessor generates a \`line directive every time it switches
-files. That includes starting an included file (`line 1 "foo.vlh" 1) or
+files. That includes starting an included file (\`line 1 "foo.vlh" 1) or
 returning to the including file.
 

Documentation/usage/reporting_issues.rst

@@ -2,25 +2,43 @@
 Reporting Issues
 ================
 
-The developers of and contributers to Icarus Verilog use github to track
+The developers of and contributors to Icarus Verilog use github to track
 issues and to create patches for the product. If you believe you have found a
 problem, use the Issues tracker at the
-`Icarus Verilog github page <https://github.com/steveicarus/iverilog>`_.
+`Icarus Verilog github page <https://github.com/steveicarus/iverilog>`__.
+
+You may browse the bugs database for existing
+bugs that may be related to yours. You might find that your bug has
+already been fixed in a later release or snapshot. If that's the case,
+then you are set.
 
 On the main page, you will find a row of selections near the top. Click the
-`Issues <https://github.com/steveicarus/iverilog/issues>`_ link to get to the
+`Issues <https://github.com/steveicarus/iverilog/issues>`__ link to get to the
 list of issues, open and closed. You will find a friendly green button where
 you can create a new issue. You will be asked to create a title for your
 issue, and to write a detailed description of your issue. Please include
 enough information that anyone who sees your issue can understand and
 reproduce it.
 
+Good Issue Reporting
+--------------------
+
+Before an error can be fixed, one needs to understand what the problem
+is. Try to explain what is wrong and why you think it is wrong. Please
+try to include sample code that demonstrates the problem.
+
 One key characteristic of a well reported issue is a small sample program that
 demonstrates the issue. The smaller the better. No developer wants to wade
 through hundreds of lines of working Verilog to find the few lines that cause
 trouble, so if you can get it down to a 10 line sample program, then your
 issue will be far more likely to be addressed.
 
+Also, include the command line you use to invoke the compiler. For
+example::
+
+	iverilog -o foo.out -tvvp foo.v
+	iverilog foo.vl -s starthere
+
 Be prepared to have a conversation about your issue. More often then you would
 expect, the issue turns out to be a bug in your program, and the person
 looking into your issue may point out a bug in your code. You learn something,
@@ -35,3 +53,24 @@ the regression test suite to see how they are structured. If you have a
 complete test that can go into the test suite, then that saves everyone a lot
 of grief, and again you increase the odds that your issue will be addressed.
 
+How To Create A Pull Request
+----------------------------
+
+Bug reports with patches/PRs are very welcome. Please also add a new test case in the regression test suite to prevent the bug from reappearing.
+
+If you are editing the source, you should be using the latest
+version from git. Please see the developer documentation for more
+detailed instructions -- :doc:`Getting Started as a Contributor <getting_started>` .
+
+COPYRIGHT ISSUES
+
+Icarus Verilog is Copyright (c) 1998-2024 Stephen Williams except
+where otherwise noted. Minor patches are covered as derivative works
+(or editorial comment or whatever the appropriate legal term is) and
+folded into the rest of ivl. However, if a submission can reasonably
+be considered independently copyrightable, it's yours and I encourage
+you to claim it with appropriate copyright notices. This submission
+then falls under the "otherwise noted" category.
+
+I must insist that any copyright material submitted for inclusion
+include the GPL license notice as shown in the rest of the source.

Documentation/usage/simulation.rst

@@ -295,8 +295,8 @@ Consider this running example of a square root calculator
           bitl = 15;
        end
     endtask
-  
+
-    initial clear;   
+    initial clear;
 
     always @(reset or posedge clk)
        if (reset)
@@ -373,7 +373,7 @@ be modified as follows
   module main;
 
     reg clk, reset;
-    reg  [31:0] x; 
+    reg  [31:0] x;
     reg  [31:0] z;
     wire [15:0] y1,y2;
     wire        rdy1,rdy2;

Documentation/usage/verilog_attributes.rst

@@ -13,7 +13,7 @@ Optimizations
 -------------
 
 * ivl_do_not_elide (snapshot 20140619 or later)
-  
+
   This applies to signals (i.e. reg, wire, etc.) and tells the optimizer to
   not elide the signal, even if it is not referenced anywhere in the
   design. This is useful if the signal is for some reason only accessed by
@@ -23,13 +23,13 @@ Synthesis
 ---------
 
 * ivl_synthesis_cell
-  
+
   Applied to a module definition, this tells the synthesizer that the module
   is a cell. The synthesizer does not descend into synthesis cells, as they
   are assumed to be primitives in the target technology.
 
 * ivl_synthesis_off
-  
+
   Attached to an "always" statement, this tells the synthesizer that the
   statement is not to be synthesized. This may be useful, for example, to tell
   the compiler that a stretch of code is test-bench code.

Documentation/usage/vhdlpp_flags.rst

@@ -1,34 +1,41 @@
 
-vhdlpp COMMAND LINE FLAGS:
+vhdlpp Command Line Flags
+=========================
+
+* -D <token>
 
--D <token>
   Debug flags. The token can be:
 
   * yydebug | no-yydebug
 
   * entities=<path>
 
--L <path>
+* -L <path>
+
   Library path. Add the directory name to the front of the library
   search path. The library search path is initially empty.
 
--V
+* -V
+
   Display version on stdout
 
--v
+* -v
+
   Verbose: Display version on stderr, and enable verbose messages to
   stderr.
 
--w <path>
+* -w <path>
+
   Work path. This is the directory where the working directory is.
 
 
-LIBRARY FORMAT:
+Library Format
+--------------
 
 The vhdlpp program stores libraries as directory that contain
 packages. The name of the directory (in lower case) is the name of the
 library as used on the "import" statement. Within that library, there
-are packages in files named <foo>.pkg. For example:
+are packages in files named <foo>.pkg. For example::
 
     <directory>/...
        sample/...
@@ -39,14 +46,14 @@ are packages in files named <foo>.pkg. For example:
 
 Use the "+vhdl-libdir+<directory>" record in a config file to tell
 Icarus Verilog that <directory> is a place to look for libraries. Then
-in your VHDL code, access packages like this:
+in your VHDL code, access packages like this::
 
     library sample;
     library bar;
     use sample.test1.all;
     use bar.test3.all;
 
-The *.pkg files are just VHDL code containing only the package with
+The \*.pkg files are just VHDL code containing only the package with
 the same name. When Icarus Verilog encounters the "use <lib>.<name>.*;"
 statement, it looks for the <name>.pkg file in the <lib> library and
 parses that file to get the package header declared therein.

Documentation/usage/vpi.rst

@@ -42,7 +42,7 @@ module, is a null terminated table of function pointers. The simulator calls
 each of the functions in the table in order. The following simple C definition
 defines a sample table::
 
-  void (*vlog_startup_routines[])() = {
+  void (*vlog_startup_routines[])(void) = {
      hello_register,
      0
   };
@@ -89,16 +89,18 @@ file hello.c::
 
   static int hello_compiletf(char*user_data)
   {
+        (void)user_data; // Avoid a warning since user_data is not used.
         return 0;
   }
 
   static int hello_calltf(char*user_data)
   {
+        (void)user_data; // Avoid a warning since user_data is not used.
         vpi_printf("Hello, World!\n");
         return 0;
   }
 
-  void hello_register()
+  void hello_register(void)
   {
         s_vpi_systf_data tf_data;
 
@@ -111,7 +113,7 @@ file hello.c::
         vpi_register_systf(&tf_data);
   }
 
-  void (*vlog_startup_routines[])() = {
+  void (*vlog_startup_routines[])(void) = {
       hello_register,
       0
   };

Documentation/usage/vvp_debug.rst

@@ -1,4 +1,4 @@
-Vvp Interactive Mode
+VVP Interactive Mode
 ====================
 
 The vvp command has an interactive debug mode, where you can stop the
@@ -78,7 +78,7 @@ terminal interrupt and drops you into the interactive prompt::
   ^C** VVP Stop(0) **
   ** Flushing output streams.
   ** Current simulation time is 533928600 ticks.
-  > 
+  >
 
 This could be useful if you suspect that your simulation is stuck in
 an infinite loop and you want to rummage around and see what's going on.

Documentation/usage/vvp_flags.rst

@@ -14,6 +14,10 @@ These options/flags go before the path to the vvp-executable program. They
 effect behavior of the vvp runtime engine, including preparation for
 simulation.
 
+* -i
+
+  This flag causes all output to <stdout> to be unbuffered.
+
 * -l<logfile>
 
   This flag specifies a logfile where all MCI <stdlog> output goes. Specify
@@ -41,6 +45,25 @@ simulation.
   determine the return types of user-defined system functions. If specified at
   compile-time, there is no need to specify them again here.
 
+* -n
+
+  This flag makes $stop or a <Control\-C> a synonym for $finish. It can be
+  used to give the program a more meaningful interface when running in a
+  non-interactive environment.
+
+* -N
+
+  This flag does the same thing as "-n", but results in an exit code of 1
+  if the stimulation calls $stop.  It can be used to indicate a simulation
+  failure when running a testbench.
+
+* -q
+
+  Enable quiet mode. This suppresses all output to <stdout> sent via MCD
+  bit 0 (e.g. all output from $display and friends). It does not affect
+  output to the log file, nor does it affect output to <stdout> sent via
+  the STDOUT file descriptor.
+
 * -s
 
   $stop right away, in the beginning of the simulation. This kicks the
@@ -51,6 +74,10 @@ simulation.
   Show verbose progress while setting up or cleaning up the runtime
   engine. This also displays some performance information.
 
+* -V
+
+  Print the version of the runtime, and exit.
+
 Extended Arguments
 ------------------
 
@@ -59,6 +86,9 @@ system tasks, system functions and any VPI/PLI code. Extended arguments that
 start with a "+" character are left for use by the user via the $plus$flag and
 $plus$value functions.
 
+NOTE: The extended arguments must appear *after* the input file name on the
+command line.
+
 VCD/FST/LXT Arguments
 ^^^^^^^^^^^^^^^^^^^^^
 
@@ -73,15 +103,22 @@ behavior.
   synonyms for turning of dumping.
 
 * -fst
-  
+
   Generate FST format outputs instead of VCD format waveform dumps. This is
-  the preferred output format if using GTKWave for viewing waveforms.
+  the preferred output format if using GTKWave or Surfer for viewing waveforms.
 
 * -lxt/-lxt2
-  
+
   Generate LXT or LXT2format instead of VCD format waveform dumps. The LXT2
   format is more advanced.
 
+* -dumpfile=<name>
+
+  Set the default dumpfile. If unspecified, the default is "dump". This
+  command line flag allows you do change it. If no suffix is specified,
+  then the suffix will be chosen based on the dump type. In any case, the
+  $dumpfile system task overrides this flag.
+
 SDF Support
 ^^^^^^^^^^^
 
@@ -89,15 +126,15 @@ The Icarus Verilog support for SDF back-annotation can take some extended
 arguments to control aspects of SDF support.
 
 * -sdf-warn
-  
+
   Print warnings during load of/annotation from an SDF file.
 
 * -sdf-info
-  
+
   Print interesting information about an SDF file while parsing it.
 
 * -sdf-verbose
-  
+
   Print warnings and info messages.
 
 Environment Variables
@@ -106,4 +143,3 @@ Environment Variables
 The vvp program pays attention to certain environment variables.
 
 * IVERILOG_DUMPER
-

Documentation/usage/vvp_library.rst

@@ -0,0 +1,29 @@
+VVP as a library
+================
+
+If configured with ::
+
+  --enable-libvvp
+
+the vvp program will be built as a small stub that
+depends on a shared library, libvvp.so.
+The library may also be used to include a vvp simulation
+in a larger program.  Typically, the simulation communicates
+with its host program using VPI, but since
+almost all the functions of vvp are included in the library
+it may be possible to use text output and interactive mode.
+
+The accessible functions of the library are defined and documented
+in the header file, vvp/libvvp.h. Although vvp is a C++ program, the
+header file presents a C interface.
+
+Note that the vvp software was not designed to be used this way
+and the library is a straightforward recompilation of the program code.
+That imposes some restrictions, mostly arising from the use
+of static variables: only a single run of a single simulation instance
+can be expected to work without special actions.
+To mitigate these restrictions, the library may by loaded dynamically
+and unloaded at the end of each simulation run.
+Parallel simulation should be possible by making multiple copies
+of the library with different names.
+

Documentation/usage/waveform_viewer.rst

@@ -1,22 +1,32 @@
+Viewing Waveforms
+=================
 
-Waveforms With GTKWave
+To view waveforms, either GTKWave or Surfer can be used.
-======================
 
-GTKWave is a VCD waveform viewer based on the GTK library. This viewer support
+GTKWave is a waveform viewer based on the GTK library. This viewer supports
-VCD and LXT formats for signal dumps. GTKWAVE is available on github
+VCD, FST, LXT, and LXT2 formats for waveform dumps. GTKWave is available on GitHub
-`here <https://github.com/gtkwave/gtkwave>`_. Most Linux distributions already
+`here <https://github.com/gtkwave/gtkwave>`__. Most Linux distributions already
-include gtkwave prepackaged.
+include gtkwave prepackaged and there are binaries for Windows available.
 
 .. image:: GTKWave_Example2.png
 
-Generating VCD/FST files for GTKWAVE ------------------------------------
+Surfer is a waveform viewer based on the Rust egui library. This viewer supports
+VCD and FST formats for waveform dumps. Surfer is available on GitLab
+`here <https://gitlab.com/surfer-project/surfer>`__. It runs on Windows, Linux,
+and MacOS, but can also run in a `web browser <https://app.surfer-project.org/>`__
+and there is a VS Code
+`extension <https://marketplace.visualstudio.com/items?itemName=surfer-project.surfer>`__.
+
+Generating waveform dump files for viewing
+------------------------------------------
+
 Waveform dumps are written by the Icarus Verilog runtime program vvp. The user
 uses $dumpfile and $dumpvars system tasks to enable waveform dumping, then the
 vvp runtime takes care of the rest. The output is written into the file
 specified by the $dumpfile system task. If the $dumpfile call is absent, the
-compiler will choose the file name dump.vcd or dump.lxt or dump.fst, depending
+compiler will choose the file name dump.vcd, dump.lxt, dump.lxt2, or dump.fst,
-on runtime flags. The example below dumps everything in and below the test
+depending on runtime flags. The example below dumps everything in and below
-module:
+the test module:
 
 .. code-block:: verilog
 
@@ -30,9 +40,9 @@ module:
 
 By default, the vvp runtime will generate VCD dump output. This is the default
 because it is the most portable. However, when using gtkwave, the FST output
-format is faster and most compact. Use the "-fst" extended argument to
+format is faster and most compact. Use the "-fst", "-lxt", or "-lxt2" extended
-activate LXT output. For example, if your compiled output is written into the
+argument to activate FST, LXT, or LXT2 output, respectively. For example, if
-file "foo.vvp", the command:
+your compiled output is written into the file "foo.vvp", the command:
 
 .. code-block:: console
 
@@ -40,7 +50,7 @@ file "foo.vvp", the command:
 
 will cause the dumpfile output to be written in FST format. Absent any
 specific $dumpfile command, this file will be called dump.fst, which can be
-viewed with the command:
+viewed with GTKWave using the command:
 
 .. code-block:: console
 
@@ -105,7 +115,7 @@ Then the simulation file:
                 $time, value, value);
   endmodule // test
 
-Compile, run, and view waveforms with these commands:
+Compile, run, and view waveforms with GTKWave using these commands:
 
 .. code-block:: console
 
@@ -113,6 +123,6 @@ Compile, run, and view waveforms with these commands:
   % vvp dsn
   % gtkwave test.vcd &
 
-Click on the 'test', then 'c1' in the top left box on GTKWAVE, then drag the
+Click on the 'test', then 'c1' in the top left box of GTKWave, then drag the
 signals to the Signals box. You will be able to add signals to display,
 scanning by scope.

INSTALL

@@ -1,52 +1,59 @@
 Basic Installation
 ==================
 
-   These are generic installation instructions.
+   These are generic installation instructions, with minor updates
+for the `iverilog` project.
 
-   The `configure' shell script attempts to guess correct values for
+   Instructions in the `README` are more concise for this project.
+
+   The `configure` shell script attempts to guess correct values for
 various system-dependent variables used during compilation.  It uses
-those values to create a `Makefile' in each directory of the package.
+those values to create a `Makefile` in each directory of the package.
-It may also create one or more `.h' files containing system-dependent
+It may also create one or more `.h` files containing system-dependent
-definitions.  Finally, it creates a shell script `config.status' that
+definitions.  Finally, it creates a shell script `config.status` that
 you can run in the future to recreate the current configuration, a file
-`config.cache' that saves the results of its tests to speed up
+`config.cache` that saves the results of its tests to speed up
-reconfiguring, and a file `config.log' containing compiler output
+reconfiguring, and a file `config.log` containing compiler output
-(useful mainly for debugging `configure').
+(useful mainly for debugging `configure`).
 
    If you need to do unusual things to compile the package, please try
-to figure out how `configure' could check whether to do them, and mail
+to figure out how `configure` could check whether to do them, and mail
-diffs or instructions to the address given in the `README' so they can
+diffs or instructions to the address given in the `README` so they can
-be considered for the next release.  If at some point `config.cache'
+be considered for the next release.  If at some point `config.cache`
 contains results you don't want to keep, you may remove or edit it.
 
-   The file `configure.ac' is used to create `configure' by a program
+   The file `configure.ac` is used to create `configure` by a program
-called `autoconf'.  You only need `configure.ac' if you want to change
+called `autoconf`.  You only need `configure.ac` if you want to change
-it or regenerate `configure' using a newer version of `autoconf'.
+it or regenerate `configure` using a newer version of `autoconf`.
 
 The simplest way to compile this package is:
 
-  1. `cd' to the directory containing the package's source code and type
+  1. `cd` to the directory containing the package's source code.
-     `./configure' to configure the package for your system.  If you're
-     using `csh' on an old version of System V, you might need to type
-     `sh ./configure' instead to prevent `csh' from trying to execute
-     `configure' itself.
 
-     Running `configure' takes awhile.  While running, it prints some
+  2. Run `sh autoconf.sh`, if building from source (and not a release).
+     If you're building from a release, skip this step.
+
+  3. Run `./configure` to configure the package for your system.  If you're
+     using `csh` on an old version of System V, you might need to type
+     `sh ./configure` instead to prevent `csh` from trying to execute
+     `configure` itself.
+
+     Running `configure` takes awhile.  While running, it prints some
      messages telling which features it is checking for.
 
-  2. Type `make' to compile the package.
+  4. Type `make` to compile the package.
 
-  3. Optionally, type `make check' to run any self-tests that come with
+  5. Optionally, type `make check` to run any self-tests that come with
      the package.
 
-  4. Type `make install' to install the programs and any data files and
+  6. Type `make install` to install the programs and any data files and
-     documentation.
+     documentation. You may need to use `sudo`.
 
-  5. You can remove the program binaries and object files from the
+  7. You can remove the program binaries and object files from the
-     source code directory by typing `make clean'.  To also remove the
+     source code directory by typing `make clean`.  To also remove the
-     files that `configure' created (so you can compile the package for
+     files that `configure` created (so you can compile the package for
-     a different kind of computer), type `make distclean'.  There is
+     a different kind of computer), type `make distclean`.  There is
-     also a `make maintainer-clean' target, but that is intended mainly
+     also a `make maintainer-clean` target, but that is intended mainly
      for the package's developers.  If you use it, you may have to get
      all sorts of other programs in order to regenerate files that came
      with the distribution.
@@ -55,126 +62,131 @@ Compilers and Options
 =====================
 
    Some systems require unusual options for compilation or linking that
-the `configure' script does not know about.  You can give `configure'
+the `configure` script does not know about.  You can give `configure`
 initial values for variables by setting them in the environment.  Using
 a Bourne-compatible shell, you can do that on the command line like
 this:
-     CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
 
-Or on systems that have the `env' program, you can do it like this:
+```bash
+     CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
+```
+
+Or on systems that have the `env` program, you can do it like this:
+```bash
      env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
+```
 
 Compiling For Multiple Architectures
 ====================================
 
    You can compile the package for more than one kind of computer at the
 same time, by placing the object files for each architecture in their
-own directory.  To do this, you must use a version of `make' that
+own directory.  To do this, you must use a version of `make` that
-supports the `VPATH' variable, such as GNU `make'.  `cd' to the
+supports the `VPATH` variable, such as GNU `make`.  `cd` to the
 directory where you want the object files and executables to go and run
-the `configure' script.  `configure' automatically checks for the
+the `configure` script.  `configure` automatically checks for the
-source code in the directory that `configure' is in and in `..'.
+source code in the directory that `configure` is in and in `..`.
 
-   If you have to use a `make' that does not supports the `VPATH'
+   If you have to use a `make` that does not supports the `VPATH`
 variable, you have to compile the package for one architecture at a time
 in the source code directory.  After you have installed the package for
-one architecture, use `make distclean' before reconfiguring for another
+one architecture, use `make distclean` before reconfiguring for another
 architecture.
 
 Installation Names
 ==================
 
-   By default, `make install' will install the package's files in
+   By default, `make install` will install the package's files in
-`/usr/local/bin', `/usr/local/man', etc.  You can specify an
+`/usr/local/bin`, `/usr/local/man`, etc.  You can specify an
-installation prefix other than `/usr/local' by giving `configure' the
+installation prefix other than `/usr/local` by giving `configure` the
-option `--prefix=PATH'.
+option `--prefix=PATH`.
 
    You can specify separate installation prefixes for
 architecture-specific files and architecture-independent files.  If you
-give `configure' the option `--exec-prefix=PATH', the package will use
+give `configure` the option `--exec-prefix=PATH`, the package will use
 PATH as the prefix for installing programs and libraries.
 Documentation and other data files will still use the regular prefix.
 
    In addition, if you use an unusual directory layout you can give
-options like `--bindir=PATH' to specify different values for particular
+options like `--bindir=PATH` to specify different values for particular
-kinds of files.  Run `configure --help' for a list of the directories
+kinds of files.  Run `configure --help` for a list of the directories
 you can set and what kinds of files go in them.
 
    If the package supports it, you can cause programs to be installed
-with an extra prefix or suffix on their names by giving `configure' the
+with an extra prefix or suffix on their names by giving `configure` the
-option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
+option `--program-prefix=PREFIX` or `--program-suffix=SUFFIX`.
 
 Optional Features
 =================
 
-   Some packages pay attention to `--enable-FEATURE' options to
+   Some packages pay attention to `--enable-FEATURE` options to
-`configure', where FEATURE indicates an optional part of the package.
+`configure`, where FEATURE indicates an optional part of the package.
-They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+They may also pay attention to `--with-PACKAGE` options, where PACKAGE
-is something like `gnu-as' or `x' (for the X Window System).  The
+is something like `gnu-as` or `x` (for the X Window System).  The
-`README' should mention any `--enable-' and `--with-' options that the
+`README` should mention any `--enable-` and `--with-` options that the
 package recognizes.
 
-   For packages that use the X Window System, `configure' can usually
+   For packages that use the X Window System, `configure` can usually
 find the X include and library files automatically, but if it doesn't,
-you can use the `configure' options `--x-includes=DIR' and
+you can use the `configure` options `--x-includes=DIR` and
-`--x-libraries=DIR' to specify their locations.
+`--x-libraries=DIR` to specify their locations.
 
 Specifying the System Type
 ==========================
 
-   There may be some features `configure' can not figure out
+   There may be some features `configure` can not figure out
 automatically, but needs to determine by the type of host the package
-will run on.  Usually `configure' can figure that out, but if it prints
+will run on.  Usually `configure` can figure that out, but if it prints
 a message saying it can not guess the host type, give it the
-`--host=TYPE' option.  TYPE can either be a short name for the system
+`--host=TYPE` option.  TYPE can either be a short name for the system
-type, such as `sun4', or a canonical name with three fields:
+type, such as `sun4`, or a canonical name with three fields:
-     CPU-COMPANY-SYSTEM
+     `CPU-COMPANY-SYSTEM`
 
-See the file `config.sub' for the possible values of each field.  If
+See the file `config.sub` for the possible values of each field.  If
-`config.sub' isn't included in this package, then this package doesn't
+`config.sub` isn't included in this package, then this package doesn't
 need to know the host type.
 
    If you are building compiler tools for cross-compiling, you can also
-use the `--target=TYPE' option to select the type of system they will
+use the `--target=TYPE` option to select the type of system they will
-produce code for and the `--build=TYPE' option to select the type of
+produce code for and the `--build=TYPE` option to select the type of
 system on which you are compiling the package.
 
 Sharing Defaults
 ================
 
-   If you want to set default values for `configure' scripts to share,
+   If you want to set default values for `configure` scripts to share,
-you can create a site shell script called `config.site' that gives
+you can create a site shell script called `config.site` that gives
-default values for variables like `CC', `cache_file', and `prefix'.
+default values for variables like `CC`, `cache_file`, and `prefix`.
-`configure' looks for `PREFIX/share/config.site' if it exists, then
+`configure` looks for `PREFIX/share/config.site` if it exists, then
-`PREFIX/etc/config.site' if it exists.  Or, you can set the
+`PREFIX/etc/config.site` if it exists.  Or, you can set the
-`CONFIG_SITE' environment variable to the location of the site script.
+`CONFIG_SITE` environment variable to the location of the site script.
-A warning: not all `configure' scripts look for a site script.
+A warning: not all `configure` scripts look for a site script.
 
 Operation Controls
 ==================
 
-   `configure' recognizes the following options to control how it
+   `configure` recognizes the following options to control how it
 operates.
 
-`--cache-file=FILE'
+`--cache-file=FILE`
      Use and save the results of the tests in FILE instead of
-     `./config.cache'.  Set FILE to `/dev/null' to disable caching, for
+     `./config.cache`.  Set FILE to `/dev/null` to disable caching, for
-     debugging `configure'.
+     debugging `configure`.
 
-`--help'
+`--help`
-     Print a summary of the options to `configure', and exit.
+     Print a summary of the options to `configure`, and exit.
 
-`--quiet'
+`--quiet`
-`--silent'
+`--silent`
-`-q'
+`-q`
      Do not print messages saying which checks are being made.
 
-`--srcdir=DIR'
+`--srcdir=DIR`
      Look for the package's source code in directory DIR.  Usually
-     `configure' can determine that directory automatically.
+     `configure` can determine that directory automatically.
 
-`--version'
+`--version`
-     Print the version of Autoconf used to generate the `configure'
+     Print the version of Autoconf used to generate the `configure`
      script, and exit.
 
-`configure' also accepts some other, not widely useful, options.
+`configure` also accepts some other, not widely useful, options.

Makefile.in

@@ -36,18 +36,23 @@ prefix = @prefix@
 exec_prefix = @exec_prefix@
 srcdir = @srcdir@
 datarootdir = @datarootdir@
+VERSION_MAJOR = @VERSION_MAJOR@
+VERSION_MINOR = @VERSION_MINOR@
 
-SUBDIRS = ivlpp vhdlpp vvp vpi libveriuser cadpli tgt-null tgt-stub tgt-vvp \
+SUBDIRS = ivlpp vhdlpp vvp vpi tgt-null tgt-stub tgt-vvp \
-          tgt-vhdl tgt-vlog95 tgt-pcb tgt-blif tgt-sizer driver
+          tgt-vhdl tgt-vlog95 tgt-pcb tgt-blif tgt-sizer driver \
+          ivtest
 # Only run distclean for these directories.
 NOTUSED = tgt-fpga tgt-pal tgt-verilog
 
-ifeq (@MINGW32@,yes)
+ifeq (@LIBVERIUSER@,yes)
-SUBDIRS += driver-vpi
+SUBDIRS += libveriuser cadpli
 else
-NOTUSED += driver-vpi
+NOTUSED += libveriuser cadpli
 endif
 
+SUBDIRS += driver-vpi
+
 # To get the version headers to build correctly we only want to look
 # for C++ files in the source directory. All other files will require
 # an explicit $(srcdir). The one exception to this is if we need to
@@ -61,8 +66,7 @@ bindir = @bindir@
 libdir = @libdir@
 # This is actually the directory where we install our own header files.
 # It is a little different from the generic includedir.
-includedir = @includedir@/iverilog$(suffix)
+ivl_includedir = @includedir@/iverilog$(suffix)
-mandir = @mandir@
 
 dllib=@DLLIB@
 
@@ -72,16 +76,19 @@ HOSTCFLAGS = @WARNING_FLAGS@ @WARNING_FLAGS_CC@ @CFLAGS@
 
 BUILDCC = @CC_FOR_BUILD@
 BUILDEXT = @BUILD_EXEEXT@
+CC = @CC@
 CXX = @CXX@
-DLLTOOL = @DLLTOOL@
+ENV_VVP=@ENV_VVP@
 INSTALL = @INSTALL@
 INSTALL_SCRIPT = @INSTALL_SCRIPT@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
 INSTALL_DATA = @INSTALL_DATA@
 LEX = @LEX@
 YACC = @YACC@
+YACC_CONFLICT_FLAGS = -Werror=conflicts-sr -Werror=conflicts-rr
 MAN = @MAN@
 PS2PDF = @PS2PDF@
+GROFF = @GROFF@
 GIT = @GIT@
 
 ifeq (@srcdir@,.)
@@ -114,15 +121,16 @@ O = main.o async.o design_dump.o discipline.o dup_expr.o elaborate.o \
     net_event.o net_expr.o net_func.o \
     net_func_eval.o net_link.o net_modulo.o \
     net_nex_input.o net_nex_output.o net_proc.o net_scope.o net_tran.o \
-    net_udp.o pad_to_width.o parse.o parse_misc.o pform.o pform_analog.o \
+    net_udp.o map_named_args.o \
+    pad_to_width.o parse.o parse_misc.o pform.o pform_analog.o \
     pform_disciplines.o pform_dump.o pform_package.o pform_pclass.o \
     pform_types.o \
     symbol_search.o sync.o sys_funcs.o verinum.o verireal.o vpi_modules.o target.o \
     Attrib.o HName.o Module.o PClass.o PDelays.o PEvent.o PExpr.o PFunction.o \
-    PGate.o PGenerate.o PModport.o PNamedItem.o PPackage.o PScope.o PSpec.o \
+    PGate.o PGenerate.o PModport.o PNamedItem.o PPackage.o PScope.o PSpec.o PTimingCheck.o \
     PTask.o PUdp.o PWire.o Statement.o AStatement.o $M $(FF) $(TT)
 
-all: dep config.h _pli_types.h version_tag.h ivl@EXEEXT@ version.exe iverilog-vpi.man
+all: dep config.h _pli_types.h version_tag.h version_base.h ivl@EXEEXT@
 	$(foreach dir,$(SUBDIRS),$(MAKE) -C $(dir) $@ && ) true
 
 # In the windows world, the installer will need a dosify program to
@@ -130,37 +138,29 @@ all: dep config.h _pli_types.h version_tag.h ivl@EXEEXT@ version.exe iverilog-vp
 ifeq (@MINGW32@,yes)
 all: dosify$(BUILDEXT)
 dosify$(BUILDEXT): $(srcdir)/dosify.c
-	$(BUILDCC) $(CFLAGS) -o dosify$(BUILDEXT) $(srcdir)/dosify.c
+	$(BUILDCC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o dosify$(BUILDEXT) $(srcdir)/dosify.c
 endif
 
-# This rule rules the compiler in the trivial hello.vl program to make
+# This rule runs the compiler using the trivial hello.vl program to make sure
-# sure the basics were compiled properly.
+# the base programs are compiled properly.
 check: all
 	$(foreach dir,$(SUBDIRS),$(MAKE) -C $(dir) $@ && ) true
+	rm -f check.vvp
 	test -r check.conf || cp $(srcdir)/check.conf .
-	driver/iverilog -B. -BMvpi -BPivlpp -tcheck -ocheck.vvp $(srcdir)/examples/hello.vl
+	driver/iverilog@EXEEXT@ -B. -BMvpi -BPivlpp -tcheck -ocheck.vvp $(srcdir)/examples/hello.vl && \
-ifeq (@WIN32@,yes)
+	$(ENV_VVP) vvp/vvp$(suffix)@EXEEXT@ -M- -M./vpi ./check.vvp | grep 'Hello, World'
-ifeq (@install_suffix@,)
+
-	vvp/vvp -M- -M./vpi ./check.vvp | grep 'Hello, World'
+check-installed check-installed-vpi check-installed-vvp check-installed-vvp-py:
-else
+	$(MAKE) -C ivtest $@
-	# On Windows if we have a suffix we must run the vvp part of
-	# the test with a suffix since it was built/linked that way.
-	ln vvp/vvp.exe vvp/vvp$(suffix).exe
-	vvp/vvp$(suffix) -M- -M./vpi ./check.vvp | grep 'Hello, World'
-	rm vvp/vvp$(suffix).exe
-endif
-else
-	vvp/vvp -M- -M./vpi ./check.vvp | grep 'Hello, World'
-endif
 
 clean:
 	$(foreach dir,$(SUBDIRS),$(MAKE) -C $(dir) $@ && ) true
 	rm -f *.o parse.cc parse.h lexor.cc
-	rm -f ivl.exp iverilog-vpi.man iverilog-vpi.pdf iverilog-vpi.ps
+	rm -f ivl.exp
+	rm -f iverilog_man.ps iverilog_man.pdf iverilog_man_$(VERSION_MAJOR)_$(VERSION_MINOR).pdf
 	rm -f parse.output syn-rules.output dosify$(BUILDEXT) ivl@EXEEXT@ check.vvp
-	rm -f lexor_keyword.cc libivl.a libvpi.a iverilog-vpi syn-rules.cc
+	rm -f lexor_keyword.cc libivl.a libvpi.a syn-rules.cc
 	rm -rf dep
-	rm -f version.exe
 
 distclean: clean
 	$(foreach dir,$(SUBDIRS),$(MAKE) -C $(dir) $@ && ) true
@@ -168,14 +168,17 @@ distclean: clean
 	rm -f Makefile config.status config.log config.cache
 	rm -f stamp-config-h config.h
 	rm -f stamp-_pli_types-h _pli_types.h
+	rm -f stamp-version_base-h version_base.h
 ifneq (@srcdir@,.)
 	rm -f version_tag.h check.conf
 	rmdir $(SUBDIRS) $(NOTUSED)
 endif
 	rm -rf autom4te.cache
 
-cppcheck: $(O:.o=.cc) $(srcdir)/dosify.c $(srcdir)/version.c
+cppcheck: $(O:.o=.cc) $(srcdir)/dosify.c
-	cppcheck --enable=all --std=c99 --std=c++03 -f \
+	cppcheck --enable=all --std=c99 --std=c++11 -f \
+	         --check-level=exhaustive \
+	         --suppressions-list=$(srcdir)/cppcheck-global.sup \
 	         --suppressions-list=$(srcdir)/cppcheck.sup \
 	         -UYYPARSE_PARAM -UYYPRINT -Ushort -Usize_t -Uyyoverflow \
 	         -UYYTYPE_INT8 -UYYTYPE_INT16 -UYYTYPE_UINT8 -UYYTYPE_UINT16 \
@@ -203,6 +206,11 @@ stamp-_pli_types-h: $(srcdir)/_pli_types.h.in config.status
 	./config.status _pli_types.h
 _pli_types.h: stamp-_pli_types-h
 
+stamp-version_base-h: $(srcdir)/version_base.h.in config.status
+	@rm -f $@
+	./config.status version_base.h
+version_base.h: stamp-version_base-h
+
 $(srcdir)/configure: $(srcdir)/configure.ac $(srcdir)/aclocal.m4
 	cd $(srcdir) && autoconf
 
@@ -211,40 +219,17 @@ config.status: $(srcdir)/configure
 	./config.status
 
 ifeq (@WIN32@,yes)
-# Under Windows (mingw) I need to make the ivl.exe in two steps.
+# Under Windows we need to create an import library to allow the target code
-# The first step makes an ivl.exe that dlltool can use to make an
+# generators to access the items exported by ivl.exe. The .def file controls
-# export and import library, and the last link makes a, ivl.exe
+# what is visible in the import library.
-# that really exports the things that the import library imports.
 ivl@EXEEXT@: $O $(srcdir)/ivl.def
-	$(CXX) -o ivl@EXEEXT@ $O $(dllib) @EXTRALIBS@
+	$(CXX) $(LDFLAGS) -o ivl@EXEEXT@ -Wl,--out-implib=libivl.a $(srcdir)/ivl.def $O $(dllib) @EXTRALIBS@
-	$(DLLTOOL) --dllname ivl@EXEEXT@ --def $(srcdir)/ivl.def \
-		--output-lib libivl.a --output-exp ivl.exp
-	$(CXX) $(LDFLAGS) -o ivl@EXEEXT@ ivl.exp $O $(dllib) @EXTRALIBS@
 else
 ivl@EXEEXT@: $O
 	$(CXX) $(LDFLAGS) -o ivl@EXEEXT@ $O $(dllib)
 endif
 
-ifeq (@MINGW32@,no)
+%.o: %.cc config.h | dep
-all: iverilog-vpi
-
-iverilog-vpi: $(srcdir)/iverilog-vpi.sh Makefile
-	sed -e 's;@SHARED@;@shared@;' -e 's;@PIC@;@PICFLAG@;' \
-	    -e 's;@SUFFIX@;$(suffix);' \
-	    -e 's;@IVCC@;$(CC);' \
-	    -e 's;@IVCXX@;$(CXX);' \
-	    -e 's;@IVCFLAGS@;$(CFLAGS);' \
-	    -e 's;@IVCXXFLAGS@;$(CXXFLAGS);' \
-	    -e 's;@IVCTARGETFLAGS@;$(CTARGETFLAGS);' \
-	    -e 's;@INCLUDEDIR@;$(includedir);' \
-	    -e 's;@LIBDIR@;@libdir@;' $< > $@
-	chmod +x $@
-endif
-
-version.exe: $(srcdir)/version.c $(srcdir)/version_base.h version_tag.h
-	$(BUILDCC) $(CFLAGS) -o version.exe -I. -I$(srcdir) $(srcdir)/version.c
-
-%.o: %.cc config.h
 	$(CXX) $(CPPFLAGS) $(CXXFLAGS) @DEPENDENCY_FLAG@ -c $< -o $*.o
 	mv $*.d dep/$*.d
 
@@ -257,10 +242,10 @@ parse.o: parse.cc
 
 # Use pattern rules to avoid parallel build issues (see pr3462585)
 parse%cc parse%h: $(srcdir)/parse%y
-	$(YACC) --verbose -t -p VL --defines=parse.h -o parse.cc $<
+	$(YACC) --verbose $(YACC_CONFLICT_FLAGS) -t -p VL --defines=parse.h -o parse.cc $<
 
 syn-rules.cc: $(srcdir)/syn-rules.y
-	$(YACC) --verbose -t -p syn_ -o $@ $<
+	$(YACC) --verbose $(YACC_CONFLICT_FLAGS) -t -p syn_ -o $@ $<
 
 lexor.cc: $(srcdir)/lexor.lex
 	$(LEX) -s -t $< > $@
@@ -268,20 +253,17 @@ lexor.cc: $(srcdir)/lexor.lex
 lexor_keyword.o: lexor_keyword.cc parse.h
 
 lexor_keyword.cc: $(srcdir)/lexor_keyword.gperf
-	gperf -o -i 7 -C -k 1-4,6,9,$$ -H keyword_hash -N check_identifier -t $(srcdir)/lexor_keyword.gperf > lexor_keyword.cc || (rm -f lexor_keyword.cc ; false)
+	gperf -o -i 7 -C -k 1-4,6,9,$$ -H keyword_hash -N check_identifier -t $< > $@ || (rm -f $@ ; false)
 
-iverilog-vpi.man: $(srcdir)/iverilog-vpi.man.in version.exe
+iverilog_man.ps: driver/iverilog.man vvp/vvp.man driver-vpi/iverilog-vpi.man
-	./version.exe `head -1 $(srcdir)/iverilog-vpi.man.in`'\n' > $@
+	$(GROFF) -man -rC1 -rD1 -T ps $^ > $@
-	tail -n +2 $(srcdir)/iverilog-vpi.man.in >> $@
 
-iverilog-vpi.ps: iverilog-vpi.man
+iverilog_man.pdf: iverilog_man.ps
-	$(MAN) -t ./iverilog-vpi.man > iverilog-vpi.ps
+	$(PS2PDF) $< $@
-
+	cp $@ iverilog_man_$(VERSION_MAJOR)_$(VERSION_MINOR).pdf
-iverilog-vpi.pdf: iverilog-vpi.ps
-	$(PS2PDF) iverilog-vpi.ps iverilog-vpi.pdf
 
 # For VERSION_TAG in driver/main.c, first try git-describe, then look for a
-# version_tag.h file in the source tree (included in snapshots and releases),
+# release_tag.h file in the source tree (included in snapshots and releases),
 # and finally use nothing.
 
 # "true" and "false" in the next few lines are Unix shell command names
@@ -296,37 +278,14 @@ version_tag.h version:
 	    tmp=`(cd $(srcdir) && $(GIT) describe --always --dirty) \
 		   | sed -e 's;\(.*\);#define VERSION_TAG "\1";'`; \
 	    echo "$$tmp" | diff - version_tag.h > /dev/null 2>&1 || echo "$$tmp" > version_tag.h || exit 1; \
-	elif test -r $(srcdir)/version_tag.h; then \
+	elif test -r $(srcdir)/release_tag.h; then \
-	    echo "Using $(srcdir)/version_tag.h for VERSION_TAG"; \
+	    echo "Using $(srcdir)/release_tag.h for VERSION_TAG"; \
-	    diff $(srcdir)/version_tag.h version_tag.h > /dev/null 2>&1 || cp $(srcdir)/version_tag.h version_tag.h; \
+	    diff $(srcdir)/release_tag.h version_tag.h > /dev/null 2>&1 || cp $(srcdir)/release_tag.h version_tag.h; \
 	else \
 	    echo "Using empty VERSION_TAG"; \
 	    echo '#define VERSION_TAG ""' > version_tag.h; \
 	fi
 
-ifeq (@MINGW32@,yes)
-ifeq ($(MAN),none)
-INSTALL_DOC = installman
-else
-ifeq ($(PS2PDF),none)
-INSTALL_DOC = installman
-else
-INSTALL_DOC = installpdf installman
-all: dep iverilog-vpi.pdf
-endif
-endif
-INSTALL_DOCDIR = $(mandir)/man1
-else
-INSTALL_DOC = installman
-INSTALL_DOCDIR = $(mandir)/man1
-endif
-
-ifeq (@MINGW32@,yes)
-WIN32_INSTALL =
-else
-WIN32_INSTALL = installwin32
-endif
-
 install: all installdirs installfiles
 	$(foreach dir,$(SUBDIRS),$(MAKE) -C $(dir) $@ && ) true
 
@@ -338,37 +297,24 @@ F = ./ivl@EXEEXT@ \
 	$(srcdir)/sv_vpi_user.h \
 	$(srcdir)/vpi_user.h \
 	$(srcdir)/acc_user.h \
-	$(srcdir)/veriuser.h \
+	$(srcdir)/veriuser.h
-	$(INSTALL_DOC) \
-	$(WIN32_INSTALL)
-
-installwin32: ./iverilog-vpi installdirs
-	$(INSTALL_SCRIPT) ./iverilog-vpi "$(DESTDIR)$(bindir)/iverilog-vpi$(suffix)"
-
-installman: iverilog-vpi.man installdirs
-	$(INSTALL_DATA) iverilog-vpi.man "$(DESTDIR)$(mandir)/man1/iverilog-vpi$(suffix).1"
-
-installpdf: iverilog-vpi.pdf installdirs
-	$(INSTALL_DATA) iverilog-vpi.pdf "$(DESTDIR)$(prefix)/iverilog-vpi$(suffix).pdf"
 
 installfiles: $(F) | installdirs
 	$(INSTALL_PROGRAM) ./ivl@EXEEXT@ "$(DESTDIR)$(libdir)/ivl$(suffix)/ivl@EXEEXT@"
 	$(INSTALL_DATA) $(srcdir)/constants.vams "$(DESTDIR)$(libdir)/ivl$(suffix)/include/constants.vams"
 	$(INSTALL_DATA) $(srcdir)/disciplines.vams "$(DESTDIR)$(libdir)/ivl$(suffix)/include/disciplines.vams"
-	$(INSTALL_DATA) $(srcdir)/ivl_target.h "$(DESTDIR)$(includedir)/ivl_target.h"
+	$(INSTALL_DATA) $(srcdir)/ivl_target.h "$(DESTDIR)$(ivl_includedir)/ivl_target.h"
-	$(INSTALL_DATA) ./_pli_types.h "$(DESTDIR)$(includedir)/_pli_types.h"
+	$(INSTALL_DATA) ./_pli_types.h "$(DESTDIR)$(ivl_includedir)/_pli_types.h"
-	$(INSTALL_DATA) $(srcdir)/sv_vpi_user.h "$(DESTDIR)$(includedir)/sv_vpi_user.h"
+	$(INSTALL_DATA) $(srcdir)/sv_vpi_user.h "$(DESTDIR)$(ivl_includedir)/sv_vpi_user.h"
-	$(INSTALL_DATA) $(srcdir)/vpi_user.h "$(DESTDIR)$(includedir)/vpi_user.h"
+	$(INSTALL_DATA) $(srcdir)/vpi_user.h "$(DESTDIR)$(ivl_includedir)/vpi_user.h"
-	$(INSTALL_DATA) $(srcdir)/acc_user.h "$(DESTDIR)$(includedir)/acc_user.h"
+	$(INSTALL_DATA) $(srcdir)/acc_user.h "$(DESTDIR)$(ivl_includedir)/acc_user.h"
-	$(INSTALL_DATA) $(srcdir)/veriuser.h "$(DESTDIR)$(includedir)/veriuser.h"
+	$(INSTALL_DATA) $(srcdir)/veriuser.h "$(DESTDIR)$(ivl_includedir)/veriuser.h"
 
 installdirs: $(srcdir)/mkinstalldirs
 	$(srcdir)/mkinstalldirs "$(DESTDIR)$(bindir)" \
-	    "$(DESTDIR)$(includedir)" \
+	    "$(DESTDIR)$(ivl_includedir)" \
 	    "$(DESTDIR)$(libdir)/ivl$(suffix)" \
-	    "$(DESTDIR)$(libdir)/ivl$(suffix)/include" \
+	    "$(DESTDIR)$(libdir)/ivl$(suffix)/include"
-	    "$(DESTDIR)$(mandir)" \
-	    "$(DESTDIR)$(mandir)/man1"
 
 uninstall:
 	$(foreach dir,$(SUBDIRS),$(MAKE) -C $(dir) $@ && ) true
@@ -376,12 +322,13 @@ uninstall:
 	    do rm -f "$(DESTDIR)$(libdir)/ivl$(suffix)/$$f"; done
 	-rmdir "$(DESTDIR)$(libdir)/ivl$(suffix)/include"
 	-rmdir "$(DESTDIR)$(libdir)/ivl$(suffix)"
-	for f in verilog$(suffix) iverilog-vpi$(suffix) gverilog$(suffix)@EXEEXT@; \
+	for f in verilog$(suffix) gverilog$(suffix)@EXEEXT@; \
 	    do rm -f "$(DESTDIR)$(bindir)/$$f"; done
 	for f in ivl_target.h vpi_user.h _pli_types.h sv_vpi_user.h acc_user.h veriuser.h; \
-	    do rm -f "$(DESTDIR)$(includedir)/$$f"; done
+	    do rm -f "$(DESTDIR)$(ivl_includedir)/$$f"; done
-	-test X$(suffix) = X || rmdir "$(DESTDIR)$(includedir)"
+	-test X$(suffix) = X || rmdir "$(DESTDIR)$(ivl_includedir)"
-	rm -f "$(DESTDIR)$(mandir)/man1/iverilog-vpi$(suffix).1" "$(DESTDIR)$(prefix)/iverilog-vpi$(suffix).pdf"
 
 
 -include $(patsubst %.o, dep/%.d, $O)
+
+.PHONY: check-installed check-installed-vpi check-installed-vvp check-installed-vvp-py

Module.cc

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1998-2026 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -21,13 +21,65 @@
 
 # include  "Module.h"
 # include  "PGate.h"
+# include  "PModport.h"
 # include  "PWire.h"
-# include  <cassert>
+# include  "parse_api.h"
+# include  "ivl_assert.h"
+# include  <iostream>
 
 using namespace std;
 
 list<Module::named_expr_t> Module::user_defparms;
 
+Module::port_t::port_t()
+: port_kind(P_SIGNAL), default_value(0), interface_unpacked_dimensions(0), lexical_pos(0)
+{
+}
+
+bool resolve_interface_formal_port(const LineInfo*li, Design*des,
+				   const Module::port_t*port,
+				   interface_formal_port_t&res,
+				   bool emit_errors)
+{
+      ivl_assert(*li, port);
+      ivl_assert(*li, port->is_interface_port());
+
+      res = interface_formal_port_t();
+
+      map<perm_string,Module*>::const_iterator mod =
+	    pform_modules.find(port->interface_type);
+      if (mod == pform_modules.end() || !mod->second->is_interface) {
+	    if (emit_errors) {
+		  cerr << li->get_fileline() << ": error: Interface port "
+		       << port->name << " uses unknown interface type `"
+		       << port->interface_type << "'." << endl;
+		  des->errors += 1;
+	    }
+	    return false;
+      }
+
+      res.module = mod->second;
+
+      if (port->modport_name.str()) {
+	    map<perm_string,PModport*>::const_iterator mp =
+		  mod->second->modports.find(port->modport_name);
+	    if (mp == mod->second->modports.end()) {
+		  if (emit_errors) {
+			cerr << li->get_fileline() << ": error: Interface port "
+			     << port->name << " uses unknown modport `"
+			     << port->modport_name << "' of interface `"
+			     << port->interface_type << "'." << endl;
+			des->errors += 1;
+		  }
+		  return false;
+	    }
+
+	    res.modport = mp->second;
+      }
+
+      return true;
+}
+
 /* n is a permallocated string. */
 Module::Module(LexicalScope*parent, perm_string n)
 : PScopeExtra(n, parent)
@@ -60,18 +112,24 @@ unsigned Module::port_count() const
  */
 const vector<PEIdent*>& Module::get_port(unsigned idx) const
 {
-      assert(idx < ports.size());
+      ivl_assert(*this, idx < ports.size());
       static const vector<PEIdent*> zero;
 
-      if (ports[idx])
+      if (ports[idx] && !ports[idx]->is_interface_port())
 	    return ports[idx]->expr;
       else
 	    return zero;
 }
 
+const Module::port_t* Module::get_port_info(unsigned idx) const
+{
+      ivl_assert(*this, idx < ports.size());
+      return ports[idx];
+}
+
 unsigned Module::find_port(const char*name) const
 {
-      assert(name != 0);
+      ivl_assert(*this, name != 0);
       for (unsigned idx = 0 ;  idx < ports.size() ;  idx += 1) {
 	    if (ports[idx] == 0) {
 		    /* It is possible to have undeclared ports. These
@@ -81,7 +139,7 @@ unsigned Module::find_port(const char*name) const
 		       inaccessible to binding by name. */
 		  continue;
 	    }
-	    assert(ports[idx]);
+	    ivl_assert(*this, ports[idx]);
 	    if (ports[idx]->name == name)
 		  return idx;
       }
@@ -92,7 +150,7 @@ unsigned Module::find_port(const char*name) const
 perm_string Module::get_port_name(unsigned idx) const
 {
 
-      assert(idx < ports.size());
+      ivl_assert(*this, idx < ports.size());
       if (ports[idx] == 0 || ports[idx]->name.str() == 0) {
               /* It is possible to have undeclared ports. These
                  are ports that are skipped in the declaration,
@@ -108,7 +166,7 @@ perm_string Module::get_port_name(unsigned idx) const
 
 PExpr* Module::get_port_default_value(unsigned idx) const
 {
-      assert(idx < ports.size());
+      ivl_assert(*this, idx < ports.size());
       return ports[idx] ? ports[idx]->default_value : 0;
 }
 
@@ -148,7 +206,7 @@ bool Module::can_be_toplevel() const
 
       // Don't choose modules with parameters without default value
       for (std::map<perm_string,param_expr_t*>::const_iterator cur =
-	    parameters.begin(); cur != parameters.end(); cur++) {
+	    parameters.begin(); cur != parameters.end(); ++cur) {
 	    if (cur->second->expr == 0)
 		  return false;
       }

Module.h

@@ -1,7 +1,7 @@
 #ifndef IVL_Module_H
 #define IVL_Module_H
 /*
- * Copyright (c) 1998-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1998-2026 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -37,11 +37,13 @@ class PGate;
 class PGenerate;
 class PModport;
 class PSpecPath;
+class PTimingCheck;
 class PTask;
 class PFunction;
 class PWire;
 class PProcess;
 class Design;
+class LineInfo;
 class NetScope;
 
 /*
@@ -64,16 +66,32 @@ class Module : public PScopeExtra, public PNamedItem {
 	   default value. */
     public:
       struct port_t {
+	    enum port_kind_t { P_SIGNAL, P_INTERFACE };
+
+	    port_t();
+
+	    port_kind_t port_kind;
 	    perm_string name;
 	    std::vector<PEIdent*> expr;
 	    PExpr*default_value;
+
+	      /* Interface formal port metadata. For signal ports these
+		 fields are empty/zero. The modport name is optional in the
+		 representation, although the parser initially only accepts
+		 the explicit interface_type.modport form. */
+	    perm_string interface_type;
+	    perm_string modport_name;
+	    std::list<pform_range_t>*interface_unpacked_dimensions;
+	    unsigned lexical_pos;
+
+	    bool is_interface_port() const { return port_kind == P_INTERFACE; }
       };
 
     public:
 	/* The name passed here is the module name, not the instance
 	   name. This name must be a permallocated string. */
       explicit Module(LexicalScope*parent, perm_string name);
-      ~Module();
+      ~Module() override;
 
 	/* Initially false. This is set to true if the module has been
 	   declared as a library module. This makes the module
@@ -136,7 +154,9 @@ class Module : public PScopeExtra, public PNamedItem {
            program blocks. */
       std::map<perm_string,PModport*> modports;
 
+	/* List for specify paths and timing checks */
       std::list<PSpecPath*> specify_paths;
+      std::list<PTimingCheck*> timing_checks;
 
 	// The mod_name() is the name of the module type.
       perm_string mod_name() const { return pscope_name(); }
@@ -145,6 +165,7 @@ class Module : public PScopeExtra, public PNamedItem {
 
       unsigned port_count() const;
       const std::vector<PEIdent*>& get_port(unsigned idx) const;
+      const port_t* get_port_info(unsigned idx) const;
       unsigned find_port(const char*name) const;
 
       // Return port name ("" for undeclared port)
@@ -164,12 +185,13 @@ class Module : public PScopeExtra, public PNamedItem {
 
       bool elaborate_sig(Design*, NetScope*scope) const;
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 
       bool can_be_toplevel() const;
 
     private:
       void dump_specparams_(std::ostream&out, unsigned indent) const;
+      void dump_timingchecks_(std::ostream&out, unsigned indent) const;
       std::list<PGate*> gates_;
 
     private: // Not implemented
@@ -177,4 +199,16 @@ class Module : public PScopeExtra, public PNamedItem {
       Module& operator= (const Module&);
 };
 
+struct interface_formal_port_t {
+      interface_formal_port_t() : module(0), modport(0) { }
+
+      const Module*module;
+      const PModport*modport;
+};
+
+extern bool resolve_interface_formal_port(const LineInfo*li, Design*des,
+					  const Module::port_t*port,
+					  interface_formal_port_t&res,
+					  bool emit_errors);
+
 #endif /* IVL_Module_H */

PClass.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PClass_H
 #define IVL_PClass_H
 /*
- * Copyright (c) 2012-2019 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 2012-2025 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -36,11 +36,11 @@ class PClass : public PScopeExtra, public PNamedItem {
 
     public:
       explicit PClass (perm_string name, LexicalScope*parent);
-      ~PClass();
+      ~PClass() override;
 
       void dump(std::ostream&out, unsigned indent) const;
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 
     public:
       class_type_t*type;

PDelays.cc

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1999-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1999-2026 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -130,10 +130,11 @@ static NetExpr* make_delay_nets(Design*des, NetScope*scope, NetExpr*expr)
       return expr;
 }
 
-static NetExpr* calc_decay_time(NetExpr *rise, NetExpr *fall)
+static const NetExpr *calc_decay_time(const NetExpr *rise,
+				      const NetExpr *fall)
 {
-      NetEConst *c_rise = dynamic_cast<NetEConst*>(rise);
+      const NetEConst *c_rise = dynamic_cast<const NetEConst*>(rise);
-      NetEConst *c_fall = dynamic_cast<NetEConst*>(fall);
+      const NetEConst *c_fall = dynamic_cast<const NetEConst*>(fall);
       if (c_rise && c_fall) {
 	    if (c_rise->value() < c_fall->value()) return rise;
 	    else return fall;
@@ -142,44 +143,43 @@ static NetExpr* calc_decay_time(NetExpr *rise, NetExpr *fall)
       return 0;
 }
 
-void PDelays::eval_delays(Design*des, NetScope*scope,
+void PDelays::eval_delays(Design*des, NetScope*scope, delay_exprs_t &delays,
-			  NetExpr*&rise_time,
-			  NetExpr*&fall_time,
-			  NetExpr*&decay_time,
 			  bool as_nets_flag) const
 {
       assert(scope);
 
-
       if (delay_[0]) {
-	    rise_time = calculate_val(des, scope, delay_[0]);
+	    NetExpr *rise = calculate_val(des, scope, delay_[0]);
 	    if (as_nets_flag)
-		  rise_time = make_delay_nets(des, scope, rise_time);
+		  rise = make_delay_nets(des, scope, rise);
+	    delays.rise = rise;
 
 	    if (delay_[1]) {
-		  fall_time = calculate_val(des, scope, delay_[1]);
+		  NetExpr *fall = calculate_val(des, scope, delay_[1]);
 		  if (as_nets_flag)
-			fall_time = make_delay_nets(des, scope, fall_time);
+			fall = make_delay_nets(des, scope, fall);
+		  delays.fall = fall;
 
 		  if (delay_[2]) {
-			decay_time = calculate_val(des, scope, delay_[2]);
+			NetExpr *decay = calculate_val(des, scope, delay_[2]);
 			if (as_nets_flag)
-			      decay_time = make_delay_nets(des, scope,
+			      decay = make_delay_nets(des, scope, decay);
-			                                   decay_time);
+			delays.decay = decay;
 
 		  } else {
 			// If this is zero then we need to do the min()
 			// at run time.
-			decay_time = calc_decay_time(rise_time, fall_time);
+			delays.decay = calc_decay_time(delays.rise,
+						       delays.fall);
 		  }
 	    } else {
 		  assert(delay_[2] == 0);
-		  fall_time = rise_time;
+		  delays.fall = delays.rise;
-		  decay_time = rise_time;
+		  delays.decay = delays.rise;
 	    }
       } else {
-	    rise_time = 0;
+	    delays.rise = nullptr;
-	    fall_time = 0;
+	    delays.fall = nullptr;
-	    decay_time = 0;
+	    delays.decay = nullptr;
       }
 }

PDelays.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PDelays_H
 #define IVL_PDelays_H
 /*
- * Copyright (c) 1999-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1999-2026 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -27,6 +27,7 @@ class Design;
 class NetScope;
 class NetExpr;
 class PExpr;
+struct delay_exprs_t;
 
 /*
  * Various PForm objects can carry delays. These delays include rise,
@@ -46,10 +47,7 @@ class PDelays {
 
       unsigned delay_count() const;
 
-      void eval_delays(Design*des, NetScope*scope,
+      void eval_delays(Design*des, NetScope*scope, delay_exprs_t &delays,
-		       NetExpr*&rise_time,
-		       NetExpr*&fall_time,
-		       NetExpr*&decay_time,
 		       bool as_nets_flag =false) const;
 
       void dump_delays(std::ostream&out) const;

PEvent.cc

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2004-2019 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 2004-2024 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -21,8 +21,8 @@
 
 # include  "PEvent.h"
 
-PEvent::PEvent(perm_string n)
+PEvent::PEvent(perm_string n, unsigned lexical_pos)
-: name_(n)
+: name_(n), lexical_pos_(lexical_pos)
 {
 }
 

PEvent.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PEvent_H
 #define IVL_PEvent_H
 /*
- * Copyright (c) 2000-2019 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 2000-2025 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -36,17 +36,20 @@ class PEvent : public PNamedItem {
     public:
 	// The name is a perm-allocated string. It is the simple name
 	// of the event, without any scope.
-      explicit PEvent(perm_string name);
+      explicit PEvent(perm_string name, unsigned lexical_pos);
-      ~PEvent();
+      ~PEvent() override;
 
       perm_string name() const;
 
+      unsigned lexical_pos() const { return lexical_pos_; }
+
       void elaborate_scope(Design*des, NetScope*scope) const;
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 
     private:
       perm_string name_;
+      unsigned lexical_pos_;
 
     private: // not implemented
       PEvent(const PEvent&);

PExpr.cc

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998-2021 Stephen Williams <steve@icarus.com>
+ * Copyright (c) 1998-2026 Stephen Williams <steve@icarus.com>
  * Copyright CERN 2013 / Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
@@ -20,12 +20,14 @@
 
 # include "config.h"
 
+# include  <algorithm>
 # include  <iostream>
 
 # include  "compiler.h"
 # include  "PExpr.h"
 # include  "PWire.h"
 # include  "Module.h"
+# include  "ivl_assert.h"
 # include  "netmisc.h"
 # include  "util.h"
 # include  <typeinfo>
@@ -53,7 +55,7 @@ bool PExpr::has_aa_term(Design*, NetScope*) const
       return false;
 }
 
-NetNet* PExpr::elaborate_lnet(Design*, NetScope*) const
+NetNet* PExpr::elaborate_lnet(Design*, NetScope*, bool) const
 {
       cerr << get_fileline() << ": error: "
            << "expression not valid in assign l-value: "
@@ -61,7 +63,7 @@ NetNet* PExpr::elaborate_lnet(Design*, NetScope*) const
       return 0;
 }
 
-NetNet* PExpr::elaborate_bi_net(Design*, NetScope*) const
+NetNet* PExpr::elaborate_bi_net(Design*, NetScope*, bool) const
 {
       cerr << get_fileline() << ": error: "
            << "expression not valid as argument to inout port: "
@@ -98,20 +100,24 @@ PEAssignPattern::PEAssignPattern()
 }
 
 PEAssignPattern::PEAssignPattern(const list<PExpr*>&p)
-: parms_(p.size())
+: parms_(p.begin(), p.end())
 {
-      size_t idx = 0;
-      for (list<PExpr*>::const_iterator cur = p.begin()
-		 ; cur != p.end() ; ++cur) {
-	    parms_[idx] = *cur;
-	    idx += 1;
-      }
 }
 
 PEAssignPattern::~PEAssignPattern()
 {
 }
 
+bool PEAssignPattern::has_aa_term(Design*des, NetScope*scope) const
+{
+      bool flag = false;
+      for (const auto *parm : parms_) {
+	    if (parm)
+		  flag = parm->has_aa_term(des, scope) || flag;
+      }
+      return flag;
+}
+
 PEBinary::PEBinary(char op, PExpr*l, PExpr*r)
 : op_(op), left_(l), right_(r)
 {
@@ -129,7 +135,7 @@ void PEBinary::declare_implicit_nets(LexicalScope*scope, NetNet::Type type)
 
 bool PEBinary::has_aa_term(Design*des, NetScope*scope) const
 {
-      assert(left_ && right_);
+      ivl_assert(*this, left_ && right_);
       return left_->has_aa_term(des, scope) || right_->has_aa_term(des, scope);
 }
 
@@ -150,6 +156,7 @@ bool PECastSize::has_aa_term(Design *des, NetScope *scope) const
 PECastType::PECastType(data_type_t*t, PExpr*b)
 : target_(t), base_(b)
 {
+      target_type_ = nullptr;
 }
 
 PECastType::~PECastType()
@@ -186,7 +193,7 @@ PEBComp::~PEBComp()
 PEBLogic::PEBLogic(char op, PExpr*l, PExpr*r)
 : PEBinary(op, l, r)
 {
-      assert(op == 'a' || op == 'o' || op == 'q' || op == 'Q');
+      ivl_assert(*this, op == 'a' || op == 'o' || op == 'q' || op == 'Q');
 }
 
 PEBLogic::~PEBLogic()
@@ -220,13 +227,13 @@ PEBShift::~PEBShift()
 {
 }
 
-PECallFunction::PECallFunction(const pform_name_t&n, const vector<PExpr *> &parms)
+PECallFunction::PECallFunction(const pform_name_t &n, const vector<named_pexpr_t> &parms)
-: package_(0), path_(n), parms_(parms), is_overridden_(false)
+: path_(n), parms_(parms), is_overridden_(false)
 {
 }
 
-PECallFunction::PECallFunction(PPackage*pkg, const pform_name_t&n, const vector<PExpr *> &parms)
+PECallFunction::PECallFunction(PPackage *pkg, const pform_name_t &n, const vector<named_pexpr_t> &parms)
-: package_(pkg), path_(n), parms_(parms), is_overridden_(false)
+: path_(pkg, n), parms_(parms), is_overridden_(false)
 {
 }
 
@@ -238,76 +245,78 @@ static pform_name_t pn_from_ps(perm_string n)
       return tmp;
 }
 
-PECallFunction::PECallFunction(PPackage*pkg, perm_string n, const list<PExpr *> &parms)
+PECallFunction::PECallFunction(PPackage *pkg, const pform_name_t &n, const list<named_pexpr_t> &parms)
-: package_(pkg), path_(pn_from_ps(n)), parms_(parms.size()), is_overridden_(false)
+: path_(pkg, n), parms_(parms.begin(), parms.end()), is_overridden_(false)
 {
-      int tmp_idx = 0;
-      assert(parms_.size() == parms.size());
-      for (list<PExpr*>::const_iterator idx = parms.begin()
-		 ; idx != parms.end() ; ++idx)
-	    parms_[tmp_idx++] = *idx;
 }
 
-PECallFunction::PECallFunction(perm_string n, const vector<PExpr*>&parms)
+PECallFunction::PECallFunction(perm_string n, const vector<named_pexpr_t> &parms)
-: package_(0), path_(pn_from_ps(n)), parms_(parms), is_overridden_(false)
+: path_(pn_from_ps(n)), parms_(parms), is_overridden_(false)
 {
 }
 
 PECallFunction::PECallFunction(perm_string n)
-: package_(0), path_(pn_from_ps(n)), is_overridden_(false)
+: path_(pn_from_ps(n)), is_overridden_(false)
 {
 }
 
 // NOTE: Anachronism. Try to work all use of svector out.
-PECallFunction::PECallFunction(const pform_name_t&n, const list<PExpr *> &parms)
+PECallFunction::PECallFunction(const pform_name_t &n, const list<named_pexpr_t> &parms)
-: package_(0), path_(n), parms_(parms.size()), is_overridden_(false)
+: path_(n), parms_(parms.begin(), parms.end()), is_overridden_(false)
 {
-      int tmp_idx = 0;
-      assert(parms_.size() == parms.size());
-      for (list<PExpr*>::const_iterator idx = parms.begin()
-		 ; idx != parms.end() ; ++idx)
-	    parms_[tmp_idx++] = *idx;
 }
 
-PECallFunction::PECallFunction(perm_string n, const list<PExpr*>&parms)
+PECallFunction::PECallFunction(perm_string n, const list<named_pexpr_t> &parms)
-: package_(0), path_(pn_from_ps(n)), parms_(parms.size()), is_overridden_(false)
+: path_(pn_from_ps(n)), parms_(parms.begin(), parms.end()), is_overridden_(false)
+{
+}
+
+PECallFunction::PECallFunction(PExpr* chain_prefix, const pform_name_t &method,
+			       const vector<named_pexpr_t> &parms)
+: path_(method), parms_(parms), chain_prefix_(chain_prefix), is_overridden_(false)
+{
+}
+
+PECallFunction::PECallFunction(PExpr* chain_prefix, const pform_name_t &method,
+			       const list<named_pexpr_t> &parms)
+: path_(method), parms_(parms.begin(), parms.end()),
+  chain_prefix_(chain_prefix), is_overridden_(false)
 {
-      int tmp_idx = 0;
-      assert(parms_.size() == parms.size());
-      for (list<PExpr*>::const_iterator idx = parms.begin()
-		 ; idx != parms.end() ; ++idx)
-	    parms_[tmp_idx++] = *idx;
 }
 
 PECallFunction::~PECallFunction()
 {
+      delete chain_prefix_;
 }
 
 void PECallFunction::declare_implicit_nets(LexicalScope*scope, NetNet::Type type)
 {
-      for (unsigned idx = 0 ; idx < parms_.size() ; idx += 1) {
+      if (chain_prefix_) {
-	    parms_[idx]->declare_implicit_nets(scope, type);
+	    chain_prefix_->declare_implicit_nets(scope, type);
+	  }
+      for (const auto &parm : parms_) {
+	    if (parm.parm) {
+		  parm.parm->declare_implicit_nets(scope, type);
+		}
       }
 }
 
 bool PECallFunction::has_aa_term(Design*des, NetScope*scope) const
 {
-      bool flag = false;
+      if (chain_prefix_ && chain_prefix_->has_aa_term(des, scope)) {
-      for (unsigned idx = 0 ; idx < parms_.size() ; idx += 1) {
+	    return true;
-	    flag = parms_[idx]->has_aa_term(des, scope) || flag;
+	  }
+      for (const auto &parm : parms_) {
+	    if (parm.parm && parm.parm->has_aa_term(des, scope)) {
+		  return true;
+		}
       }
-      return flag;
+      return false;
 }
 
 PEConcat::PEConcat(const list<PExpr*>&p, PExpr*r)
-: parms_(p.size()), width_modes_(SIZED, p.size()), repeat_(r)
+: parms_(p.begin(), p.end()), width_modes_(SIZED, p.size()), repeat_(r)
 {
-      int tmp_idx = 0;
-      assert(parms_.size() == p.size());
-      for (list<PExpr*>::const_iterator idx = p.begin()
-		 ; idx != p.end() ; ++idx)
-	    parms_[tmp_idx++] = *idx;
-
       tested_scope_ = 0;
       repeat_count_ = 1;
 }
@@ -352,7 +361,7 @@ PEEvent::edge_t PEEvent::type() const
 
 bool PEEvent::has_aa_term(Design*des, NetScope*scope) const
 {
-      assert(expr_);
+      ivl_assert(*this, expr_);
       return expr_->has_aa_term(des, scope);
 }
 
@@ -384,19 +393,19 @@ const verireal& PEFNumber::value() const
       return *value_;
 }
 
-PEIdent::PEIdent(const pform_name_t&that)
+PEIdent::PEIdent(const pform_name_t&that, unsigned lexical_pos)
-: package_(0), path_(that), no_implicit_sig_(false)
+: path_(that), lexical_pos_(lexical_pos), no_implicit_sig_(false)
 {
 }
 
-PEIdent::PEIdent(perm_string s, bool no_implicit_sig)
+PEIdent::PEIdent(perm_string s, unsigned lexical_pos, bool no_implicit_sig)
-: package_(0), no_implicit_sig_(no_implicit_sig)
+: lexical_pos_(lexical_pos), no_implicit_sig_(no_implicit_sig)
 {
-      path_.push_back(name_component_t(s));
+      path_.name.push_back(name_component_t(s));
 }
 
-PEIdent::PEIdent(PPackage*pkg, const pform_name_t&that)
+PEIdent::PEIdent(PPackage*pkg, const pform_name_t&that, unsigned lexical_pos)
-: package_(pkg), path_(that), no_implicit_sig_(true)
+: path_(pkg, that), lexical_pos_(lexical_pos), no_implicit_sig_(true)
 {
 }
 
@@ -406,14 +415,11 @@ PEIdent::~PEIdent()
 
 static bool find_enum_constant(LexicalScope*scope, perm_string name)
 {
-      for (vector<enum_type_t*>::const_iterator cur = scope->enum_sets.begin() ;
+      return std::any_of(scope->enum_sets.cbegin(), scope->enum_sets.cend(),
-           cur != scope->enum_sets.end() ; ++ cur) {
+                         [name](const enum_type_t *cur) {
-	    for (list<named_pexpr_t>::const_iterator idx = (*cur)->names->begin() ;
+	    return std::any_of(cur->names->cbegin(), cur->names->cend(),
-                 idx != (*cur)->names->end() ; ++ idx) {
+	                       [name](const named_pexpr_t&idx){return idx.name == name;});
-                  if (idx->name == name) return true;
+      });
-            }
-      }
-      return false;
 }
 
 void PEIdent::declare_implicit_nets(LexicalScope*scope, NetNet::Type type)
@@ -425,8 +431,10 @@ void PEIdent::declare_implicit_nets(LexicalScope*scope, NetNet::Type type)
 	   - this is not an implicit named port connection */
      if (no_implicit_sig_)
 	    return;
-     if ((path_.size() == 1) && (path_.front().index.size() == 0)) {
+     if (path_.package)
-            perm_string name = path_.front().name;
+	    return;
+     if (path_.name.size() == 1 && path_.name.front().index.empty()) {
+            perm_string name = path_.name.front().name;
             LexicalScope*ss = scope;
             while (ss) {
                   if (ss->wires.find(name) != ss->wires.end())
@@ -448,7 +456,7 @@ void PEIdent::declare_implicit_nets(LexicalScope*scope, NetNet::Type type)
 
                   ss = ss->parent_scope();
             }
-            PWire*net = new PWire(name, type, NetNet::NOT_A_PORT);
+            PWire*net = new PWire(name, lexical_pos_, type, NetNet::NOT_A_PORT);
             net->set_file(get_file());
             net->set_lineno(get_lineno());
             scope->wires[name] = net;
@@ -462,7 +470,7 @@ void PEIdent::declare_implicit_nets(LexicalScope*scope, NetNet::Type type)
 bool PEIdent::has_aa_term(Design*des, NetScope*scope) const
 {
       symbol_search_results sr;
-      if (!symbol_search(this, des, scope, path_, &sr))
+      if (!symbol_search(this, des, scope, path_, lexical_pos_, &sr))
 	    return false;
 
       // Class properties are not considered automatic since a non-blocking
@@ -488,14 +496,9 @@ PENewClass::PENewClass(void)
 {
 }
 
-PENewClass::PENewClass(const list<PExpr*>&p, data_type_t *class_type)
+PENewClass::PENewClass(const list<named_pexpr_t> &p, data_type_t *class_type)
-: parms_(p.size()), class_type_(class_type)
+: parms_(p.begin(), p.end()), class_type_(class_type)
 {
-      size_t tmp_idx = 0;
-      for (list<PExpr*>::const_iterator cur = p.begin()
-		 ; cur != p.end() ; ++ cur) {
-	    parms_[tmp_idx++] = *cur;
-      }
 }
 
 PENewClass::~PENewClass()
@@ -514,7 +517,7 @@ PENewCopy::~PENewCopy()
 PENumber::PENumber(verinum*vp)
 : value_(vp)
 {
-      assert(vp);
+      ivl_assert(*this, vp);
 }
 
 PENumber::~PENumber()
@@ -553,7 +556,7 @@ PETernary::~PETernary()
 
 void PETernary::declare_implicit_nets(LexicalScope*scope, NetNet::Type type)
 {
-      assert(expr_ && tru_ && fal_);
+      ivl_assert(*this, expr_ && tru_ && fal_);
       expr_->declare_implicit_nets(scope, type);
       tru_->declare_implicit_nets(scope, type);
       fal_->declare_implicit_nets(scope, type);
@@ -561,7 +564,7 @@ void PETernary::declare_implicit_nets(LexicalScope*scope, NetNet::Type type)
 
 bool PETernary::has_aa_term(Design*des, NetScope*scope) const
 {
-      assert(expr_ && tru_ && fal_);
+      ivl_assert(*this, expr_ && tru_ && fal_);
       return expr_->has_aa_term(des, scope)
            || tru_->has_aa_term(des, scope)
            || fal_->has_aa_term(des, scope);
@@ -587,13 +590,13 @@ PEUnary::~PEUnary()
 
 void PEUnary::declare_implicit_nets(LexicalScope*scope, NetNet::Type type)
 {
-      assert(expr_);
+      ivl_assert(*this, expr_);
       expr_->declare_implicit_nets(scope, type);
 }
 
 bool PEUnary::has_aa_term(Design*des, NetScope*scope) const
 {
-      assert(expr_);
+      ivl_assert(*this, expr_);
       return expr_->has_aa_term(des, scope);
 }
 

PExpr.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PExpr_H
 #define IVL_PExpr_H
 /*
- * Copyright (c) 1998-2021 Stephen Williams <steve@icarus.com>
+ * Copyright (c) 1998-2026 Stephen Williams <steve@icarus.com>
  * Copyright CERN 2013 / Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
@@ -37,6 +37,7 @@ class NetExpr;
 class NetScope;
 class PPackage;
 struct symbol_search_results;
+class netclass_t;
 
 /*
  * The PExpr class hierarchy supports the description of
@@ -60,7 +61,7 @@ class PExpr : public LineInfo {
       static const char*width_mode_name(width_mode_t mode);
 
       PExpr();
-      virtual ~PExpr();
+      virtual ~PExpr() override;
 
       virtual void dump(std::ostream&) const;
 
@@ -156,13 +157,15 @@ class PExpr : public LineInfo {
 
 	// This method elaborates the expression as gates, but
 	// restricted for use as l-values of continuous assignments.
-      virtual NetNet* elaborate_lnet(Design*des, NetScope*scope) const;
+      virtual NetNet* elaborate_lnet(Design*des, NetScope*scope,
+                                     bool var_allowed_in_sv) const;
 
 	// This is similar to elaborate_lnet, except that the
 	// expression is evaluated to be bi-directional. This is
 	// useful for arguments to inout ports of module instances and
 	// ports of tran primitives.
-      virtual NetNet* elaborate_bi_net(Design*des, NetScope*scope) const;
+      virtual NetNet* elaborate_bi_net(Design*des, NetScope*scope,
+                                       bool var_allowed_in_sv) const;
 
 	// Expressions that can be in the l-value of procedural
 	// assignments can be elaborated with this method. If the
@@ -172,7 +175,8 @@ class PExpr : public LineInfo {
       virtual NetAssign_* elaborate_lval(Design*des,
 					 NetScope*scope,
 					 bool is_cassign,
-					 bool is_force) const;
+					 bool is_force,
+					 bool is_init = false) const;
 
 	// This method returns true if the expression represents a
         // structural net that can have multiple drivers. This is
@@ -201,20 +205,37 @@ class PEAssignPattern : public PExpr {
     public:
       explicit PEAssignPattern();
       explicit PEAssignPattern(const std::list<PExpr*>&p);
-      ~PEAssignPattern();
+      ~PEAssignPattern() override;
 
-      void dump(std::ostream&) const;
+      void dump(std::ostream&) const override;
 
-      virtual unsigned test_width(Design*des, NetScope*scope, width_mode_t&mode);
+      virtual bool has_aa_term(Design*des, NetScope*scope) const override;
+
+      virtual unsigned test_width(Design*des, NetScope*scope, width_mode_t&mode) override;
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
     private:
-      NetExpr* elaborate_expr_darray_(Design*des, NetScope*scope,
+      NetExpr* elaborate_expr_packed_(Design *des, NetScope *scope,
-				      ivl_type_t type, unsigned flags) const;
+				      ivl_variable_type_t base_type,
+				      unsigned int width,
+				      const netranges_t &dims,
+				      unsigned int cur_dim,
+				      bool need_const) const;
+      NetExpr* elaborate_expr_struct_(Design *des, NetScope *scope,
+				      const netstruct_t *struct_type,
+				      bool need_const) const;
+      NetExpr* elaborate_expr_array_(Design *des, NetScope *scope,
+				     const netarray_t *array_type,
+				     bool need_const, bool up) const;
+      NetExpr* elaborate_expr_uarray_(Design *des, NetScope *scope,
+				      const netuarray_t *uarray_type,
+				      const netranges_t &dims,
+				      unsigned int cur_dim,
+				      bool need_const) const;
 
     private:
       std::vector<PExpr*>parms_;
@@ -224,35 +245,39 @@ class PEConcat : public PExpr {
 
     public:
       explicit PEConcat(const std::list<PExpr*>&p, PExpr*r =0);
-      ~PEConcat();
+      ~PEConcat() override;
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
 
-      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type);
+      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type) override;
 
-      virtual bool has_aa_term(Design*des, NetScope*scope) const;
+      virtual bool has_aa_term(Design*des, NetScope*scope) const override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
-      virtual NetNet* elaborate_lnet(Design*des, NetScope*scope) const;
+      virtual NetNet* elaborate_lnet(Design*des, NetScope*scope,
-      virtual NetNet* elaborate_bi_net(Design*des, NetScope*scope) const;
+                                     bool var_allowed_in_sv) const override;
+      virtual NetNet* elaborate_bi_net(Design*des, NetScope*scope,
+                                       bool var_allowed_in_sv) const override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
       virtual NetAssign_* elaborate_lval(Design*des,
 					 NetScope*scope,
 					 bool is_cassign,
-					 bool is_force) const;
+					 bool is_force,
+					 bool is_init = false) const override;
       virtual bool is_collapsible_net(Design*des, NetScope*scope,
-                                      NetNet::PortType port_type) const;
+                                      NetNet::PortType port_type) const override;
     private:
       NetNet* elaborate_lnet_common_(Design*des, NetScope*scope,
-				     bool bidirectional_flag) const;
+				     bool bidirectional_flag,
+				     bool var_allowed_in_sv) const;
     private:
       std::vector<PExpr*>parms_;
       std::valarray<width_mode_t>width_modes_;
@@ -277,14 +302,14 @@ class PEEvent : public PExpr {
 	// Use this constructor to create events based on edges or levels.
       PEEvent(edge_t t, PExpr*e);
 
-      ~PEEvent();
+      ~PEEvent() override;
 
       edge_t type() const;
       PExpr* expr() const;
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
 
-      virtual bool has_aa_term(Design*des, NetScope*scope) const;
+      virtual bool has_aa_term(Design*des, NetScope*scope) const override;
 
     private:
       edge_t type_;
@@ -298,19 +323,19 @@ class PEFNumber : public PExpr {
 
     public:
       explicit PEFNumber(verireal*vp);
-      ~PEFNumber();
+      ~PEFNumber() override;
 
       const verireal& value() const;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
       virtual NetExpr*elaborate_expr(Design*des, NetScope*,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
       virtual NetExpr*elaborate_expr(Design*des, NetScope*,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
 
     private:
       verireal*value_;
@@ -319,40 +344,41 @@ class PEFNumber : public PExpr {
 class PEIdent : public PExpr {
 
     public:
-      explicit PEIdent(perm_string, bool no_implicit_sig=false);
+      explicit PEIdent(perm_string, unsigned lexical_pos, bool no_implicit_sig=false);
-      explicit PEIdent(PPackage*pkg, const pform_name_t&name);
+      explicit PEIdent(PPackage*pkg, const pform_name_t&name, unsigned lexical_pos);
-      explicit PEIdent(const pform_name_t&);
+      explicit PEIdent(const pform_name_t&, unsigned lexical_pos);
-      ~PEIdent();
+      ~PEIdent() override;
 
 	// Add another name to the string of hierarchy that is the
 	// current identifier.
       void append_name(perm_string);
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
 
-      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type);
+      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type) override;
 
-      virtual bool has_aa_term(Design*des, NetScope*scope) const;
+      virtual bool has_aa_term(Design*des, NetScope*scope) const override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
 	// Identifiers are allowed (with restrictions) is assign l-values.
-      virtual NetNet* elaborate_lnet(Design*des, NetScope*scope) const;
+      virtual NetNet* elaborate_lnet(Design*des, NetScope*scope, bool var_allowed_in_sv) const override;
 
-      virtual NetNet* elaborate_bi_net(Design*des, NetScope*scope) const;
+      virtual NetNet* elaborate_bi_net(Design*des, NetScope*scope, bool var_allowed_in_sv) const override;
 
 	// Identifiers are also allowed as procedural assignment l-values.
       virtual NetAssign_* elaborate_lval(Design*des,
 					 NetScope*scope,
 					 bool is_cassign,
-					 bool is_force) const;
+					 bool is_force,
+					 bool is_init = false) const override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
       virtual NetExpr*elaborate_expr(Design*des, NetScope*,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 
 	// Elaborate the PEIdent as a port to a module. This method
 	// only applies to Ident expressions.
@@ -364,15 +390,15 @@ class PEIdent : public PExpr {
       NetNet* elaborate_unpacked_net(Design*des, NetScope*sc) const;
 
       virtual bool is_collapsible_net(Design*des, NetScope*scope,
-                                      NetNet::PortType port_type) const;
+                                      NetNet::PortType port_type) const override;
 
-      const PPackage* package() const { return package_; }
+      const pform_scoped_name_t& path() const { return path_; }
 
-      const pform_name_t& path() const { return path_; }
+      unsigned lexical_pos() const { return lexical_pos_; }
 
     private:
-      PPackage*package_;
+      pform_scoped_name_t path_;
-      pform_name_t path_;
+      unsigned lexical_pos_;
       bool no_implicit_sig_;
 
     private:
@@ -389,7 +415,7 @@ class PEIdent : public PExpr {
 	// the values written to the msb/lsb arguments. If there are
 	// invalid bits (xz) in either expression, then the defined
 	// flag is set to *false*.
-      bool calculate_parts_(Design*, NetScope*, long&msb, long&lsb, bool&defined) const;
+      void calculate_parts_(Design*, NetScope*, long&msb, long&lsb, bool&defined) const;
       NetExpr* calculate_up_do_base_(Design*, NetScope*, bool need_const) const;
 
       bool calculate_up_do_width_(Design*, NetScope*, unsigned long&wid) const;
@@ -403,28 +429,37 @@ class PEIdent : public PExpr {
 	//    [2:0][x]     - BAD
 	//    [y][x]       - BAD
 	// Leave the last index for special handling.
-      bool calculate_packed_indices_(Design*des, NetScope*scope, NetNet*net,
+      bool calculate_packed_indices_(Design*des, NetScope*scope, const NetNet*net,
 				     std::list<long>&prefix_indices) const;
 
     private:
-      NetAssign_*elaborate_lval_method_class_member_(Design*, NetScope*) const;
+
+      void report_mixed_assignment_conflict_(const char*category) const;
+
+      NetAssign_ *elaborate_lval_array_(Design *des, NetScope *scope,
+				        bool is_force, NetNet *reg) const;
+      NetAssign_ *elaborate_lval_var_(Design *des, NetScope *scope,
+				      bool is_force, bool is_cassign,
+				      NetNet *reg, ivl_type_t data_type,
+				      pform_name_t tail_path) const;
       NetAssign_*elaborate_lval_net_word_(Design*, NetScope*, NetNet*,
-					  bool need_const_idx) const;
+					  bool need_const_idx, bool is_force) const;
       bool elaborate_lval_net_bit_(Design*, NetScope*, NetAssign_*,
-				   bool need_const_idx) const;
+				   bool need_const_idx, bool is_force) const;
-      bool elaborate_lval_net_part_(Design*, NetScope*, NetAssign_*) const;
+      bool elaborate_lval_net_part_(Design*, NetScope*, NetAssign_*,
+				    bool is_force) const;
       bool elaborate_lval_net_idx_(Design*, NetScope*, NetAssign_*,
                                    index_component_t::ctype_t,
-				   bool need_const_idx) const;
+				   bool need_const_idx, bool is_force) const;
       NetAssign_*elaborate_lval_net_class_member_(Design*, NetScope*,
 						   const netclass_t *class_type,
 						   NetNet*,
 						   pform_name_t) const;
       bool elaborate_lval_net_packed_member_(Design*, NetScope*,
 					     NetAssign_*,
-					     pform_name_t member_path) const;
+					     pform_name_t member_path, bool is_force) const;
       bool elaborate_lval_darray_bit_(Design*, NetScope*,
-				       NetAssign_*) const;
+				      NetAssign_*, bool is_force) const;
 
     private:
       NetExpr* elaborate_expr_(Design *des, NetScope *scope,
@@ -456,18 +491,12 @@ class PEIdent : public PExpr {
 					 const NetScope*found_in,
 					 ivl_type_t par_type,
 				         unsigned expr_wid) const;
-      NetExpr*elaborate_expr_param_idx_up_(Design*des,
+      NetExpr*elaborate_expr_param_idx_up_do_(Design*des,
-					   NetScope*scope,
+					      NetScope*scope,
-					   const NetExpr*par,
+					      const NetExpr*par,
-					   const NetScope*found_in,
+					      const NetScope*found_in,
-					   ivl_type_t par_type,
+					      ivl_type_t par_type,
-                                           bool need_const) const;
+					      bool up, bool need_const) const;
-      NetExpr*elaborate_expr_param_idx_do_(Design*des,
-					   NetScope*scope,
-					   const NetExpr*par,
-					   const NetScope*found_in,
-					   ivl_type_t par_type,
-                                           bool need_const) const;
       NetExpr*elaborate_expr_net(Design*des,
 				 NetScope*scope,
 				 NetNet*net,
@@ -485,16 +514,11 @@ class PEIdent : public PExpr {
 				       NetESignal*net,
 				       NetScope*found,
 				       unsigned expr_wid) const;
-      NetExpr*elaborate_expr_net_idx_up_(Design*des,
+      NetExpr*elaborate_expr_net_idx_up_do_(Design*des,
-				         NetScope*scope,
+					    NetScope*scope,
-				         NetESignal*net,
+					    NetESignal*net,
-				         NetScope*found,
+					    NetScope*found,
-                                         bool need_const) const;
+					    bool up, bool need_const) const;
-      NetExpr*elaborate_expr_net_idx_do_(Design*des,
-				         NetScope*scope,
-				         NetESignal*net,
-				         NetScope*found,
-                                         bool need_const) const;
       NetExpr*elaborate_expr_net_bit_(Design*des,
 				      NetScope*scope,
 				      NetESignal*net,
@@ -506,26 +530,23 @@ class PEIdent : public PExpr {
 					   NetScope*found,
 					   bool need_const) const;
 
-      NetExpr*elaborate_expr_class_member_(Design*des,
-					   NetScope*scope,
-					   unsigned expr_wid,
-					   unsigned flags) const;
-
       NetExpr *elaborate_expr_class_field_(Design*des, NetScope*scope,
 					   const symbol_search_results &sr,
 					   unsigned expr_wid,
 					   unsigned flags) const;
 
-      unsigned test_width_method_(Design*des, NetScope*scope, width_mode_t&mode);
-
       unsigned test_width_parameter_(const NetExpr *par, width_mode_t&mode);
 
+      ivl_type_t resolve_type_(Design *des, const symbol_search_results &sr,
+			       unsigned int &index_depth) const;
+
     private:
       NetNet* elaborate_lnet_common_(Design*des, NetScope*scope,
-				     bool bidirectional_flag) const;
+				     bool bidirectional_flag,
+				     bool var_allowed_in_sv) const;
 
 
-      bool eval_part_select_(Design*des, NetScope*scope, NetNet*sig,
+      bool eval_part_select_(Design*des, NetScope*scope, const NetNet*sig,
 			     long&midx, long&lidx) const;
 };
 
@@ -533,16 +554,16 @@ class PENewArray : public PExpr {
 
     public:
       explicit PENewArray (PExpr*s, PExpr*i);
-      ~PENewArray();
+      ~PENewArray() override;
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
       virtual NetExpr*elaborate_expr(Design*des, NetScope*,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 
     private:
       PExpr*size_;
@@ -555,21 +576,21 @@ class PENewClass : public PExpr {
 	// New without (or with default) constructor
       explicit PENewClass ();
 	// New with constructor arguments
-      explicit PENewClass (const std::list<PExpr*>&p,
+      explicit PENewClass (const std::list<named_pexpr_t> &p,
 			   data_type_t *class_type = nullptr);
 
-      ~PENewClass();
+      ~PENewClass() override;
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
 	// Class objects don't have a useful width, but the expression
 	// is IVL_VT_CLASS.
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 	// Note that class (new) expressions only appear in context
 	// that uses this form of the elaborate_expr method. In fact,
 	// the type argument is going to be a netclass_t object.
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
 
     private:
       NetExpr* elaborate_expr_constructor_(Design*des, NetScope*scope,
@@ -577,25 +598,25 @@ class PENewClass : public PExpr {
 					   NetExpr*obj, unsigned flags) const;
 
     private:
-      std::vector<PExpr*>parms_;
+      std::vector<named_pexpr_t> parms_;
       data_type_t *class_type_;
 };
 
 class PENewCopy : public PExpr {
     public:
       explicit PENewCopy(PExpr*src);
-      ~PENewCopy();
+      ~PENewCopy() override;
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
 	// Class objects don't have a useful width, but the expression
 	// is IVL_VT_CLASS.
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 	// Note that class (new) expressions only appear in context
 	// that uses this form of the elaborate_expr method. In fact,
 	// the type argument is going to be a netclass_t object.
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
 
     private:
       PExpr*src_;
@@ -604,38 +625,39 @@ class PENewCopy : public PExpr {
 class PENull : public PExpr {
     public:
       explicit PENull();
-      ~PENull();
+      ~PENull() override;
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
       virtual NetExpr*elaborate_expr(Design*des, NetScope*,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 };
 
 class PENumber : public PExpr {
 
     public:
       explicit PENumber(verinum*vp);
-      ~PENumber();
+      ~PENumber() override;
 
       const verinum& value() const;
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
       virtual NetExpr  *elaborate_expr(Design*des, NetScope*scope,
-				       ivl_type_t type, unsigned flags) const;
+				       ivl_type_t type, unsigned flags) const override;
       virtual NetEConst*elaborate_expr(Design*des, NetScope*,
-				       unsigned expr_wid, unsigned) const;
+				       unsigned expr_wid, unsigned) const override;
       virtual NetAssign_* elaborate_lval(Design*des,
 					 NetScope*scope,
 					 bool is_cassign,
-					 bool is_force) const;
+					 bool is_force,
+					 bool is_init = false) const override;
 
     private:
       verinum*const value_;
@@ -652,20 +674,24 @@ class PEString : public PExpr {
 
     public:
       explicit PEString(char*s);
-      ~PEString();
+      ~PEString() override;
 
       std::string value() const;
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
-      virtual NetEConst*elaborate_expr(Design*des, NetScope*scope,
+      virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				       ivl_type_t type, unsigned flags) const;
+				       ivl_type_t type, unsigned flags) const override;
 
       virtual NetEConst*elaborate_expr(Design*des, NetScope*,
-				       unsigned expr_wid, unsigned) const;
+				       unsigned expr_wid, unsigned) const override;
 
+      NetExpr *elaborate_expr_uarray_(Design *des, NetScope *scope,
+				      const netuarray_t *uarray_type,
+				      const std::vector<netrange_t> &dims,
+				      unsigned int cur_dim) const;
     private:
       char*text_;
 };
@@ -673,13 +699,13 @@ class PEString : public PExpr {
 class PETypename : public PExpr {
     public:
       explicit PETypename(data_type_t*data_type);
-      ~PETypename();
+      ~PETypename() override;
 
-      virtual void dump(std::ostream&) const;
+      virtual void dump(std::ostream&) const override;
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
 
       inline data_type_t* get_type() const { return data_type_; }
 
@@ -691,20 +717,20 @@ class PEUnary : public PExpr {
 
     public:
       explicit PEUnary(char op, PExpr*ex);
-      ~PEUnary();
+      ~PEUnary() override;
 
-      virtual void dump(std::ostream&out) const;
+      virtual void dump(std::ostream&out) const override;
 
-      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type);
+      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type) override;
 
-      virtual bool has_aa_term(Design*des, NetScope*scope) const;
+      virtual bool has_aa_term(Design*des, NetScope*scope) const override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 
     public:
       inline char get_op() const { return op_; }
@@ -722,20 +748,20 @@ class PEBinary : public PExpr {
 
     public:
       explicit PEBinary(char op, PExpr*l, PExpr*r);
-      ~PEBinary();
+      ~PEBinary() override;
 
-      virtual void dump(std::ostream&out) const;
+      virtual void dump(std::ostream&out) const override;
 
-      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type);
+      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type) override;
 
-      virtual bool has_aa_term(Design*des, NetScope*scope) const;
+      virtual bool has_aa_term(Design*des, NetScope*scope) const override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 
     protected:
       char op_;
@@ -766,13 +792,13 @@ class PEBComp  : public PEBinary {
 
     public:
       explicit PEBComp(char op, PExpr*l, PExpr*r);
-      ~PEBComp();
+      ~PEBComp() override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
       NetExpr* elaborate_expr(Design*des, NetScope*scope,
-			      unsigned expr_wid, unsigned flags) const;
+			      unsigned expr_wid, unsigned flags) const override;
 
     private:
       unsigned l_width_;
@@ -786,13 +812,13 @@ class PEBLogic  : public PEBinary {
 
     public:
       explicit PEBLogic(char op, PExpr*l, PExpr*r);
-      ~PEBLogic();
+      ~PEBLogic() override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
       NetExpr* elaborate_expr(Design*des, NetScope*scope,
-			      unsigned expr_wid, unsigned flags) const;
+			      unsigned expr_wid, unsigned flags) const override;
 };
 
 /*
@@ -804,38 +830,38 @@ class PEBLeftWidth  : public PEBinary {
 
     public:
       explicit PEBLeftWidth(char op, PExpr*l, PExpr*r);
-      ~PEBLeftWidth() =0;
+      ~PEBLeftWidth() override =0;
 
       virtual NetExpr*elaborate_expr_leaf(Design*des, NetExpr*lp, NetExpr*rp,
 					  unsigned expr_wid) const =0;
 
     protected:
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 };
 
 class PEBPower  : public PEBLeftWidth {
 
     public:
       explicit PEBPower(char op, PExpr*l, PExpr*r);
-      ~PEBPower();
+      ~PEBPower() override;
 
       NetExpr*elaborate_expr_leaf(Design*des, NetExpr*lp, NetExpr*rp,
-				  unsigned expr_wid) const;
+				  unsigned expr_wid) const override;
 };
 
 class PEBShift  : public PEBLeftWidth {
 
     public:
       explicit PEBShift(char op, PExpr*l, PExpr*r);
-      ~PEBShift();
+      ~PEBShift() override;
 
       NetExpr*elaborate_expr_leaf(Design*des, NetExpr*lp, NetExpr*rp,
-				  unsigned expr_wid) const;
+				  unsigned expr_wid) const override;
 };
 
 /*
@@ -846,20 +872,20 @@ class PETernary : public PExpr {
 
     public:
       explicit PETernary(PExpr*e, PExpr*t, PExpr*f);
-      ~PETernary();
+      ~PETernary() override;
 
-      virtual void dump(std::ostream&out) const;
+      virtual void dump(std::ostream&out) const override;
 
-      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type);
+      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type) override;
 
-      virtual bool has_aa_term(Design*des, NetScope*scope) const;
+      virtual bool has_aa_term(Design*des, NetScope*scope) const override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*,
 		                     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 
     private:
       NetExpr* elab_and_eval_alternative_(Design*des, NetScope*scope,
@@ -879,43 +905,53 @@ class PETernary : public PExpr {
  */
 class PECallFunction : public PExpr {
     public:
-      explicit PECallFunction(const pform_name_t&n, const std::vector<PExpr *> &parms);
+      explicit PECallFunction(const pform_name_t &n, const std::vector<named_pexpr_t> &parms);
 	// Call function defined in package.
-      explicit PECallFunction(PPackage*pkg, perm_string n, const std::vector<PExpr *> &parms);
+      explicit PECallFunction(PPackage *pkg, const pform_name_t &n, const std::list<named_pexpr_t> &parms);
-      explicit PECallFunction(PPackage*pkg, perm_string n, const std::list<PExpr *> &parms);
 
 	// Used to convert a user function called as a task
-      explicit PECallFunction(PPackage*pkg, const pform_name_t&n, const std::vector<PExpr *> &parms);
+      explicit PECallFunction(PPackage *pkg, const pform_name_t &n, const std::vector<named_pexpr_t> &parms);
 
 	// Call of system function (name is not hierarchical)
-      explicit PECallFunction(perm_string n, const std::vector<PExpr *> &parms);
+      explicit PECallFunction(perm_string n, const std::vector<named_pexpr_t> &parms);
       explicit PECallFunction(perm_string n);
 
 	// std::list versions. Should be removed!
-      explicit PECallFunction(const pform_name_t&n, const std::list<PExpr *> &parms);
+      explicit PECallFunction(const pform_name_t &n, const std::list<named_pexpr_t> &parms);
-      explicit PECallFunction(perm_string n, const std::list<PExpr *> &parms);
+      explicit PECallFunction(perm_string n, const std::list<named_pexpr_t> &parms);
 
-      ~PECallFunction();
+	// SystemVerilog: prefix().method(args) — prefix elaborates to a class handle.
+      explicit PECallFunction(PExpr* chain_prefix, const pform_name_t &method,
+			      const std::vector<named_pexpr_t> &parms);
+      explicit PECallFunction(PExpr* chain_prefix, const pform_name_t &method,
+			      const std::list<named_pexpr_t> &parms);
 
-      virtual void dump(std::ostream &) const;
+      ~PECallFunction() override;
 
-      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type);
+	// For chained-call resolution (path is only the final method name).
+      const pform_scoped_name_t& peek_path(void) const { return path_; }
+      const PExpr* peek_chain_prefix(void) const { return chain_prefix_; }
 
-      virtual bool has_aa_term(Design*des, NetScope*scope) const;
+      virtual void dump(std::ostream &) const override;
+
+      virtual void declare_implicit_nets(LexicalScope*scope, NetNet::Type type) override;
+
+      virtual bool has_aa_term(Design*des, NetScope*scope) const override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     unsigned expr_wid, unsigned flags) const;
+				     unsigned expr_wid, unsigned flags) const override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
     private:
-      PPackage*package_;
+      pform_scoped_name_t path_;
-      pform_name_t path_;
+      std::vector<named_pexpr_t> parms_;
-      std::vector<PExpr *> parms_;
+	// If non-null, this call is prefix().tail_name(...) (SV method chain).
+      PExpr* chain_prefix_ = nullptr;
 
         // For system functions.
       bool is_overridden_;
@@ -928,14 +964,11 @@ class PECallFunction : public PExpr {
       NetExpr* elaborate_expr_(Design *des, NetScope *scope,
 			       unsigned flags) const;
 
-      NetExpr*elaborate_expr_pkg_(Design*des, NetScope*scope,
-				  unsigned flags)const;
-
       NetExpr* elaborate_expr_method_(Design*des, NetScope*scope,
 				      symbol_search_results&search_results)
 				      const;
-      NetExpr* elaborate_expr_method_par_(Design*des, NetScope*scope,
+      NetExpr* elaborate_expr_method_par_(Design*des, const NetScope*scope,
-					  symbol_search_results&search_results)
+					  const symbol_search_results&search_results)
 					  const;
 
 
@@ -947,16 +980,35 @@ class PECallFunction : public PExpr {
       unsigned test_width_sfunc_(Design*des, NetScope*scope,
 			         width_mode_t&mode);
       unsigned test_width_method_(Design*des, NetScope*scope,
-				  symbol_search_results&search_results,
+				  const symbol_search_results&search_results,
 				  width_mode_t&mode);
 
       NetExpr*elaborate_base_(Design*des, NetScope*scope, NetScope*dscope,
 			      unsigned flags) const;
 
       unsigned elaborate_arguments_(Design*des, NetScope*scope,
-				    NetFuncDef*def, bool need_const,
+                                    const NetFuncDef*def, bool need_const,
-				    std::vector<NetExpr*>&parms,
+                                    std::vector<NetExpr*>&parms,
-				    unsigned parm_off) const;
+                                    unsigned parm_off,
+                                    const std::vector<named_pexpr_t>*src_parms = nullptr) const;
+
+      NetExpr* elaborate_class_method_net_(Design*des, NetScope*scope,
+					   NetNet*net, const netclass_t*class_type,
+					   perm_string method_name,
+					   const std::vector<named_pexpr_t>*src_parms) const;
+
+      NetExpr* elaborate_class_method_net_this_(Design*des, NetScope*scope,
+						NetExpr* this_expr,
+						const netclass_t*class_type,
+						perm_string method_name,
+						const std::vector<named_pexpr_t>*src_parms) const;
+
+      NetExpr* elaborate_expr_method_chained_(Design*des, NetScope*scope,
+					     symbol_search_results&search_results) const;
+
+      NetExpr* elaborate_expr_chain_(Design*des, NetScope*scope, unsigned flags) const;
+
+      unsigned test_width_chain_(Design*des, NetScope*scope, width_mode_t&mode);
 };
 
 /*
@@ -966,18 +1018,18 @@ class PECastSize  : public PExpr {
 
     public:
       explicit PECastSize(PExpr*size, PExpr*base);
-      ~PECastSize();
+      ~PECastSize() override;
 
-      void dump(std::ostream &out) const;
+      void dump(std::ostream &out) const override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 
-      virtual bool has_aa_term(Design *des, NetScope *scope) const;
+      virtual bool has_aa_term(Design *des, NetScope *scope) const override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
     private:
       PExpr* size_;
@@ -991,20 +1043,20 @@ class PECastType  : public PExpr {
 
     public:
       explicit PECastType(data_type_t*target, PExpr*base);
-      ~PECastType();
+      ~PECastType() override;
 
-      void dump(std::ostream &out) const;
+      void dump(std::ostream &out) const override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     ivl_type_t type, unsigned flags) const;
+				     ivl_type_t type, unsigned flags) const override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     unsigned expr_wid, unsigned flags) const;
+				     unsigned expr_wid, unsigned flags) const override;
 
-      virtual bool has_aa_term(Design *des, NetScope *scope) const;
+      virtual bool has_aa_term(Design *des, NetScope *scope) const override;
 
       virtual unsigned test_width(Design*des, NetScope*scope,
-				  width_mode_t&mode);
+				  width_mode_t&mode) override;
 
     private:
       data_type_t* target_;
@@ -1019,16 +1071,16 @@ class PECastSign : public PExpr {
 
     public:
       explicit PECastSign(bool signed_flag, PExpr *base);
-      ~PECastSign() = default;
+      ~PECastSign() override = default;
 
-      void dump(std::ostream &out) const;
+      void dump(std::ostream &out) const override;
 
       NetExpr* elaborate_expr(Design *des, NetScope *scope,
-			      unsigned expr_wid, unsigned flags) const;
+			      unsigned expr_wid, unsigned flags) const override;
 
-      virtual bool has_aa_term(Design *des, NetScope *scope) const;
+      virtual bool has_aa_term(Design *des, NetScope *scope) const override;
 
-      unsigned test_width(Design *des, NetScope *scope, width_mode_t &mode);
+      unsigned test_width(Design *des, NetScope *scope, width_mode_t &mode) override;
 
     private:
       std::unique_ptr<PExpr> base_;
@@ -1042,11 +1094,11 @@ class PEVoid : public PExpr {
 
     public:
       explicit PEVoid();
-      ~PEVoid();
+      ~PEVoid() override;
 
       virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
 				     unsigned expr_wid,
-                                     unsigned flags) const;
+                                     unsigned flags) const override;
 };
 
 #endif /* IVL_PExpr_H */

PFunction.cc

@@ -20,7 +20,6 @@
 # include "config.h"
 # include "PTask.h"
 # include "Statement.h"
-# include <cassert>
 # include "ivl_assert.h"
 
 using namespace std;
@@ -38,8 +37,8 @@ PFunction::~PFunction()
 
 void PFunction::set_statement(Statement*s)
 {
-      assert(s != 0);
+      ivl_assert(*this, s != 0);
-      assert(statement_ == 0);
+      ivl_assert(*this, statement_ == 0);
       statement_ = s;
 }
 

PGate.cc

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1999-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1999-2026 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -22,48 +22,42 @@
 # include  "PGate.h"
 # include  "PExpr.h"
 # include  "verinum.h"
-# include  <cassert>
+# include  "ivl_assert.h"
 
 using namespace std;
 
 void PGate::set_pins_(list<PExpr*>*pins)
 {
-      assert(pins);
+      ivl_assert(*this, pins);
-      assert(pins->size() == pins_.size());
+      ivl_assert(*this, pins->size() == pins_.size());
 
       for (size_t idx = 0 ; idx < pins_.size() ; idx += 1) {
 	    pins_[idx] = pins->front();
 	    pins->pop_front();
       }
 
-      assert(pins->empty());
+      ivl_assert(*this, pins->empty());
       delete pins;
 }
 
 PGate::PGate(perm_string name, list<PExpr*>*pins, const list<PExpr*>*del)
-: name_(name), pins_(pins? pins->size() : 0), ranges_(0)
+: name_(name), pins_(pins? pins->size() : 0), ranges_(nullptr)
 {
       if (pins) set_pins_(pins);
       if (del) delay_.set_delays(del);
-      str0_ = IVL_DR_STRONG;
-      str1_ = IVL_DR_STRONG;
 }
 
 PGate::PGate(perm_string name, list<PExpr*>*pins, PExpr*del)
-: name_(name), pins_(pins? pins->size() : 0), ranges_(0)
+: name_(name), pins_(pins? pins->size() : 0), ranges_(nullptr)
 {
       if (pins) set_pins_(pins);
       if (del) delay_.set_delay(del);
-      str0_ = IVL_DR_STRONG;
-      str1_ = IVL_DR_STRONG;
 }
 
 PGate::PGate(perm_string name, list<PExpr*>*pins)
-: name_(name), pins_(pins? pins->size() : 0), ranges_(0)
+: name_(name), pins_(pins? pins->size() : 0), ranges_(nullptr)
 {
       if (pins) set_pins_(pins);
-      str0_ = IVL_DR_STRONG;
-      str1_ = IVL_DR_STRONG;
 }
 
 PGate::~PGate()
@@ -72,28 +66,18 @@ PGate::~PGate()
 
 void PGate::set_ranges(list<pform_range_t>*ranges)
 {
-      assert(ranges_ == 0);
+      ivl_assert(*this, ranges_ == 0);
       ranges_ = ranges;
 }
 
-ivl_drive_t PGate::strength0() const
+drive_strength_t PGate::strength() const
 {
-      return str0_;
+      return strength_;
 }
 
-void PGate::strength0(ivl_drive_t s)
+void PGate::strength(const drive_strength_t &str)
 {
-      str0_ = s;
+      strength_ = str;
-}
-
-ivl_drive_t PGate::strength1() const
-{
-      return str1_;
-}
-
-void PGate::strength1(ivl_drive_t s)
-{
-      str1_ = s;
 }
 
 void PGate::elaborate_scope(Design*, NetScope*) const
@@ -109,15 +93,10 @@ void PGate::elaborate_scope(Design*, NetScope*) const
  * numbers of expressions.
  */
 
-void PGate::eval_delays(Design*des, NetScope*scope,
+void PGate::eval_delays(Design*des, NetScope*scope, delay_exprs_t &delays,
-			NetExpr*&rise_expr,
-			NetExpr*&fall_expr,
-			NetExpr*&decay_expr,
 			bool as_net_flag) const
 {
-      delay_.eval_delays(des, scope,
+      delay_.eval_delays(des, scope, delays, as_net_flag);
-			 rise_expr, fall_expr, decay_expr,
-			 as_net_flag);
 }
 
 unsigned PGate::delay_count() const
@@ -133,13 +112,13 @@ PNamedItem::SymbolType PGate::symbol_type() const
 PGAssign::PGAssign(list<PExpr*>*pins)
 : PGate(perm_string(), pins)
 {
-      assert(pin_count() == 2);
+      ivl_assert(*this, pin_count() == 2);
 }
 
 PGAssign::PGAssign(list<PExpr*>*pins, list<PExpr*>*dels)
 : PGate(perm_string(), pins, dels)
 {
-      assert(pin_count() == 2);
+      ivl_assert(*this, pin_count() == 2);
 }
 
 PGAssign::~PGAssign()
@@ -148,7 +127,7 @@ PGAssign::~PGAssign()
 
 PGBuiltin::PGBuiltin(Type t, perm_string name,
 		     list<PExpr*>*pins,
-		     list<PExpr*>*del)
+		     const list<PExpr*>*del)
 : PGate(name, pins, del), type_(t)
 {
 }
@@ -270,7 +249,7 @@ PGModule::PGModule(perm_string type, perm_string name, list<PExpr*>*pins)
 }
 
 PGModule::PGModule(perm_string type, perm_string name,
-		   named<PExpr*>*pins, unsigned npins)
+		   named_pexpr_t *pins, unsigned npins)
 : PGate(name, 0), bound_type_(0), type_(type), overrides_(0), pins_(pins),
   npins_(npins), parms_(0), nparms_(0)
 {
@@ -288,14 +267,14 @@ PGModule::~PGModule()
 
 void PGModule::set_parameters(list<PExpr*>*o)
 {
-      assert(overrides_ == 0);
+      ivl_assert(*this, overrides_ == 0);
       overrides_ = o;
 }
 
-void PGModule::set_parameters(named<PExpr*>*pa, unsigned npa)
+void PGModule::set_parameters(named_pexpr_t *pa, unsigned npa)
 {
-      assert(parms_ == 0);
+      ivl_assert(*this, parms_ == 0);
-      assert(overrides_ == 0);
+      ivl_assert(*this, overrides_ == 0);
       parms_ = pa;
       nparms_ = npa;
 }

PGate.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PGate_H
 #define IVL_PGate_H
 /*
- * Copyright (c) 1998-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1998-2026 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -31,6 +31,8 @@
 class PExpr;
 class PUdp;
 class Module;
+struct delay_exprs_t;
+struct drive_strength_t;
 
 /*
  * A PGate represents a Verilog gate. The gate has a name and other
@@ -57,7 +59,7 @@ class PGate : public PNamedItem {
 
       explicit PGate(perm_string name, std::list<PExpr*>*pins);
 
-      virtual ~PGate();
+      virtual ~PGate() override;
 
       void set_ranges(std::list<pform_range_t>*ranges);
       bool is_array() const { return ranges_ != 0; }
@@ -66,10 +68,7 @@ class PGate : public PNamedItem {
 
 	// This evaluates the delays as far as possible, but returns
 	// an expression, and do not signal errors.
-      void eval_delays(Design*des, NetScope*scope,
+      void eval_delays(Design*des, NetScope*scope, delay_exprs_t &delays,
-		       NetExpr*&rise_time,
-		       NetExpr*&fall_time,
-		       NetExpr*&decay_time,
 		       bool as_net_flag =false) const;
 
       unsigned delay_count() const;
@@ -77,11 +76,9 @@ class PGate : public PNamedItem {
       unsigned pin_count() const { return pins_.size(); }
       PExpr*pin(unsigned idx) const { return pins_[idx]; }
 
-      ivl_drive_t strength0() const;
+      drive_strength_t strength() const;
-      ivl_drive_t strength1() const;
 
-      void strength0(ivl_drive_t);
+      void strength(const drive_strength_t &str);
-      void strength1(ivl_drive_t);
 
       std::map<perm_string,PExpr*> attributes;
 
@@ -90,7 +87,7 @@ class PGate : public PNamedItem {
       virtual void elaborate_scope(Design*des, NetScope*sc) const;
       virtual bool elaborate_sig(Design*des, NetScope*scope) const;
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 
     protected:
       const std::vector<PExpr*>& get_pins() const { return pins_; }
@@ -109,7 +106,7 @@ class PGate : public PNamedItem {
 
       std::list<pform_range_t>*ranges_;
 
-      ivl_drive_t str0_, str1_;
+      drive_strength_t strength_;
 
       void set_pins_(std::list<PExpr*>*pins);
 
@@ -127,14 +124,15 @@ class PGAssign  : public PGate {
     public:
       explicit PGAssign(std::list<PExpr*>*pins);
       explicit PGAssign(std::list<PExpr*>*pins, std::list<PExpr*>*dels);
-      ~PGAssign();
+      ~PGAssign() override;
 
-      void dump(std::ostream&out, unsigned ind =4) const;
+      void dump(std::ostream&out, unsigned ind =4) const override;
-      virtual void elaborate(Design*des, NetScope*scope) const;
+      virtual void elaborate(Design*des, NetScope*scope) const override;
-      virtual bool elaborate_sig(Design*des, NetScope*scope) const;
 
     private:
-      void elaborate_unpacked_array_(Design*des, NetScope*scope, NetNet*lval) const;
+      void elaborate_unpacked_array_(Design*des, NetScope*scope, NetNet*lval,
+				     const drive_strength_t &drive,
+				     const delay_exprs_t &delays) const;
 };
 
 
@@ -159,18 +157,17 @@ class PGBuiltin  : public PGate {
     public:
       explicit PGBuiltin(Type t, perm_string name,
 			 std::list<PExpr*>*pins,
-			 std::list<PExpr*>*del);
+			 const std::list<PExpr*>*del);
       explicit PGBuiltin(Type t, perm_string name,
 			 std::list<PExpr*>*pins,
 			 PExpr*del);
-      ~PGBuiltin();
+      ~PGBuiltin() override;
 
       Type type() const { return type_; }
       const char * gate_name() const;
 
-      virtual void dump(std::ostream&out, unsigned ind =4) const;
+      virtual void dump(std::ostream&out, unsigned ind =4) const override;
-      virtual void elaborate(Design*, NetScope*scope) const;
+      virtual void elaborate(Design*, NetScope*scope) const override;
-      virtual bool elaborate_sig(Design*des, NetScope*scope) const;
 
     private:
       void calculate_gate_and_lval_count_(unsigned&gate_count,
@@ -204,25 +201,23 @@ class PGModule  : public PGate {
 	// If the binding of ports is by name, this constructor takes
 	// the bindings and stores them for later elaboration.
       explicit PGModule(perm_string type, perm_string name,
-			named<PExpr*>*pins, unsigned npins);
+			named_pexpr_t *pins, unsigned npins);
 
 	// If the module type is known by design, then use this
 	// constructor.
       explicit PGModule(Module*type, perm_string name);
 
-      ~PGModule();
+      ~PGModule() override;
 
 	// Parameter overrides can come as an ordered list, or a set
 	// of named expressions.
       void set_parameters(std::list<PExpr*>*o);
-      void set_parameters(named<PExpr*>*pa, unsigned npa);
+      void set_parameters(named_pexpr_t *pa, unsigned npa);
 
-      std::map<perm_string,PExpr*> attributes;
+      virtual void dump(std::ostream&out, unsigned ind =4) const override;
-
+      virtual void elaborate(Design*, NetScope*scope) const override;
-      virtual void dump(std::ostream&out, unsigned ind =4) const;
+      virtual void elaborate_scope(Design*des, NetScope*sc) const override;
-      virtual void elaborate(Design*, NetScope*scope) const;
+      virtual bool elaborate_sig(Design*des, NetScope*scope) const override;
-      virtual void elaborate_scope(Design*des, NetScope*sc) const;
-      virtual bool elaborate_sig(Design*des, NetScope*scope) const;
 
 	// This returns the module name of this module. It is a
 	// permallocated string.
@@ -232,19 +227,28 @@ class PGModule  : public PGate {
       Module*bound_type_;
       perm_string type_;
       std::list<PExpr*>*overrides_;
-      named<PExpr*>*pins_;
+      named_pexpr_t *pins_;
       unsigned npins_;
 
 	// These members support parameter override by name
-      named<PExpr*>*parms_;
+      named_pexpr_t *parms_;
       unsigned nparms_;
 
       friend class delayed_elaborate_scope_mod_instances;
-      void elaborate_mod_(Design*, Module*mod, NetScope*scope) const;
+      void elaborate_mod_(Design*, const Module*mod, NetScope*scope) const;
       void elaborate_udp_(Design*, PUdp  *udp, NetScope*scope) const;
       void elaborate_scope_mod_(Design*des, Module*mod, NetScope*sc) const;
       void elaborate_scope_mod_instances_(Design*des, Module*mod, NetScope*sc) const;
-      bool elaborate_sig_mod_(Design*des, NetScope*scope, Module*mod) const;
+      bool elaborate_sig_mod_(Design*des, NetScope*scope, const Module*mod) const;
+      bool bind_interface_ports_(Design*des, const Module*mod,
+				 NetScope*parent_scope, NetScope*instance_scope,
+				 const std::vector<PExpr*>&pins,
+				 const std::vector<bool>&pins_fromwc) const;
+      bool match_module_ports_(Design*des, const Module*mod,
+			       NetScope*scope,
+			       std::vector<PExpr*>&pins,
+			       std::vector<bool>&pins_fromwc,
+			       std::vector<bool>&pins_is_explicitly_not_connected) const;
 	// Not currently used.
 #if 0
       bool elaborate_sig_udp_(Design*des, NetScope*scope, PUdp*udp) const;

PGenerate.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PGenerate_H
 #define IVL_PGenerate_H
 /*
- * Copyright (c) 2006-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 2006-2025 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -26,10 +26,12 @@
 # include  <list>
 # include  <map>
 # include  <valarray>
+# include  <vector>
 # include  "pform_types.h"
 
 class Design;
 class NetScope;
+class PClass;
 class PExpr;
 class PFunction;
 class PProcess;
@@ -54,7 +56,7 @@ class PGenerate : public PNamedItem, public LexicalScope {
 
     public:
       explicit PGenerate(LexicalScope*parent, unsigned id_number);
-      ~PGenerate();
+      ~PGenerate() override;
 
 	// Generate schemes have an ID number, for when the scope is
 	// implicit.
@@ -92,9 +94,11 @@ class PGenerate : public PNamedItem, public LexicalScope {
       std::list<PGate*> gates;
       void add_gate(PGate*);
 
-	// Tasks instantiated within this scheme.
+	// Definitions instantiated within this scheme.
       std::map<perm_string,PTask*> tasks;
       std::map<perm_string,PFunction*>funcs;
+      std::map<perm_string,PClass*> classes;
+      std::vector<PClass*> classes_lexical;
 
 	// Generate schemes can contain further generate schemes.
       std::list<PGenerate*> generate_schemes;
@@ -112,7 +116,7 @@ class PGenerate : public PNamedItem, public LexicalScope {
 
       void dump(std::ostream&out, unsigned indent) const;
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 
     private:
       void check_for_valid_genvar_value_(long value);

PModport.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PModport_H
 #define IVL_PModport_H
 /*
- * Copyright (c) 2015-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 2015-2025 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -34,14 +34,14 @@ class PModport : public PNamedItem {
 	// The name is a perm-allocated string. It is the simple name
 	// of the modport, without any scope.
       explicit PModport(perm_string name);
-      ~PModport();
+      ~PModport() override;
 
       perm_string name() const { return name_; }
 
       typedef std::pair <NetNet::PortType,PExpr*> simple_port_t;
       std::map<perm_string,simple_port_t> simple_ports;
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 
     private:
       perm_string name_;

PNamedItem.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PNamedItem_H
 #define IVL_PNamedItem_H
 /*
- * Copyright (c) 2019 Martin Whitaker (icarus@martin-whitaker.me.uk)
+ * Copyright (c) 2019-2025 Martin Whitaker (icarus@martin-whitaker.me.uk)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -34,7 +34,7 @@ class PNamedItem : virtual public LineInfo {
                         INSTANCE };
 
       explicit PNamedItem();
-      virtual ~PNamedItem();
+      virtual ~PNamedItem() override;
 
       virtual SymbolType symbol_type() const;
 };
@@ -49,9 +49,9 @@ class PGenvar : public PNamedItem {
 
     public:
       explicit PGenvar();
-      virtual ~PGenvar();
+      virtual ~PGenvar() override;
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 };
 
 #endif /* IVL_PNamedItem_H */

PPackage.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PPackage_H
 #define IVL_PPackage_H
 /*
- * Copyright (c) 2012-2014 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 2012-2025 Stephen Williams (steve@icarus.com)
  * Copyright CERN 2013 / Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
@@ -24,6 +24,7 @@
 # include  "LineInfo.h"
 # include  "StringHeap.h"
 # include  <iostream>
+# include  <vector>
 
 /*
  * SystemVerilog supports class declarations with their own lexical
@@ -35,13 +36,20 @@ class PPackage : public PScopeExtra, public LineInfo {
 
     public:
       explicit PPackage (perm_string name, LexicalScope*parent);
-      ~PPackage();
+      ~PPackage() override;
 
       bool elaborate_scope(Design*des, NetScope*scope);
       bool elaborate_sig(Design*des, NetScope*scope) const;
       bool elaborate(Design*des, NetScope*scope) const;
 
       void pform_dump(std::ostream&out) const;
+
+      struct export_t {
+	    PPackage *pkg;
+	    perm_string name;
+      };
+
+      std::vector<export_t> exports;
 };
 
 #endif /* IVL_PPackage_H */

PScope.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PScope_H
 #define IVL_PScope_H
 /*
- * Copyright (c) 2008-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 2008-2026 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -25,6 +25,7 @@
 # include  "ivl_target.h"
 # include  <map>
 # include  <set>
+# include  <unordered_set>
 # include  <vector>
 
 class PEvent;
@@ -67,9 +68,14 @@ class LexicalScope {
 	// Symbols that are defined or declared in this scope.
       std::map<perm_string,PNamedItem*>local_symbols;
 
-	// Symbols that are explicitly imported. Bind the imported name
+	// Symbols that are explicitly imported. This contains the package where
-	// to the package from which the name is imported.
+	// the symbol has been decelared. When using exports, this might not be
+	// the same as the package where it has been imported from.
       std::map<perm_string,PPackage*>explicit_imports;
+        // Symbols that are explicitly imported. This contains the set of
+	// packages from which the symbol has been imported. When using exports
+	// the same identifier can be imported via multiple packages.
+      std::map<perm_string,std::unordered_set<PPackage*>> explicit_imports_from;
 
 	// Packages that are wildcard imported. When identifiers from
 	// these packages are referenced, they will be added to the
@@ -115,6 +121,10 @@ class LexicalScope {
 	    bool overridable;
 	      // Whether the parameter is a type parameter
 	    bool type_flag = false;
+	      // Type restriction for a type parameter
+	    type_restrict_t type_restrict;
+	      // The lexical position of the declaration
+	    unsigned lexical_pos = 0;
 
 	    SymbolType symbol_type() const;
       };
@@ -190,7 +200,7 @@ class PScope : public LexicalScope {
 	// modules. Scopes for tasks and functions point to their
 	// containing module.
       explicit PScope(perm_string name, LexicalScope*parent =0);
-      virtual ~PScope();
+      virtual ~PScope() override;
 
       perm_string pscope_name() const { return name_; }
 
@@ -225,7 +235,7 @@ class PScopeExtra : public PScope {
 
     public:
       explicit PScopeExtra(perm_string, LexicalScope*parent =0);
-      ~PScopeExtra();
+      ~PScopeExtra() override;
 
 	/* Task definitions within this module */
       std::map<perm_string,PTask*> tasks;

PSpec.cc

@@ -19,10 +19,11 @@
 
 # include  "PSpec.h"
 
-PSpecPath::PSpecPath(unsigned src_cnt, unsigned dst_cnt, char polarity,
+PSpecPath::PSpecPath(const std::list<perm_string> &src_list,
-                     bool full_flag)
+		     const std::list<perm_string> &dst_list,
+		     char polarity, bool full_flag)
 : conditional(false), condition(0), edge(0),
-  src(src_cnt), dst(dst_cnt),
+  src(src_list.begin(), src_list.end()), dst(dst_list.begin(), dst_list.end()),
   data_source_expression(0)
 {
       full_flag_ = full_flag;

PSpec.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PSpec_H
 #define IVL_PSpec_H
 /*
- * Copyright (c) 2006-2014 Stephen Williams <steve@icarus.com>
+ * Copyright (c) 2006-2025 Stephen Williams <steve@icarus.com>
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -22,6 +22,7 @@
 # include  "LineInfo.h"
 # include  "StringHeap.h"
 # include  <vector>
+# include  <list>
 
 class PExpr;
 
@@ -56,9 +57,10 @@ class PExpr;
 class PSpecPath  : public LineInfo {
 
     public:
-      PSpecPath(unsigned src_cnt, unsigned dst_cnt, char polarity,
+      PSpecPath(const std::list<perm_string> &src_list,
-                bool full_flag);
+	        const std::list<perm_string> &dst_list,
-      ~PSpecPath();
+		char polarity, bool full_flag);
+      ~PSpecPath() override;
 
       void elaborate(class Design*des, class NetScope*scope) const;
 

PTask.cc

@@ -18,8 +18,8 @@
  */
 
 # include "config.h"
-# include  "PTask.h"
+# include "PTask.h"
-# include  <cassert>
+# include "ivl_assert.h"
 
 using namespace std;
 
@@ -39,13 +39,13 @@ bool PTaskFunc::var_init_needs_explicit_lifetime() const
 
 void PTaskFunc::set_ports(vector<pform_tf_port_t>*p)
 {
-      assert(ports_ == 0);
+      ivl_assert(*this, ports_ == 0);
       ports_ = p;
 }
 
 void PTaskFunc::set_this(class_type_t*type, PWire*this_wire)
 {
-      assert(this_type_ == 0);
+      ivl_assert(*this, this_type_ == 0);
       this_type_ = type;
 
 	// Push a synthesis argument that is the "this" value.
@@ -72,7 +72,7 @@ PTask::~PTask()
 
 void PTask::set_statement(Statement*s)
 {
-      assert(statement_ == 0);
+      ivl_assert(*this, statement_ == 0);
       statement_ = s;
 }
 

PTask.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PTask_H
 #define IVL_PTask_H
 /*
- * Copyright (c) 1999-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1999-2025 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -39,9 +39,9 @@ class PTaskFunc : public PScope, public PNamedItem {
 
     public:
       PTaskFunc(perm_string name, LexicalScope*parent);
-      ~PTaskFunc();
+      ~PTaskFunc() override;
 
-      bool var_init_needs_explicit_lifetime() const;
+      bool var_init_needs_explicit_lifetime() const override;
 
       void set_ports(std::vector<pform_tf_port_t>*p);
 
@@ -63,7 +63,8 @@ class PTaskFunc : public PScope, public PNamedItem {
 	// default value expressions, if any.
       void elaborate_sig_ports_(Design*des, NetScope*scope,
 				std::vector<NetNet*>&ports,
-				std::vector<NetExpr*>&pdefs) const;
+				std::vector<NetExpr*> &pdefs,
+				std::vector<perm_string> &port_names) const;
 
       void dump_ports_(std::ostream&out, unsigned ind) const;
 
@@ -79,7 +80,7 @@ class PTask  : public PTaskFunc {
 
     public:
       explicit PTask(perm_string name, LexicalScope*parent, bool is_auto);
-      ~PTask();
+      ~PTask() override;
 
       void set_statement(Statement *s);
 
@@ -90,16 +91,16 @@ class PTask  : public PTaskFunc {
       void elaborate_scope(Design*des, NetScope*scope) const;
 
 	// Bind the ports to the regs that are the ports.
-      void elaborate_sig(Design*des, NetScope*scope) const;
+      void elaborate_sig(Design*des, NetScope*scope) const override;
 
 	// Elaborate the statement to finish off the task definition.
-      void elaborate(Design*des, NetScope*scope) const;
+      void elaborate(Design*des, NetScope*scope) const override;
 
       bool is_auto() const { return is_auto_; };
 
-      void dump(std::ostream&, unsigned) const;
+      void dump(std::ostream&, unsigned) const override;
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 
     private:
       Statement*statement_;
@@ -121,7 +122,7 @@ class PFunction : public PTaskFunc {
 
     public:
       explicit PFunction(perm_string name, LexicalScope*parent, bool is_auto);
-      ~PFunction();
+      ~PFunction() override;
 
       void set_statement(Statement *s);
       void set_return(data_type_t*t);
@@ -141,16 +142,16 @@ class PFunction : public PTaskFunc {
       void elaborate_scope(Design*des, NetScope*scope) const;
 
 	/* elaborate the ports and return value. */
-      void elaborate_sig(Design *des, NetScope*) const;
+      void elaborate_sig(Design *des, NetScope*) const override;
 
 	/* Elaborate the behavioral statement. */
-      void elaborate(Design *des, NetScope*) const;
+      void elaborate(Design *des, NetScope*) const override;
 
       bool is_auto() const { return is_auto_; };
 
-      void dump(std::ostream&, unsigned) const;
+      void dump(std::ostream&, unsigned) const override;
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 
     private:
       data_type_t* return_type_;
@@ -173,12 +174,12 @@ class PLet : public PTaskFunc {
 // FIXME: Should the port list be a vector. Check once implemented completely
       explicit PLet(perm_string name, LexicalScope*parent,
                     std::list<let_port_t*>*ports, PExpr*expr);
-      ~PLet();
+      ~PLet() override;
 
-      void elaborate_sig(Design*des, NetScope*scope) const { (void)des; (void)scope; }
+      void elaborate_sig(Design*des, NetScope*scope) const override { (void)des; (void)scope; }
-      void elaborate(Design*des, NetScope*scope) const { (void)des; (void)scope; }
+      void elaborate(Design*des, NetScope*scope) const override { (void)des; (void)scope; }
 
-      void dump(std::ostream&, unsigned) const;
+      void dump(std::ostream&, unsigned) const override;
 
     private:
       std::list<let_port_t*>*ports_;

PTimingCheck.cc

@@ -0,0 +1,72 @@
+/*
+ * Copyright (c) 2006-2023 Stephen Williams <steve@icarus.com>
+ *
+ *    This source code is free software; you can redistribute it
+ *    and/or modify it in source code form under the terms of the GNU
+ *    General Public License as published by the Free Software
+ *    Foundation; either version 2 of the License, or (at your option)
+ *    any later version.
+ *
+ *    This program is distributed in the hope that it will be useful,
+ *    but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *    GNU General Public License for more details.
+ *
+ *    You should have received a copy of the GNU General Public License
+ *    along with this program; if not, write to the Free Software
+ *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
+
+# include  "PTimingCheck.h"
+
+PRecRem::PRecRem(event_t* reference_event,
+      event_t* data_event,
+      PExpr* setup_limit,
+      PExpr* hold_limit,
+      pform_name_t* notifier,
+      PExpr* timestamp_cond,
+      PExpr* timecheck_cond,
+      pform_name_t* delayed_reference,
+      pform_name_t* delayed_data)
+      :
+      reference_event_ (reference_event),
+      data_event_ (data_event),
+      setup_limit_ (setup_limit),
+      hold_limit_ (hold_limit),
+      notifier_ (notifier),
+      timestamp_cond_ (timestamp_cond),
+      timecheck_cond_ (timecheck_cond),
+      delayed_reference_ (delayed_reference),
+      delayed_data_ (delayed_data)
+{
+}
+
+PRecRem::~PRecRem()
+{
+}
+
+PSetupHold::PSetupHold(event_t* reference_event,
+      event_t* data_event,
+      PExpr* setup_limit,
+      PExpr* hold_limit,
+      pform_name_t* notifier,
+      PExpr* timestamp_cond,
+      PExpr* timecheck_cond,
+      pform_name_t* delayed_reference,
+      pform_name_t* delayed_data)
+      :
+      reference_event_ (reference_event),
+      data_event_ (data_event),
+      setup_limit_ (setup_limit),
+      hold_limit_ (hold_limit),
+      notifier_ (notifier),
+      timestamp_cond_ (timestamp_cond),
+      timecheck_cond_ (timecheck_cond),
+      delayed_reference_ (delayed_reference),
+      delayed_data_ (delayed_data)
+{
+}
+
+PSetupHold::~PSetupHold()
+{
+}

PTimingCheck.h

@@ -0,0 +1,139 @@
+#ifndef IVL_PTimingCheck_H
+#define IVL_PTimingCheck_H
+/*
+ * Copyright (c) 2006-2025 Stephen Williams <steve@icarus.com>
+ *
+ *    This source code is free software; you can redistribute it
+ *    and/or modify it in source code form under the terms of the GNU
+ *    General Public License as published by the Free Software
+ *    Foundation; either version 2 of the License, or (at your option)
+ *    any later version.
+ *
+ *    This program is distributed in the hope that it will be useful,
+ *    but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *    GNU General Public License for more details.
+ *
+ *    You should have received a copy of the GNU General Public License
+ *    along with this program; if not, write to the Free Software
+ *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
+
+# include  "LineInfo.h"
+# include  "PExpr.h"
+# include  "pform_types.h"
+# include  <memory>
+
+/*
+* The PTimingCheck is the base class for all timing checks
+*/
+class PTimingCheck  : public LineInfo {
+
+    public:
+      enum EdgeType {EDGE_01, EDGE_0X, EDGE_10, EDGE_1X, EDGE_X0, EDGE_X1};
+
+      struct event_t {
+        pform_name_t name;
+        bool posedge;
+        bool negedge;
+        std::vector<EdgeType> edges;
+        std::unique_ptr<PExpr> condition;
+      };
+
+      // This struct is used to parse the optional arguments
+      struct optional_args_t {
+        pform_name_t* notifier          = nullptr;
+        PExpr* timestamp_cond    = nullptr;
+        PExpr* timecheck_cond    = nullptr;
+        pform_name_t* delayed_reference = nullptr;
+        pform_name_t* delayed_data      = nullptr;
+        PExpr* event_based_flag         = nullptr;
+        PExpr* remain_active_flag       = nullptr;
+      };
+
+      PTimingCheck() { }
+      virtual ~PTimingCheck() override { }
+
+      virtual void elaborate(class Design*des, class NetScope*scope) const = 0;
+
+      virtual void dump(std::ostream&out, unsigned ind) const = 0;
+};
+
+/*
+* The PRecRem is the parse of a $recrem timing check
+*/
+class PRecRem : public PTimingCheck {
+
+    public:
+
+      PRecRem(event_t* reference_event,
+                    event_t* data_event,
+                    PExpr* setup_limit,
+                    PExpr* hold_limit,
+                    pform_name_t* notifier,
+                    PExpr* timestamp_cond,
+                    PExpr* timecheck_cond,
+                    pform_name_t* delayed_reference,
+                    pform_name_t* delayed_data);
+
+      ~PRecRem() override;
+
+      void elaborate(class Design*des, class NetScope*scope) const override;
+
+      void dump(std::ostream&out, unsigned ind) const override;
+
+    private:
+      std::unique_ptr<event_t> reference_event_;
+      std::unique_ptr<event_t> data_event_;
+
+      std::unique_ptr<PExpr> setup_limit_;
+      std::unique_ptr<PExpr> hold_limit_;
+
+      std::unique_ptr<pform_name_t> notifier_;
+
+      std::unique_ptr<PExpr> timestamp_cond_;
+      std::unique_ptr<PExpr> timecheck_cond_;
+
+      std::unique_ptr<pform_name_t> delayed_reference_;
+      std::unique_ptr<pform_name_t> delayed_data_;
+};
+
+/*
+* The PSetupHold is the parse of a $setuphold timing check
+*/
+class PSetupHold : public PTimingCheck {
+
+    public:
+      PSetupHold(event_t* reference_event,
+                    event_t* data_event,
+                    PExpr* setup_limit,
+                    PExpr* hold_limit,
+                    pform_name_t* notifier,
+                    PExpr* timestamp_cond,
+                    PExpr* timecheck_cond,
+                    pform_name_t* delayed_reference,
+                    pform_name_t* delayed_data);
+
+      ~PSetupHold() override;
+
+      void elaborate(class Design*des, class NetScope*scope) const override;
+
+      void dump(std::ostream&out, unsigned ind) const override;
+
+    private:
+      std::unique_ptr<event_t> reference_event_;
+      std::unique_ptr<event_t> data_event_;
+
+      std::unique_ptr<PExpr> setup_limit_;
+      std::unique_ptr<PExpr> hold_limit_;
+
+      std::unique_ptr<pform_name_t> notifier_;
+
+      std::unique_ptr<PExpr> timestamp_cond_;
+      std::unique_ptr<PExpr> timecheck_cond_;
+
+      std::unique_ptr<pform_name_t> delayed_reference_;
+      std::unique_ptr<pform_name_t> delayed_data_;
+};
+
+#endif /* IVL_PTimingCheck_H */

PWire.cc

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1999-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1999-2024 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -21,15 +21,15 @@
 # include "ivl_assert.h"
 # include  "PWire.h"
 # include  "PExpr.h"
-# include  <cassert>
 
 using namespace std;
 
 PWire::PWire(perm_string n,
+	     unsigned lp,
 	     NetNet::Type t,
 	     NetNet::PortType pt,
 	     PWSRType rt)
-: name_(n), type_(t), port_type_(pt), signed_(false),
+: name_(n), lexical_pos_(lp), type_(t), port_type_(pt), signed_(false),
   port_set_(false), net_set_(false), is_scalar_(false),
   error_cnt_(0), discipline_(0)
 {
@@ -59,7 +59,7 @@ perm_string PWire::basename() const
 
 bool PWire::set_wire_type(NetNet::Type t)
 {
-      assert(t != NetNet::IMPLICIT);
+      ivl_assert(*this, t != NetNet::IMPLICIT);
 
       switch (type_) {
 	  case NetNet::IMPLICIT:
@@ -90,8 +90,8 @@ NetNet::PortType PWire::get_port_type() const
 
 bool PWire::set_port_type(NetNet::PortType pt)
 {
-      assert(pt != NetNet::NOT_A_PORT);
+      ivl_assert(*this, pt != NetNet::NOT_A_PORT);
-      assert(pt != NetNet::PIMPLICIT);
+      ivl_assert(*this, pt != NetNet::PIMPLICIT);
 
       switch (port_type_) {
 	  case NetNet::PIMPLICIT:
@@ -181,13 +181,13 @@ void PWire::set_data_type(data_type_t*type)
       if (set_data_type_.get() == type)
 	    return;
 
-      assert(!set_data_type_.get());
+      ivl_assert(*this, !set_data_type_.get());
       set_data_type_.reset(type);
 }
 
 void PWire::set_discipline(ivl_discipline_t d)
 {
-      assert(discipline_ == 0);
+      ivl_assert(*this, discipline_ == 0);
       discipline_ = d;
 }
 

PWire.h

@@ -1,7 +1,7 @@
 #ifndef IVL_PWire_H
 #define IVL_PWire_H
 /*
- * Copyright (c) 1998-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1998-2025 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -55,6 +55,7 @@ class PWire : public PNamedItem {
 
     public:
       PWire(perm_string name,
+	    unsigned lexical_pos,
 	    NetNet::Type t,
 	    NetNet::PortType pt,
 	    PWSRType rt = SR_NET);
@@ -62,12 +63,17 @@ class PWire : public PNamedItem {
 	// Return a hierarchical name.
       perm_string basename() const;
 
+      unsigned lexical_pos() const { return lexical_pos_; }
+
       NetNet::Type get_wire_type() const;
       bool set_wire_type(NetNet::Type);
 
       NetNet::PortType get_port_type() const;
       bool set_port_type(NetNet::PortType);
 
+      void set_const(bool is_const) { is_const_ = is_const; };
+      bool get_const() const { return is_const_; };
+
       void set_signed(bool flag);
       bool get_signed() const;
 
@@ -85,9 +91,9 @@ class PWire : public PNamedItem {
 	// Write myself to the specified stream.
       void dump(std::ostream&out, unsigned ind=4) const;
 
-      NetNet* elaborate_sig(Design*, NetScope*scope) const;
+      NetNet* elaborate_sig(Design*, NetScope*scope);
 
-      SymbolType symbol_type() const;
+      SymbolType symbol_type() const override;
 
       bool is_net() const { return net_set_; };
       bool is_port() const { return port_set_; };
@@ -96,10 +102,16 @@ class PWire : public PNamedItem {
 
     private:
       perm_string name_;
+      unsigned lexical_pos_;
       NetNet::Type type_;
       NetNet::PortType port_type_;
       bool signed_;
 
+        // Whether the wire is variable declared with the const keyword.
+      bool is_const_ = false;
+
+      bool is_elaborating_ = false;
+
 	// These members hold expressions for the bit width of the
 	// wire. If they do not exist, the wire is 1 bit wide. If they
 	// do exist, they represent the packed dimensions of the
@@ -128,10 +140,10 @@ class PWire : public PNamedItem {
       PWire& operator= (const PWire&);
 
       ivl_type_t elaborate_type(Design*des, NetScope*scope,
-			        const std::vector<netrange_t>&packed_dimensions) const;
+			        const netranges_t &packed_dimensions) const;
       ivl_type_t elaborate_darray_type(Design*des, NetScope*scope,
 				       const char *darray_type,
-				       const std::vector<netrange_t>&packed_dimensions)
+				       const netranges_t &packed_dimensions)
 				       const;
 };
 

QUICK_START.txt

@@ -1,83 +0,0 @@
-
-* Getting Started with Icarus Verilog
-
-Icarus Verilog is a Verilog compiler. It is suitable for use as a
-simulator, and, to some degree, synthesizer. Icarus Verilog runs under
-Linux and a variety of UNIX systems, as well as Windows as a command
-line tool, so the instructions are generally applicable to all
-environments. Note that this is only a quick start. For more detailed
-documentation, see the manual page for the iverilog command.
-
-
-* Hello, World!
-
-The first thing you want to do as a user is learn how to compile and
-execute even the most trivial design. For the purposes of simulation,
-we use as our example *the* most trivial simulation:
-
-  module main;
-
-  initial
-    begin
-      $display("Hello, World");
-      $finish ;
-    end
-
-  endmodule
-
-By a text editor (or copy hello.vl from the Icarus Verilog examples
-directory) arrange for this program to be in a text file, "hello.vl".
-Next, compile this program with a command like this:
-
-	% iverilog -o hello hello.vl
-
-The results of this compile are placed into the file "hello", as the
-"-o" flag tells the compiler where to place the compiled result. Next,
-execute the compiled program like so:
-
-	% vvp hello
-	Hello, World
-
-And there it is, the program has been executed. So what happened? The
-first step, the "iverilog" command, read and interpreted the source
-file, then generated a compiled result. The compiled form may be
-selected by command line switches, but the default form is the VVP
-format, which is actually run by the "vvp" command.
-
-The "iverilog" and "vvp" commands are the only commands that users
-use to invoke Icarus Verilog. What the compiler actually does is
-controlled by command line switches. In our little example, we asked
-the compiler to compile the source program to the default vvp form,
-which is in turn executed by the vvp program.
-
-
-* Windows Install
-
-The easiest way to install under Windows is to get a precompiled
-installer for the version you wish to install. Icarus Verilog is
-distributed for Windows users as a self-installing .exe. Just execute
-the installer and follow the instructions. During the install, take
-note of the directory where the program is installed: for example,
-C:\iverilog is a good place to install.
-
-Once the binary is installed, you need to add the bin directory to
-your execution path. The executables you need are in C:\iverilog\bin,
-where the "C:\iverilog" part is actually the root of where you
-installed the package. The programs are in the bin subdirectory. Put
-this directory in your PATH environment variable, and the above
-commands become accessible to you at the command line prompt, or even
-in batch files.
-
-
-* Linux Install
-
-Under Linux, the install is even easier. For RedHat and Mandrake based
-systems, there is the appropriate RPM file. Just install the package
-with the "rpm -U <file>" command. Debian users should get Icarus
-Verilog packages from the main Debian software site.
-
-
-* Install From Source
-
-In this case, see README.txt and other documentation that comes with
-the source.

README.md

@@ -1,15 +1,45 @@
 # The ICARUS Verilog Compilation System
 
-Copyright 2000-2019 Stephen Williams
+Copyright 2000-2026 Stephen Williams
 
+<details>
+<summary><h2>Table of Contents</h2></summary>
+
+1. [What is ICARUS Verilog?](#what-is-icarus-verilog)
+2. [Building/Installing Icarus Verilog From Source](#buildinginstalling-icarus-verilog-from-source)
+	- [Compile Time Prerequisites](#compile-time-prerequisites)
+	- [Compilation](#compilation)
+	- [(Optional) Testing](#optional-testing)
+	- [Installation](#installation)
+3. [How Icarus Verilog Works](#how-icarus-verilog-works)
+	- [Preprocessing](#preprocessing)
+	- [Parse](#parse)
+	- [Elaboration](#elaboration)
+	- [Optimization](#optimization)
+	- [Code Generation](#code-generation)
+	- [Attributes](#attributes)
+4.	[Running iverilog](#running-iverilog)
+	- [Examples](#examples)
+5. [Unsupported Constructs](#unsupported-constructs)
+6. [Nonstandard Constructs or Behaviors](#nonstandard-constructs-or-behaviors)
+	- [Builtin system functions](#builtin-system-functions)
+	- [Preprocessing Library Modules](#preprocessing-library-modules)
+	- [Width in %t Time Formats](#width-in-t-time-formats)
+	- [vpiScope iterator on vpiScope objects](#vpiscope-iterator-on-vpiscope-objects)
+	- [Time 0 Race Resolution](#time-0-race-resolution)
+	- [Nets with Types](#nets-with-types)
+7. [Credits](#credits)
+
+</details>
 
 ## What is ICARUS Verilog?
 
-Icarus Verilog is intended to compile ALL of the Verilog HDL as
+Icarus Verilog is intended to compile ALL of the Verilog HDL, as
-described in the IEEE-1364 standard. Of course, it's not quite there
+described in the IEEE 1364 standard. Of course, it's not quite there
-yet. It does currently handle a mix of structural and behavioural
+yet. It also compiles a (slowly growing) subset of the SystemVerilog
-constructs. For a view of the current state of Icarus Verilog, see its
+language, as described in the IEEE 1800 standard. For a view of the
-home page at http://iverilog.icarus.com/.
+current state of Icarus Verilog, see its home page at
+https://steveicarus.github.io/iverilog/.
 
 Icarus Verilog is not aimed at being a simulator in the traditional
 sense, but a compiler that generates code employed by back-end
@@ -18,7 +48,7 @@ tools.
 > For instructions on how to run Icarus Verilog, see the `iverilog` man page.
 
 
-## Building/Installing Icarus Verilog From Source
+## Building/Installing Icarus Verilog from Source
 
 If you are starting from the source, the build process is designed to be
 as simple as practical. Someone basically familiar with the target
@@ -26,10 +56,13 @@ system and C/C++ compilation should be able to build the source
 distribution with little effort. Some actual programming skills are
 not required, but helpful in case of problems.
 
-> If you are building on Windows, see the mingw.txt file.
-
 ### Compile Time Prerequisites
 
+You can use:
+```bash
+apt install -y autoconf gperf make gcc g++ bison flex
+```
+
 You need the following software to compile Icarus Verilog from source
 on a UNIX-like system:
 
@@ -49,7 +82,7 @@ on a UNIX-like system:
   OSX note: bison 2.3 shipped with MacOS including Catalina generates
   broken code, but bison 3+ works. We recommend using the Fink
   project version of bison and flex (finkproject.org), brew version
-  works fine either.
+  works fine too.
 
 - gperf 3.0 or later
   The lexical analyzer doesn't recognize keywords directly,
@@ -77,21 +110,29 @@ on a UNIX-like system:
 
 ### Compilation
 
-Unpack the tar-ball and cd into the `verilog-#########` directory
+<details>
-(presumably, that is how you got to this README) and compile the source
+<summary><h4><a href="https://github.com/steveicarus/iverilog/releases">Compiling From Release</a></h4></summary>
-with the commands:
 
-```
+Unpack the tar-ball, `cd` into the `verilog-#########` directory,
+and compile the source with the commands:
+
+```bash
   ./configure
   make
 ```
+</details>
+
+<details>
+<summary><h4>Compiling From GitHub</h4></summary>
 
 If you are building from git, you have to run the command below before
 compiling the source. This will generate the "configure" file, which is
 automatically done when building from tarball.
 
-```
+```bash
   sh autoconf.sh
+  ./configure
+  make
 ```
 
 Normally, this command automatically figures out everything it needs
@@ -126,12 +167,13 @@ configure script that modify its behaviour:
 				i686-w64-mingw32 for building 32-bit Windows executables
 			Both options require installing the required mingw-w64 packages.
 ```
+</details>
 
 ### (Optional) Testing
 
 To run a simple test before installation, execute
 
-```
+```bash
   make check
 ```
 
@@ -146,7 +188,7 @@ default install in /usr/local unless you specify a different prefix
 with the `--prefix=<path>` flag to the configure command.) You may need
 to do this as root to gain access to installation directories.
 
-```
+```bash
 	make install
 ```
 
@@ -166,11 +208,11 @@ switches.
 
 ### Preprocessing
 
-There is a separate program, ivlpp, that does the preprocessing. This
+There is a separate program, `ivlpp`, that does the preprocessing. This
 program implements the `` `include `` and  `` `define `` directives producing
 output that is equivalent but without the directives. The output is a
 single file with line number directives, so that the actual compiler
-only sees a single input file. See ivlpp/ivlpp.txt for details.
+only sees a single input file. See `ivlpp/ivlpp.txt` for details.
 
 ### Parse
 
@@ -251,7 +293,7 @@ to generate actual output.
 The user selects the target code generator with the `-t` flag on the
 command line.
 
-### ATTRIBUTES
+### Attributes
 
 > NOTE: The $attribute syntax will soon be deprecated in favour of the Verilog-2001 attribute syntax, which is cleaner and standardized.
 
@@ -290,31 +332,32 @@ attributes. They have the same general meaning as with the $attribute
 syntax, but they are attached to objects by position instead of by
 name. Also, the key is a Verilog identifier instead of a string.
 
-## Running iverilog
+## Running `iverilog`
 
 The preferred way to invoke the compiler is with the `iverilog`(1)
-command. This program invokes the preprocessor (ivlpp) and the
+command. This program invokes the preprocessor (`ivlpp`) and the
 compiler (`ivl`) with the proper command line options to get the job
 done in a friendly way. See the `iverilog`(1) man page for usage details.
 
 
-## EXAMPLES
+### EXAMPLE: Hello World
 
 Example: Compiling `"hello.vl"`
 
-```
+```verilog
------------------------- hello.vl ----------------------------
+// ------------------------ hello.vl ----------------------------
+
 module main();
 
 initial
   begin
-    $display("Hi there");
+    $display("Hello World");
     $finish ;
   end
 
 endmodule
 
---------------------------------------------------------------
+// --------------------------------------------------------------
 ```
 
 Ensure that `iverilog` is on your search path, and the vpi library
@@ -322,16 +365,16 @@ is available.
 
 To compile the program:
 
-```
+```bash
 	iverilog hello.vl
 ```
 
-(The above presumes that /usr/local/include and /usr/local/lib are
+(The above presumes that `/usr/local/include` and `/usr/local/lib` are
-part of the compiler search path, which is usually the case for gcc.)
+part of the compiler search path, which is usually the case for `gcc`.)
 
-To run the program:
+To run the generated program:
 
-```
+```bash
 	./a.out
 ```
 
@@ -348,165 +391,30 @@ Verilog web page for the current state of support for Verilog, and in
 particular, browse the bug report database for reported unsupported
 constructs.
 
-  - System functions are supported, but the return value is a little
+  - Specify blocks are parsed but ignored by default. When enabled
-    tricky. See SYSTEM FUNCTION TABLE FILES in the iverilog man page.
+    by the `-gspecify` compiler option, a subset of specify block
-
+    constructs are supported.
-  - Specify blocks are parsed but ignored in general.
 
   - `trireg` is not supported. `tri0` and `tri1` are supported.
 
-  - tran primitives, i.e. `tran`, `tranif1`, `tranif0`, `rtran`, `rtranif1`
-    and `rtranif0` are not supported.
-
   - Net delays, of the form `wire #N foo;` do not work. Delays in
     every other context do work properly, including the V2001 form
     `wire #5 foo = bar;`
 
-  - Event controls inside non-blocking assignments are not supported.
+The list of unsupported SystemVerilog constructs is too large to
-    i.e.: `a <= @(posedge clk) b;`
+enumerate here.
 
-  - Macro arguments are not supported. `` `define `` macros are supported,
+## Nonstandard Constructs and Behaviors
-    but they cannot take arguments.
 
-## Nonstandard Constructs or Behaviors
+Icarus Verilog includes some features that are not part of the IEEE 1364
+standard, but have well-defined meaning, and also sometimes gives nonstandard
+(but extended) meanings to some features of the language that are defined.
+See the "Icarus Verilog Extensions" and "Icarus Verilog Quirks" sections at
+https://steveicarus.github.io/iverilog/ for more details.
 
-Icarus Verilog includes some features that are not part of the
+## Credits
-IEEE1364 standard, but have well-defined meaning, and also sometimes
-gives nonstandard (but extended) meanings to some features of the
-language that are defined. See the "extensions.txt" documentation for
-more details.
 
-* `$is_signed(<expr>)`
+Except where otherwise noted, Icarus Verilog, ivl, and ivlpp are
-
-	This system function returns 1 if the expression contained is
-	signed, or 0 otherwise. This is mostly of use for compiler
-	regression tests.
-
-* `$sizeof(<expr>)`, `$bits(<expr>)`
-
-	The `$bits` system function returns the size in bits of the
-	expression that is its argument. The result of this
-	function is undefined if the argument doesn't have a
-	self-determined size.
-
-	The `$sizeof` function is deprecated in favour of `$bits`, which is
-	the same thing, but included in the SystemVerilog definition.
-
-* `$simtime`
-	
-  The `$simtime` system function returns as a 64bit value the
-	simulation time, unscaled by the time units of local
-	scope. This is different from the $time and $stime functions
-	which return the scaled times. This function is added for
-	regression testing of the compiler and run time, but can be
-	used by applications who really want the simulation time.
-
-	Note that the simulation time can be confusing if there are
-	lots of different `` `timescales`` within a design. It is not in
-	general possible to predict what the simulation precision will
-	turn out to be.
-
-* `$mti_random()`, `$mti_dist_uniform`
-
-	These functions are similar to the IEEE1364 standard $random
-	functions, but they use the Mersenne Twister (MT19937)
-	algorithm. This is considered an excellent random number
-	generator, but does not generate the same sequence as the
-	standardized $random.
-
-### Builtin system functions
-
-Certain of the system functions have well-defined meanings, so
-can theoretically be evaluated at compile-time, instead of
-using runtime VPI code. Doing so means that VPI cannot
-override the definitions of functions handled in this
-manner. On the other hand, this makes them synthesizable, and
-also allows for more aggressive constant propagation. The
-functions handled in this manner are:
-
-* `$bits`
-* `$signed`
-* `$sizeof`
-* `$unsigned`
-
-Implementations of these system functions in VPI modules will be ignored.
-
-### Preprocessing Library Modules
-
-Icarus Verilog does preprocess modules that are loaded from
-libraries via the -y mechanism. However, the only macros
-defined during the compilation of that file are those that it
-defines itself (or includes) or that are defined in the
-command line or command file.
-
-Specifically, macros defined in the non-library source files
-are not remembered when the library module is loaded. This is
-intentional. If it were otherwise, then compilation results
-might vary depending on the order that libraries are loaded,
-and that is too unpredictable.
-
-It is said that some commercial compilers do allow macro
-definitions to span library modules. That's just plain weird.
-
-### Width in `%t` Time Formats
-
-Standard Verilog does not allow width fields in the %t formats
-of display strings. For example, this is illegal:
-
-```
-	$display("Time is %0t", $time);
-```
-
-Standard Verilog instead relies on the $timeformat to
-completely specify the format.
-
-Icarus Verilog allows the programmer to specify the field
-width. The `%t` format in Icarus Verilog works exactly as it
-does in standard Verilog. However, if the programmer chooses
-to specify a minimum width (i.e., `%5t`), then for that display
-Icarus Verilog will override the `$timeformat` minimum width and
-use the explicit minimum width.
-
-### vpiScope iterator on vpiScope objects.
-
-In the VPI, the normal way to iterate over vpiScope objects
-contained within a vpiScope object, is the vpiInternalScope
-iterator. Icarus Verilog adds support for the vpiScope
-iterator of a vpiScope object, that iterates over *everything*
-the is contained in the current scope. This is useful in cases
-where one wants to iterate over all the objects in a scope
-without iterating over all the contained types explicitly.
-
-### time 0 race resolution.
-
-Combinational logic is routinely modelled using always
-blocks. However, this can lead to race conditions if the
-inputs to the combinational block are initialized in initial
-statements. Icarus Verilog slightly modifies time 0 scheduling
-by arranging for always statements with ANYEDGE sensitivity
-lists to be scheduled before any other threads. This causes
-combinational always blocks to be triggered when the values in
-the sensitivity list are initialized by initial threads.
-
-### Nets with Types
-
-Icarus Verilog supports an extended syntax that allows nets
-and regs to be explicitly typed. The currently supported types
-are logic, bool and real. This implies that `logic` and `bool`
-are new keywords. Typical syntax is:
-
-```
-	wire real foo = 1.0;
-	reg logic bar, bat;
-```
-... and so forth. The syntax can be turned off by using the
--g2 flag to iverilog, and turned on explicitly with the -g2x
-flag to iverilog.
-
-
-## CREDITS
-
-Except where otherwise noted, Icarus Verilog, ivl and ivlpp are
 Copyright Stephen Williams. The proper notices are in the head of each
 file. However, I have early on received aid in the form of fixes,
 Verilog guidance, and especially testing from many people. Testers, in

Statement.cc

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998-2021 Stephen Williams (steve@icarus.com)
+ * Copyright (c) 1998-2024 Stephen Williams (steve@icarus.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
@@ -29,8 +29,9 @@ Statement::~Statement()
 {
 }
 
-PAssign_::PAssign_(PExpr*lval__, PExpr*ex, bool is_constant)
+PAssign_::PAssign_(PExpr*lval__, PExpr*ex, bool is_constant, bool is_init)
-: event_(0), count_(0), lval_(lval__), rval_(ex), is_constant_(is_constant)
+: event_(0), count_(0), lval_(lval__), rval_(ex), is_constant_(is_constant),
+  is_init_(is_init)
 {
       delay_ = 0;
 }
@@ -73,8 +74,8 @@ PAssign::PAssign(PExpr*lval__, PExpr*cnt, PEventStatement*d, PExpr*ex)
 {
 }
 
-PAssign::PAssign(PExpr*lval__, PExpr*ex, bool is_constant)
+PAssign::PAssign(PExpr*lval__, PExpr*ex, bool is_constant, bool is_init)
-: PAssign_(lval__, ex, is_constant), op_(0)
+: PAssign_(lval__, ex, is_constant, is_init), op_(0)
 {
 }
 
@@ -139,8 +140,8 @@ PChainConstructor* PBlock::extract_chain_constructor()
 
 void PBlock::set_join_type(PBlock::BL_TYPE type)
 {
-      assert(bl_type_ == BL_PAR);
+      ivl_assert(*this, bl_type_ == BL_PAR);
-      assert(type==BL_PAR || type==BL_JOIN_NONE || type==BL_JOIN_ANY);
+      ivl_assert(*this, type==BL_PAR || type==BL_JOIN_NONE || type==BL_JOIN_ANY);
       bl_type_ = type;
 }
 
@@ -165,37 +166,19 @@ PNamedItem::SymbolType PBlock::symbol_type() const
       return BLOCK;
 }
 
-PCallTask::PCallTask(const pform_name_t&n, const list<PExpr*>&p)
+PCallTask::PCallTask(const pform_name_t &n, const list<named_pexpr_t> &p)
-: package_(0), path_(n), parms_(p.size())
+: package_(0), path_(n), parms_(p.begin(), p.end())
 {
-      list<PExpr*>::const_iterator cur = p.begin();
-      for (size_t idx = 0 ; idx < parms_.size() ; idx += 1) {
-	    parms_[idx] = *cur;
-	    ++cur;
-      }
-      assert(cur == p.end());
 }
 
-PCallTask::PCallTask(PPackage*pkg, const pform_name_t&n, const list<PExpr*>&p)
+PCallTask::PCallTask(PPackage *pkg, const pform_name_t &n, const list<named_pexpr_t> &p)
-: package_(pkg), path_(n), parms_(p.size())
+: package_(pkg), path_(n), parms_(p.begin(), p.end())
 {
-      list<PExpr*>::const_iterator cur = p.begin();
-      for (size_t idx = 0 ; idx < parms_.size() ; idx += 1) {
-	    parms_[idx] = *cur;
-	    ++cur;
-      }
-      assert(cur == p.end());
 }
 
-PCallTask::PCallTask(perm_string n, const list<PExpr*>&p)
+PCallTask::PCallTask(perm_string n, const list<named_pexpr_t> &p)
-: package_(0), parms_(p.size())
+: package_(0), parms_(p.begin(), p.end())
 {
-      list<PExpr*>::const_iterator cur = p.begin();
-      for (size_t idx = 0 ; idx < parms_.size() ; idx += 1) {
-	    parms_[idx] = *cur;
-	    ++cur;
-      }
-      assert(cur == p.end());
       path_.push_back(name_component_t(n));
 }
 
@@ -233,15 +216,14 @@ PCAssign::~PCAssign()
       delete expr_;
 }
 
-PChainConstructor::PChainConstructor(const list<PExpr*>&parms)
+PChainConstructor::PChainConstructor(const list<named_pexpr_t> &parms)
-: parms_(parms.size())
+: parms_(parms.begin(), parms.end())
+{
+}
+
+PChainConstructor::PChainConstructor(const vector<named_pexpr_t> &parms)
+: parms_(parms)
 {
-      list<PExpr*>::const_iterator cur = parms.begin();
-      for (size_t idx = 0 ; idx < parms_.size() ; idx += 1) {
-	    parms_[idx] = *cur;
-	    ++cur;
-      }
-      assert(cur == parms.end());
 }
 
 PChainConstructor::~PChainConstructor()
@@ -303,7 +285,7 @@ PDoWhile::~PDoWhile()
 PEventStatement::PEventStatement(const std::vector<PEEvent*>&ee)
 : expr_(ee), statement_(0), always_sens_(false)
 {
-      assert(expr_.size() > 0);
+      ivl_assert(*this, expr_.size() > 0);
 }
 
 
@@ -349,12 +331,8 @@ PForce::~PForce()
 }
 
 PForeach::PForeach(perm_string av, const list<perm_string>&ix, Statement*s)
-: array_var_(av), index_vars_(ix.size()), statement_(s)
+: array_var_(av), index_vars_(ix.begin(), ix.end()), statement_(s)
 {
-      size_t idx = 0;
-      for (list<perm_string>::const_iterator cur = ix.begin()
-		 ; cur != ix.end() ; ++cur)
-	    index_vars_[idx++] = *cur;
 }
 
 PForeach::~PForeach()
@@ -418,8 +396,8 @@ PReturn::~PReturn()
       delete expr_;
 }
 
-PTrigger::PTrigger(PPackage*pkg, const pform_name_t&ev)
+PTrigger::PTrigger(PPackage*pkg, const pform_name_t&ev, unsigned lexical_pos)
-: package_(pkg), event_(ev)
+: event_(pkg, ev), lexical_pos_(lexical_pos)
 {
 }
 
@@ -427,8 +405,8 @@ PTrigger::~PTrigger()
 {
 }
 
-PNBTrigger::PNBTrigger(const pform_name_t&ev, PExpr*dly)
+PNBTrigger::PNBTrigger(const pform_name_t&ev, unsigned lexical_pos, PExpr*dly)
-: event_(ev), dly_(dly)
+: event_(ev), lexical_pos_(lexical_pos), dly_(dly)
 {
 }