diff --git a/README.rst b/README.rst index cd067fffa..29e399531 100644 --- a/README.rst +++ b/README.rst @@ -4,19 +4,19 @@ |badge1| |badge2| |badge3| |badge4| |badge5| |badge7| |badge8| .. |badge1| image:: https://img.shields.io/badge/Website-Verilator.org-181717.svg - :target: https://verilator.org + :target: https://verilator.org .. |badge2| image:: https://img.shields.io/badge/License-LGPL%20v3-blue.svg - :target: https://www.gnu.org/licenses/lgpl-3.0 + :target: https://www.gnu.org/licenses/lgpl-3.0 .. |badge3| image:: https://img.shields.io/badge/License-Artistic%202.0-0298c3.svg - :target: https://opensource.org/licenses/Artistic-2.0 + :target: https://opensource.org/licenses/Artistic-2.0 .. |badge4| image:: https://repology.org/badge/tiny-repos/verilator.svg?header=distro%20packages - :target: https://repology.org/project/verilator/versions + :target: https://repology.org/project/verilator/versions .. |badge5| image:: https://img.shields.io/docker/pulls/verilator/verilator - :target: https://hub.docker.com/r/verilator/verilator + :target: https://hub.docker.com/r/verilator/verilator .. |badge7| image:: https://github.com/verilator/verilator/workflows/build/badge.svg - :target: https://github.com/verilator/verilator/actions?query=workflow%3Abuild + :target: https://github.com/verilator/verilator/actions?query=workflow%3Abuild .. |badge8| image:: https://img.shields.io/github/actions/workflow/status/verilator/verilator/rtlmeter.yml?branch=master&event=schedule&label=benchmarks - :target: https://verilator.github.io/verilator-rtlmeter-results + :target: https://verilator.github.io/verilator-rtlmeter-results Welcome to Verilator @@ -54,7 +54,7 @@ Welcome to Verilator What Verilator Does =================== -Verilator is invoked with parameters similar to GCC or Synopsys's VCS. It +Verilator is invoked with parameters similar to GCC or Synopsys's VCS. It "Verilates" the specified Verilog or SystemVerilog code by reading it, performing lint checks, and optionally inserting assertion checks and coverage-analysis points. It outputs single- or multithreaded .cpp and .h @@ -69,21 +69,21 @@ Verilated generated libraries, optionally encrypted, into other simulators. Verilator may not be the best choice if you are expecting a full-featured replacement for a closed-source Verilog simulator, need SDF annotation, mixed-signal simulation, or are doing a quick class project (we recommend -`Icarus Verilog`_ for classwork). However, if you are looking for a path -to migrate SystemVerilog to C++/SystemC, or want high-speed simulation of +`Icarus Verilog`_ for classwork). However, if you are looking for a path to +migrate SystemVerilog to C++/SystemC, or want high-speed simulation of designs, Verilator is the tool for you. Performance =========== -Verilator does not directly translate Verilog HDL to C++ or SystemC. Rather, -Verilator compiles your code into a much faster optimized and optionally -thread-partitioned model, which is in turn wrapped inside a C++/SystemC -module. The results are a compiled Verilog model that executes even on a -single thread over 10x faster than standalone SystemC, and on a single -thread is about 100 times faster than interpreted Verilog simulators such -as `Icarus Verilog`_. Another 2-10x speedup might be gained from +Verilator does not directly translate Verilog HDL to C++ or SystemC. +Rather, Verilator compiles your code into a much faster optimized and +optionally thread-partitioned model, which is in turn wrapped inside a +C++/SystemC module. The results are a compiled Verilog model that executes +even on a single thread over 10x faster than standalone SystemC, and on a +single thread is about 100 times faster than interpreted Verilog simulators +such as `Icarus Verilog`_. Another 2-10x speedup might be gained from multithreading (yielding 200-1000x total over interpreted simulators). Verilator has typically similar or better performance versus closed-source @@ -101,8 +101,8 @@ For more information: - `Verilator installation and package directory structure `_ -- `Verilator manual (HTML) `_, - or `Verilator manual (PDF) `_ +- `Verilator manual (HTML) `_, or + `Verilator manual (PDF) `_ - `Subscribe to Verilator announcements `_ diff --git a/ci/docker/buildenv/README.rst b/ci/docker/buildenv/README.rst index a111e1be7..d579574af 100644 --- a/ci/docker/buildenv/README.rst +++ b/ci/docker/buildenv/README.rst @@ -9,11 +9,11 @@ Verilator Build Docker Container This Verilator Build Docker Container is set up to compile and test a Verilator build. It uses the following parameters: -- Source repository (default: https://github.com/verilator/verilator) +- Source repository (default: https://github.com/verilator/verilator) -- Source revision (default: master) +- Source revision (default: master) -- Compiler (GCC 13.3.0, clang 18.1.3, default: 13.3.0) +- Compiler (GCC 13.3.0, clang 18.1.3, default: 13.3.0) The container is published as ``verilator/verilator-buildenv`` on `docker hub @@ -37,8 +37,9 @@ To change the compiler use the `-e` switch to pass environment variables: docker run -ti -e CXX=clang++-18 verilator/verilator-buildenv test -The tests, that involve numactl are not working due to security restrictions. -To run those too, add the CAP_SYS_NICE capability during the start of the container: +The tests, that involve numactl are not working due to security +restrictions. To run those too, add the CAP_SYS_NICE capability during the +start of the container: :: diff --git a/ci/docker/run/README.rst b/ci/docker/run/README.rst index 86bad6cdb..aaf9d783f 100644 --- a/ci/docker/run/README.rst +++ b/ci/docker/run/README.rst @@ -11,12 +11,12 @@ easily as a docker image, e.g.: docker run -ti verilator/verilator:latest --version -This will pull the container from `docker hub -`_, run the latest Verilator and print -Verilator's version. +This will pull the container from `Docker Hub +`_, run the latest Verilator +and print Verilator's version. -Containers are automatically built and pushed to docker hub for all released versions, so you may -easily compare results across versions, e.g.: +Containers are automatically built and pushed to docker hub for all +released versions, so you may easily compare results across versions, e.g.: :: @@ -38,7 +38,7 @@ or ./verilator-docker 4.030 --cc test.v If you prefer not to use ``verilator-docker`` you must give the container -access to your files as a volume with appropriate user rights. For example +access to your files as a volume with appropriate user rights. For example to Verilate test.v: :: @@ -68,9 +68,9 @@ Internals The Dockerfile builds Verilator and removes the tree when completed to reduce the image size. The entrypoint is a wrapper script (``verilator-wrap.sh``). That script 1. calls Verilator, and 2. copies the -Verilated runtime files to the ``obj_dir`` or the ``-Mdir`` -respectively. This allows the user to have the files to they may later -build the C++ output with the matching runtime files. The wrapper also -patches the Verilated Makefile accordingly. +Verilated runtime files to the ``obj_dir`` or the ``-Mdir`` respectively. +This allows the user to have the files to they may later build the C++ +output with the matching runtime files. The wrapper also patches the +Verilated Makefile accordingly. A hook is also defined and run by Docker Hub via automated builds. diff --git a/docs/CONTRIBUTING.rst b/docs/CONTRIBUTING.rst index 061394812..4b42b8f1d 100644 --- a/docs/CONTRIBUTING.rst +++ b/docs/CONTRIBUTING.rst @@ -23,8 +23,8 @@ Did you find a Verilator bug? demonstrating the bug and expected behavior that is not occurring. - The ideal example works against other simulators, and is in the - test_regress/t test format, as described in - `Verilator Internals Documentation + test_regress/t test format, as described in `Verilator Internals + Documentation `__. @@ -38,18 +38,18 @@ Did you write a patch that fixes a Verilator bug? `__. - See the coding conventions, and other developer information in - ``docs/internals.rst`` in the distribution, or as rendered at - `Verilator Internals Documentation + ``docs/internals.rst`` in the distribution, or as rendered at `Verilator + Internals Documentation `__. -- Verilator uses GitHub Actions to provide continuous integration. You - may want to enable Actions on your GitHub branch to ensure your changes - keep the tests passing. +- Verilator uses GitHub Actions to provide continuous integration. You may + want to enable Actions on your GitHub branch to ensure your changes keep + the tests passing. -- Your source-code contributions must be certified as open source, - under the `Developer Certificate of - Origin `__. On your first - contribution, you must either: +- Your source-code contributions must be certified as open source, under + the `Developer Certificate of Origin + `__. On your first contribution, you + must either: - Have your patch include the addition of your name to `docs/CONTRIBUTORS `__ (preferred). @@ -75,9 +75,9 @@ Did you write a patch that fixes a Verilator bug? Do you have questions on Verilator? ----------------------------------- -- Please see FAQ section and rest of the `Verilator - manual `__, or `Verilator - manual (PDF) `__. +- Please see FAQ section and rest of the `Verilator manual + `__, or `Verilator manual (PDF) + `__. - Ask any question in the `Verilator forum `__. diff --git a/docs/README.rst b/docs/README.rst index 3e5949f15..0752c6a5c 100644 --- a/docs/README.rst +++ b/docs/README.rst @@ -10,8 +10,8 @@ For formatted documentation see: - `Verilator installation and package directory structure `_ -- `Verilator manual (HTML) `_, - or `Verilator manual (PDF) `_ +- `Verilator manual (HTML) `_, or + `Verilator manual (PDF) `_ - `Subscribe to Verilator announcements `_ diff --git a/docs/guide/changes.rst b/docs/guide/changes.rst index 7454f5162..e284eb178 100644 --- a/docs/guide/changes.rst +++ b/docs/guide/changes.rst @@ -5,12 +5,13 @@ Revision History **************** -.. COMMENT above header must use ### so there is an extra level of headers +.. + COMMENT above header must use *** so there is an extra level of headers here so the index won't show the huge list of revisions when clicking on "Revision History" in the sidebar. Changes are contained in the :file:`Changes` file of the distribution, and -also summarized below. To subscribe to new versions, see `Verilator +also summarized below. To subscribe to new versions, see `Verilator Announcements `_. .. include:: ../_build/gen/Changes diff --git a/docs/guide/connecting.rst b/docs/guide/connecting.rst index b951acd97..dab359147 100644 --- a/docs/guide/connecting.rst +++ b/docs/guide/connecting.rst @@ -11,13 +11,13 @@ Structure of the Verilated Model ================================ Verilator outputs a :file:`{prefix}.h` header file which defines a class -named :code:`{prefix}` which represents the generated model the user is -supposed to instantiate. This model class defines the interface of the +named ``{prefix}`` which represents the generated model the user is +supposed to instantiate. This model class defines the interface of the Verilated model. Verilator will additionally create a :file:`{prefix}.cpp` file, together -with additional .h and .cpp files for internals. See the :file:`examples` -directory in the kit for examples. See :ref:`Files Read/Written` for +with additional .h and .cpp files for internals. See the :file:`examples` +directory in the kit for examples. See :ref:`Files Read/Written` for information on all the files Verilator might output. The output of Verilator will contain a :file:`{prefix}.mk` file that may be @@ -32,91 +32,89 @@ model: equivalents. * Public top level module instances are exposed as pointers to allow access - to :code:`/* verilator public */` items. + to ``/* verilator public */`` items. -* The root of the design hierarchy (as in SystemVerilog :code:`$root`) is - exposed via the :code:`rootp` member pointer to allow access to model - internals, including :code:`/* verilator public_flat */` items. +* The root of the design hierarchy (as in SystemVerilog ``$root``) is + exposed via the ``rootp`` member pointer to allow access to model + internals, including ``/* verilator public_flat */`` items. .. _porting from pre 4.210: Model interface changes in version 4.210 ------------------------------------------- +---------------------------------------- Starting from version 4.210, the model class is an interface object. Up until Verilator version 4.204 inclusive, the generated model class was also the instance of the top level instance in the design hierarchy (what -you would refer to with :code:`$root` in SystemVerilog). This meant that -all internal variables that were implemented by Verilator in the root scope -were accessible as members of the model class itself. Note there were often -many such variable due to module inlining, including -:code:`/* verilator public_flat */` items. +you would refer to with ``$root`` in SystemVerilog). This meant that all +internal variables that were implemented by Verilator in the root scope +were accessible as members of the model class itself. Note there were often +many such variable due to module inlining, including ``/* verilator +public_flat */`` items. This means that user code that accesses internal signals in the model -(likely including :code:`/* verilator public_flat */` signals, as they are +(likely including ``/* verilator public_flat */`` signals, as they are often inlined into the root scope) will need to be updated as follows: * No change required for accessing top level IO signals. These are directly accessible in the model class via references. -* No change required for accessing :code:`/* verilator public */` items. - These are directly accessible via sub-module pointers in the model class. +* No change required for accessing ``/* verilator public */`` items. These + are directly accessible via sub-module pointers in the model class. * Accessing any other internal members, including - :code:`/* verilator public_flat */` items requires the following changes: + ``/* verilator public_flat */`` items requires the following changes: * Additionally include :file:`{prefix}___024root.h`. This header defines - type of the :code:`rootp` pointer within the model class. Note the - :code:`__024` substring is the Verilator escape sequence for the - :code:`$` character, i.e.: :code:`rootp` points to the Verilated - SystemVerilog :code:`$root` scope. + type of the ``rootp`` pointer within the model class. Note the + ``__024`` substring is the Verilator escape sequence for the ``$`` + character, i.e.: ``rootp`` points to the Verilated SystemVerilog + ``$root`` scope. - * Replace :code:`modelp->internal->member` references with - :code:`modelp->rootp->internal->member` references, which - contain one additional indirection via the :code:`rootp` pointer. + * Replace ``modelp->internal->member`` references with + ``modelp->rootp->internal->member`` references, which contain one + additional indirection via the ``rootp`` pointer. -.. _connecting to C++: +.. _connecting to c++: Connecting to C++ ================= -In C++ output mode (:vlopt:`--cc`), the Verilator generated model class is a -simple C++ class. The user must write a C++ wrapper and main loop for the +In C++ output mode (:vlopt:`--cc`), the Verilator generated model class is +a simple C++ class. The user must write a C++ wrapper and main loop for the simulation, which instantiates the model class, and link with the Verilated model. Refer to ``examples/make_tracing_c`` in the distribution for a detailed commented example. -Top level IO signals are read and written as members of the model. You -call the model's :code:`eval()` method to evaluate the model. When the -simulation is complete call the model's :code:`final()` method to execute -any SystemVerilog final blocks, and complete any assertions. If using -:vlopt:`--timing`, there are two additional functions for checking if -there are any events pending in the simulation due to delays, and for -retrieving the simulation time of the next delayed event. See -:ref:`Evaluation Loop`. - +Top level IO signals are read and written as members of the model. You call +the model's ``eval()`` method to evaluate the model. When the simulation is +complete call the model's ``final()`` method to execute any SystemVerilog +final blocks, and complete any assertions. If using :vlopt:`--timing`, +there are two additional functions for checking if there are any events +pending in the simulation due to delays, and for retrieving the simulation +time of the next delayed event. See :ref:`Evaluation Loop`. Connecting to SystemC ===================== In SystemC output mode (:vlopt:`--sc`), the Verilator generated model class -is a SystemC SC_MODULE. This module will attach directly into a SystemC +is a SystemC SC_MODULE. This module will attach directly into a SystemC netlist as an instantiation. The SC_MODULE gets the same pinout as the Verilog module, with the -following type conversions: Pins of a single bit become bool. Pins 2-32 -bits wide become uint32_t's. Pins 33-64 bits wide become sc_bv's or -uint64_t's depending on the :vlopt:`--no-pins64` option. Wider pins -become sc_bv's. (Uints simulate the fastest so are used where possible.) +following type conversions: Pins of a single bit become bool. Pins 2-32 +bits wide become uint32_t's. Pins 33-64 bits wide become sc_bv's or +uint64_t's depending on the :vlopt:`--no-pins64` option. Wider pins become +sc_bv's. (Uints simulate the fastest so are used where possible.) Model internals, including lower level sub-modules are not pure SystemC -code. This is a feature, as using the SystemC pin interconnect scheme +code. This is a feature, as using the SystemC pin interconnect scheme everywhere would reduce performance by an order of magnitude. @@ -124,41 +122,42 @@ Verilated API ============= The API to a Verilated model is the C++ headers in the include/ directory -in the distribution. These headers use Doxygen comments, `///` and `//<`, +in the distribution. These headers use Doxygen comments, `///` and `//<`, to indicate and document those functions that are part of the Verilated public API. Process-Level Clone APIs --------------------------- +------------------------ -Modern operating systems support process-level clone (a.k.a copying, forking) -with system call interfaces in C/C++, e.g., :code:`fork()` in Linux. +Modern operating systems support process-level clone (a.k.a copying, +forking) with system call interfaces in C/C++, e.g., ``fork()`` in Linux. However, after cloning a parent process, some resources cannot be inherited -in the child process. For example, in POSIX systems, when you fork a process, -the child process inherits all the memory of the parent process. However, -only the thread that called fork is replicated in the child process. Other -threads are not. +in the child process. For example, in POSIX systems, when you fork a +process, the child process inherits all the memory of the parent process. +However, only the thread that called fork is replicated in the child +process. Other threads are not. -Therefore, to support the process-level clone mechanisms, Verilator supports -:code:`prepareClone()` and :code:`atClone()` APIs to allow the user to manually -re-construct the model in the child process. The two APIs handle all necessary -resources required for releasing and re-initializing before and after cloning. +Therefore, to support the process-level clone mechanisms, Verilator +supports ``prepareClone()`` and ``atClone()`` APIs to allow the user to +manually re-construct the model in the child process. The two APIs handle +all necessary resources required for releasing and re-initializing before +and after cloning. -The two APIs are supported in the verilated models. Here is an example of usage -with Linux :code:`fork()` and :code:`pthread_atfork` APIs: +The two APIs are supported in the verilated models. Here is an example of +usage with Linux ``fork()`` and ``pthread_atfork`` APIs: .. code-block:: C++ - // static function pointers to fit pthread_atfork - static auto prepareClone = [](){ topp->prepareClone(); }; - static auto atClone = [](){ topp->atClone(); }; + // static function pointers to fit pthread_atfork + static auto prepareClone = [](){ topp->prepareClone(); }; + static auto atClone = [](){ topp->atClone(); }; - // in main function, register the handlers: - pthread_atfork(prepareClone, atClone, atClone); + // in main function, register the handlers: + pthread_atfork(prepareClone, atClone, atClone); For better flexibility, you can also manually call the handlers before and -after :code:`fork()`. +after ``fork()``. With the process-level clone APIs, users can create process-level snapshots for the verilated models. While the Verilator save/restore option provides @@ -170,7 +169,7 @@ Direct Programming Interface (DPI) ================================== Verilator supports SystemVerilog Direct Programming Interface import and -export statements. Only the SystemVerilog form ("DPI-C") is supported, not +export statements. Only the SystemVerilog form ("DPI-C") is supported, not the original Synopsys-only DPI. DPI Example @@ -181,76 +180,76 @@ Verilog, put in our.v: .. code-block:: - import "DPI-C" function int add (input int a, input int b); + import "DPI-C" function int add (input int a, input int b); - initial begin - $display("%x + %x = %x", 1, 2, add(1,2)); - endtask + initial begin + $display("%x + %x = %x", 1, 2, add(1,2)); + endtask Then after Verilating, Verilator will create a file Vour__Dpi.h with the prototype to call this function: .. code-block:: C++ - extern int add(int a, int b); + extern int add(int a, int b); From the sc_main.cpp file (or another .cpp file passed to the Verilator command line, or the link), you'd then: .. code-block:: C++ - #include "svdpi.h" - #include "Vour__Dpi.h" - int add(int a, int b) { return a+b; } + #include "svdpi.h" + #include "Vour__Dpi.h" + int add(int a, int b) { return a+b; } DPI System Task/Functions ------------------------- Verilator extends the DPI format to allow using the same scheme to -efficiently add system functions. Use a dollar-sign prefixed system +efficiently add system functions. Use a dollar-sign prefixed system function name for the import, but note it must be escaped. .. code-block:: sv - export "DPI-C" function integer \$myRand; + export "DPI-C" function integer \$myRand; - initial $display("myRand=%d", $myRand()); + initial $display("myRand=%d", $myRand()); Going the other direction, you can export Verilog tasks so they can be called from C++: .. code-block:: sv - export "DPI-C" task publicSetBool; + export "DPI-C" task publicSetBool; - task publicSetBool; - input bit in_bool; - var_bool = in_bool; - endtask + task publicSetBool; + input bit in_bool; + var_bool = in_bool; + endtask Then after Verilating, Verilator will create a file Vour__Dpi.h with the prototype to call this function: .. code-block:: C++ - extern void publicSetBool(svBit in_bool); + extern void publicSetBool(svBit in_bool); From the sc_main.cpp file, you'd then: .. code-block:: C++ - #include "Vour__Dpi.h" - publicSetBool(value); + #include "Vour__Dpi.h" + publicSetBool(value); -Or, alternatively, call the function under the design class. This isn't -DPI compatible but is easier to read and better supports multiple designs. +Or, alternatively, call the function under the design class. This isn't DPI +compatible but is easier to read and better supports multiple designs. .. code-block:: C++ - #include "Vour__Dpi.h" - Vour::publicSetBool(value); - // or top->publicSetBool(value); + #include "Vour__Dpi.h" + Vour::publicSetBool(value); + // or top->publicSetBool(value); Note that if the DPI task or function accesses any register or net within the RTL, it will require a scope to be set. This can be done using the @@ -263,11 +262,11 @@ with respect to that top level module, then the scope could be set with .. code-block:: C++ - #include "svdpi.h" - ... - const svScope scope = svGetScopeFromName("TOP.dut"); - assert(scope); // Check for nullptr if scope not found - svSetScope(scope); + #include "svdpi.h" + ... + const svScope scope = svGetScopeFromName("TOP.dut"); + assert(scope); // Check for nullptr if scope not found + svSetScope(scope); (Remember that Verilator adds a "TOP" to the top of the module hierarchy.) @@ -282,24 +281,24 @@ DPI Imports that access signals If a DPI import accesses a signal through the VPI Verilator will not be able to know what variables are accessed and may schedule the code -inappropriately. Ideally pass the values as inputs/outputs so the VPI is -not required. Alternatively a workaround is to use a non-inlined task as a +inappropriately. Ideally pass the values as inputs/outputs so the VPI is +not required. Alternatively a workaround is to use a non-inlined task as a wrapper: .. code-block:: - logic din; + logic din; - // This DPI function will read "din" - import "DPI-C" context function void dpi_that_accesses_din(); + // This DPI function will read "din" + import "DPI-C" context function void dpi_that_accesses_din(); - always @(...) - dpi_din_args(din); + always @(...) + dpi_din_args(din); - task dpi_din_args(input din); - // verilator no_inline_task - dpi_that_accesses_din(); - endtask + task dpi_din_args(input din); + // verilator no_inline_task + dpi_that_accesses_din(); + endtask DPI Display Functions @@ -309,8 +308,8 @@ Verilator allows writing $display like functions using this syntax: .. code-block:: - import "DPI-C" function void - \$my_display(input string formatted /*verilator sformat*/ ); + import "DPI-C" function void + \$my_display(input string formatted /*verilator sformat*/ ); The :option:`/*verilator&32;sformat*/` metacomment indicates that this function accepts a $display like format specifier followed by any number of @@ -320,14 +319,14 @@ arguments to satisfy the format. DPI Context Functions --------------------- -Verilator supports IEEE DPI Context Functions. Context imports pass the +Verilator supports IEEE DPI Context Functions. Context imports pass the simulator context, including calling scope name, and filename and line -number to the C code. For example, in Verilog: +number to the C code. For example, in Verilog: .. code-block:: - import "DPI-C" context function int dpic_line(); - initial $display("This is line %d, again, line %d\n", `line, dpic_line()); + import "DPI-C" context function int dpic_line(); + initial $display("This is line %d, again, line %d\n", `line, dpic_line()); This will call C++ code which may then use the svGet\* functions to read information, in this case the line number of the Verilog statement that @@ -335,22 +334,22 @@ invoked the dpic_line function: .. code-block:: C++ - int dpic_line() { - // Get a scope: svScope scope = svGetScope(); + int dpic_line() { + // Get a scope: svScope scope = svGetScope(); - const char* scopenamep = svGetNameFromScope(scope); - assert(scopenamep); + const char* scopenamep = svGetNameFromScope(scope); + assert(scopenamep); - const char* filenamep = ""; - int lineno = 0; - if (svGetCallerInfo(&filenamep, &lineno)) { - printf("dpic_line called from scope %s on line %d\n", - scopenamep, lineno); - return lineno; - } else { - return 0; - } - } + const char* filenamep = ""; + int lineno = 0; + if (svGetCallerInfo(&filenamep, &lineno)) { + printf("dpic_line called from scope %s on line %d\n", + scopenamep, lineno); + return lineno; + } else { + return 0; + } + } See the IEEE Standard for more information. @@ -359,13 +358,12 @@ DPI Header Isolation -------------------- Verilator places the IEEE standard header files such as svdpi.h into a -separate include directory, vltstd (VeriLaTor STandarD). When compiling +separate include directory, vltstd (VeriLaTor STandarD). When compiling most applications $VERILATOR_ROOT/include/vltstd would be in the include -path along with the normal $VERILATOR_ROOT/include. However, when -compiling Verilated models into other simulators which have their own -svdpi.h and similar standard files with different contents, the vltstd -directory should not be included to prevent picking up incompatible -definitions. +path along with the normal $VERILATOR_ROOT/include. However, when compiling +Verilated models into other simulators which have their own svdpi.h and +similar standard files with different contents, the vltstd directory should +not be included to prevent picking up incompatible definitions. Public Functions @@ -378,24 +376,23 @@ are slightly faster, but less compatible. Verification Procedural Interface (VPI) ======================================= -Verilator supports a limited subset of the VPI. This subset allows +Verilator supports a limited subset of the VPI. This subset allows inspection, examination, value change callbacks, and depositing of values to public signals only. VPI is enabled with the Verilator :vlopt:`--vpi` option. To access signals via the VPI, Verilator must be told exactly which signals -are to be accessed. This is done using the Verilator public pragmas +are to be accessed. This is done using the Verilator public pragmas documented below. Verilator has an important difference from an event based simulator; signal values that are changed by the VPI will not immediately propagate their -values, instead the top level header file's :code:`eval()` method must be -called. Normally this would be part of the normal evaluation (i.e. the -next clock edge), not as part of the value change. This makes the -performance of VPI routines extremely fast compared to event based -simulators, but can confuse some test-benches that expect immediate -propagation. +values, instead the top level header file's ``eval()`` method must be +called. Normally this would be part of the normal evaluation (i.e. the next +clock edge), not as part of the value change. This makes the performance of +VPI routines extremely fast compared to event based simulators, but can +confuse some test-benches that expect immediate propagation. Note the VPI by its specified implementation will always be much slower than accessing the Verilator values by direct reference @@ -405,17 +402,18 @@ while the direct references are evaluated by the compiler and result in only a couple of instructions. For signal callbacks to work the main loop of the program must call -:code:`VerilatedVpi::callValueCbs()`. +``VerilatedVpi::callValueCbs()``. -Verilator also tracks when the model state has been modified via the VPI with -an :code:`evalNeeded` flag. This flag can be checked with :code:`VerilatedVpi::evalNeeded()` -and it can be cleared with :code:`VerilatedVpi::clearEvalNeeded()`. Used together -it is possible to skip :code:`eval()` calls if no model state has been changed -since the last :code:`eval()`. +Verilator also tracks when the model state has been modified via the VPI +with an ``evalNeeded`` flag. This flag can be checked with +``VerilatedVpi::evalNeeded()`` and it can be cleared with +``VerilatedVpi::clearEvalNeeded()``. Used together it is possible to skip +``eval()`` calls if no model state has been changed since the last +``eval()``. -Any data written via :code:`vpi_put_value` with :code:`vpiInertialDelay` will -be deferred for later. These delayed values can be flushed to the model with -:code:`VerilatedVpi::doInertialPuts()`. +Any data written via ``vpi_put_value`` with ``vpiInertialDelay`` will be +deferred for later. These delayed values can be flushed to the model with +``VerilatedVpi::doInertialPuts()``. .. _vpi example: @@ -424,62 +422,62 @@ VPI Example ----------- In the below example, we have readme marked read-only, and writeme marked -read-write which if written from outside the model will have the same semantics -as if it was a top level input. +read-write which if written from outside the model will have the same +semantics as if it was a top level input. .. code-block:: bash - cat >our.v <<'EOF' - module our #( - parameter WIDTH /*verilator public_flat_rd*/ = 32 - ) (input clk); - reg [WIDTH-1:0] readme /*verilator public_flat_rd*/; - reg [WIDTH-1:0] writeme /*verilator public_flat_rw*/; - initial $finish; - endmodule - EOF + cat >our.v <<'EOF' + module our #( + parameter WIDTH /*verilator public_flat_rd*/ = 32 + ) (input clk); + reg [WIDTH-1:0] readme /*verilator public_flat_rd*/; + reg [WIDTH-1:0] writeme /*verilator public_flat_rw*/; + initial $finish; + endmodule + EOF There are many online tutorials and books on the VPI, but an example that accesses the above signal "readme" would be: .. code-block:: bash - cat >sim_main.cpp <<'EOF' - #include "Vour.h" - #include "verilated.h" - #include "verilated_vpi.h" // Required to get definitions + cat >sim_main.cpp <<'EOF' + #include "Vour.h" + #include "verilated.h" + #include "verilated_vpi.h" // Required to get definitions - uint64_t main_time = 0; // See comments in first example - double sc_time_stamp() { return main_time; } + uint64_t main_time = 0; // See comments in first example + double sc_time_stamp() { return main_time; } - void read_and_check() { - vpiHandle vh1 = vpi_handle_by_name((PLI_BYTE8*)"TOP.our.readme", NULL); - if (!vh1) vl_fatal(__FILE__, __LINE__, "sim_main", "No handle found"); - const char* name = vpi_get_str(vpiName, vh1); - const char* type = vpi_get_str(vpiType, vh1); - const int size = vpi_get(vpiSize, vh1); - printf("register name: %s, type: %s, size: %d\n", name, type, size); // Prints "register name: readme, type: vpiReg, size: 32" + void read_and_check() { + vpiHandle vh1 = vpi_handle_by_name((PLI_BYTE8*)"TOP.our.readme", NULL); + if (!vh1) vl_fatal(__FILE__, __LINE__, "sim_main", "No handle found"); + const char* name = vpi_get_str(vpiName, vh1); + const char* type = vpi_get_str(vpiType, vh1); + const int size = vpi_get(vpiSize, vh1); + printf("register name: %s, type: %s, size: %d\n", name, type, size); // Prints "register name: readme, type: vpiReg, size: 32" - s_vpi_value v; - v.format = vpiIntVal; - vpi_get_value(vh1, &v); - printf("Value of %s: %d\n", name, v.value.integer); // Prints "Value of readme: 0" - } + s_vpi_value v; + v.format = vpiIntVal; + vpi_get_value(vh1, &v); + printf("Value of %s: %d\n", name, v.value.integer); // Prints "Value of readme: 0" + } - int main(int argc, char** argv) { - Verilated::commandArgs(argc, argv); - const std::unique_ptr contextp{new VerilatedContext}; - const std::unique_ptr top{new Vour{contextp.get()}}; + int main(int argc, char** argv) { + Verilated::commandArgs(argc, argv); + const std::unique_ptr contextp{new VerilatedContext}; + const std::unique_ptr top{new Vour{contextp.get()}}; - contextp->internalsDump(); // See scopes to help debug - while (!contextp->gotFinish()) { - top->eval(); - VerilatedVpi::callValueCbs(); // For signal callbacks - read_and_check(); - } - return 0; - } - EOF + contextp->internalsDump(); // See scopes to help debug + while (!contextp->gotFinish()) { + top->eval(); + VerilatedVpi::callValueCbs(); // For signal callbacks + read_and_check(); + } + return 0; + } + EOF .. _evaluation loop: @@ -488,49 +486,47 @@ Wrappers and Model Evaluation Loop ================================== When using SystemC, evaluation of the Verilated model is managed by the -SystemC kernel, and for the most part can be ignored. When using C++, the -user must call :code:`eval()`, or :code:`eval_step()` and -:code:`eval_end_step()`. +SystemC kernel, and for the most part can be ignored. When using C++, the +user must call ``eval()``, or ``eval_step()`` and ``eval_end_step()``. 1. When there is a single design instantiated at the C++ level that needs -to evaluate within a given context, call :code:`designp->eval()`. +to evaluate within a given context, call ``designp->eval()``. 2. When there are multiple designs instantiated at the C++ level that need -to evaluate within a context, call :code:`first_designp->eval_step()` then -:code:`->eval_step()` on all other designs. Then call -:code:`->eval_end_step()` on the first design then all other designs. If -there is only a single design, you would call :code:`eval_step()` then -:code:`eval_end_step()`; in fact :code:`eval()` described above is just a -wrapper which calls these two functions. +to evaluate within a context, call ``first_designp->eval_step()`` then +``->eval_step()`` on all other designs. Then call ``->eval_end_step()`` on +the first design then all other designs. If there is only a single design, +you would call ``eval_step()`` then ``eval_end_step()``; in fact ``eval()`` +described above is just a wrapper which calls these two functions. 3. If using delays and :vlopt:`--timing`, there are two additional methods the user should call: - * :code:`designp->eventsPending()`, which returns :code:`true` if there are + * ``designp->eventsPending()``, which returns ``true`` if there are any delayed events pending, - * :code:`designp->nextTimeSlot()`, which returns the simulation time of the + * ``designp->nextTimeSlot()``, which returns the simulation time of the next delayed event. This method can only be called if - :code:`designp->eventsPending()` returned :code:`true`. + ``designp->eventsPending()`` returned ``true``. -Call :code:`eventsPending()` to check if you should continue with the -simulation, and then :code:`nextTimeSlot()` to move simulation time forward. +Call ``eventsPending()`` to check if you should continue with the +simulation, and then ``nextTimeSlot()`` to move simulation time forward. :vlopt:`--main` can be used with :vlopt:`--timing` to generate a basic example of a timing-enabled eval loop. -When :code:`eval()` (or :code:`eval_step()`) is called Verilator looks for -changes in clock signals and evaluates related sequential always blocks, -such as computing always_ff @ (posedge...) outputs. With :vlopt:`--timing`, it +When ``eval()`` (or ``eval_step()``) is called Verilator looks for changes +in clock signals and evaluates related sequential always blocks, such as +computing always_ff @ (posedge...) outputs. With :vlopt:`--timing`, it resumes any delayed processes awaiting the current simulation time. Then Verilator evaluates combinational logic. Note combinatorial logic is not computed before sequential always blocks are computed (for speed reasons). Therefore it is best to set any non-clock -inputs up with a separate :code:`eval()` call before changing clocks. +inputs up with a separate ``eval()`` call before changing clocks. Alternatively, if all always_ff statements use only the posedge of clocks, or all inputs go directly to always_ff statements, as is typical, then you can change non-clock inputs on the negative edge of the input clock, which -will be faster as there will be fewer :code:`eval()` calls. +will be faster as there will be fewer ``eval()`` calls. For more information on evaluation, see :file:`docs/internals.rst` in the distribution. @@ -540,18 +536,18 @@ Verilated and VerilatedContext ============================== Multiple C++ Verilated models may be part of the same simulation context, -that is share a VPI interface, sense of time, and common settings. This +that is share a VPI interface, sense of time, and common settings. This common simulation context information is stored in a ``VerilatedContext`` -structure. If a ``VerilatedContext`` is not created prior to creating a -model, a default global one is created automatically. SystemC requires +structure. If a ``VerilatedContext`` is not created prior to creating a +model, a default global one is created automatically. SystemC requires using only the single, default VerilatedContext. The ``Verilated::`` methods, including the ``Verilated::commandArgs`` call shown above, call VerilatedContext methods using the default global -VerilatedContext. (Technically they operate on the last one used by a -given thread.) If you are using multiple simulation contexts you should -not use the Verilated:: methods, and instead always use VerilatedContext -methods called on the appropriate VerilatedContext object. +VerilatedContext. (Technically they operate on the last one used by a given +thread.) If you are using multiple simulation contexts you should not use +the Verilated:: methods, and instead always use VerilatedContext methods +called on the appropriate VerilatedContext object. For methods available under Verilated and VerilatedContext see :file:`include/verilated.h` in the distribution. diff --git a/docs/guide/contributing.rst b/docs/guide/contributing.rst index b5d82f3b5..e5e06ceba 100644 --- a/docs/guide/contributing.rst +++ b/docs/guide/contributing.rst @@ -19,47 +19,47 @@ Reporting Bugs First, check the :ref:`Language Limitations` section. -Next, try the :vlopt:`--debug` option. This will enable additional -internal assertions, and may help identify the problem. +Next, try the :vlopt:`--debug` option. This will enable additional internal +assertions, and may help identify the problem. Finally, reduce your code to the smallest possible routine that exhibits -the bug (see: :ref:`Minimizing bug-inducing code`). Even better, create -a test in the :file:`test_regress/t` directory, as follows: +the bug (see: :ref:`Minimizing bug-inducing code`). Even better, create a +test in the :file:`test_regress/t` directory, as follows: .. code-block:: bash - cd test_regress - cp -p t/t_EXAMPLE.py t/t_BUG.py - cp -p t/t_EXAMPLE.v t/t_BUG.v + cd test_regress + cp -p t/t_EXAMPLE.py t/t_BUG.py + cp -p t/t_EXAMPLE.v t/t_BUG.v There are many hints on how to write a good test in the :file:`test_regress/driver.py` documentation which can be seen by running: .. code-block:: bash - cd $VERILATOR_ROOT # Need the original distribution kit - test_regress/driver.py --help + cd $VERILATOR_ROOT # Need the original distribution kit + test_regress/driver.py --help Edit :file:`t/t_BUG.py` to suit your example; you can do anything you want in the Verilog code there; just make sure it retains the single clk input -and no outputs. Now, the following should fail: +and no outputs. Now, the following should fail: .. code-block:: bash - cd $VERILATOR_ROOT # Need the original distribution kit - cd test_regress - t/t_BUG.py # Run on Verilator - t/t_BUG.py --debug # Run on Verilator, passing --debug to Verilator - t/t_BUG.py --vcs # Run on VCS simulator - t/t_BUG.py --nc|--iv|--ghdl # Likewise on other simulators + cd $VERILATOR_ROOT # Need the original distribution kit + cd test_regress + t/t_BUG.py # Run on Verilator + t/t_BUG.py --debug # Run on Verilator, passing --debug to Verilator + t/t_BUG.py --vcs # Run on VCS simulator + t/t_BUG.py --nc|--iv|--ghdl # Likewise on other simulators The test driver accepts a number of options, many of which mirror the main Verilator options. For example the previous test could have been run with -debugging enabled. The full set of test options can be seen by running +debugging enabled. The full set of test options can be seen by running :command:`driver.py --help` as shown above. Finally, report the bug at `Verilator Issues -`_. The bug will become publicly visible; if +`_. The bug will become publicly visible; if this is unacceptable, mail the bug report to ``wsnyder@wsnyder.org``. .. _minimizing bug-inducing code: @@ -73,12 +73,12 @@ caused by a complex interaction of many parts of the design, and it is not clear which parts are necessary to reproduce the bug. In these cases, an Open Source tool called `sv-bugpoint `_ can be used to automatically -reduce a SystemVerilog design to the smallest possible reproducer. -It can be used to automatically reduce a design with hundreds of thousands of +reduce a SystemVerilog design to the smallest possible reproducer. It can +be used to automatically reduce a design with hundreds of thousands of lines to a minimal test case while preserving the bug-inducing behavior. With :vlopt:`--debug` or :vlopt:`--dump-inputs`, Verilator will write a -*{prefix}*\ __inputs\ .vpp file which has all of the individual input files +*{prefix}*\ __inputs.vpp file which has all of the individual input files combined and pre-processed, this is often useful as the input design into `sv-bugpoint`. @@ -88,4 +88,5 @@ information on how to use `sv-bugpoint`. .. Contributing .. ============ + .. include:: ../CONTRIBUTING.rst diff --git a/docs/guide/contributors.rst b/docs/guide/contributors.rst index 25e7e54f4..dd5676cce 100644 --- a/docs/guide/contributors.rst +++ b/docs/guide/contributors.rst @@ -177,24 +177,24 @@ Historical Origins ================== Verilator was conceived in 1994 by Paul Wasson at the Core Logic Group at -Digital Equipment Corporation. The Verilog code that was converted to C -was then merged with a C-based CPU model of the Alpha processor and -simulated in a C-based environment called CCLI. +Digital Equipment Corporation. The Verilog code that was converted to C was +then merged with a C-based CPU model of the Alpha processor and simulated +in a C-based environment called CCLI. In 1995 Verilator started being used for Multimedia and Network Processor -development inside Digital. Duane Galbi took over the active development -of Verilator, and added several performance enhancements, and CCLI was -still being used as the shell. +development inside Digital. Duane Galbi took over the active development of +Verilator, and added several performance enhancements, and CCLI was still +being used as the shell. In 1998, through the efforts of existing DECies, mainly Duane Galbi, -Digital graciously agreed to release the source code. (Subject to the code +Digital graciously agreed to release the source code. (Subject to the code not being resold, which is compatible with the GNU Public License.) -In 2001, Wilson Snyder took the kit, added a SystemC mode, and called -it Verilator2. This was the first packaged public release. +In 2001, Wilson Snyder took the kit, added a SystemC mode, and called it +Verilator2. This was the first packaged public release. In 2002, Wilson Snyder created Verilator 3.000 by rewriting Verilator from -scratch in C++. This added many optimizations, yielding about a 2-5x +scratch in C++. This added many optimizations, yielding about a 2-5x performance gain. In 2009, major SystemVerilog and DPI language support was added. diff --git a/docs/guide/copyright.rst b/docs/guide/copyright.rst index e83fcc1ed..c34a6dd27 100644 --- a/docs/guide/copyright.rst +++ b/docs/guide/copyright.rst @@ -5,8 +5,7 @@ Copyright ********* -The latest version of Verilator is available from `https://verilator.org -`_. +The latest version of Verilator is available from https://verilator.org. Copyright 2003-2025 by Wilson Snyder. This program is free software; you can redistribute it and/or modify the Verilator internals under the terms diff --git a/docs/guide/deprecations.rst b/docs/guide/deprecations.rst index 1d7f85f75..459ec44e0 100644 --- a/docs/guide/deprecations.rst +++ b/docs/guide/deprecations.rst @@ -7,22 +7,23 @@ Deprecations The following deprecated items are scheduled for future removal: C++14 compiler support - Verilator currently requires a C++20 or newer compiler for timing, and a - C++14 or newer compiler for both compiling Verilator and compiling - Verilated models with --no-timing. + Verilator currently requires a C++20 or newer compiler for timing, and a + C++14 or newer compiler for both compiling Verilator and compiling + Verilated models with --no-timing. - Verilator will require C++20 or newer compilers for both compiling - Verilator and compiling all Verilated models no sooner than May 2025. - (Likely to be removed shortly after GitHub removes Ubuntu 20.04 - continuous-integration action runners, which are used to test the older - C++ standard). + Verilator will require C++20 or newer compilers for both compiling + Verilator and compiling all Verilated models no sooner than May 2025. + (Likely to be removed shortly after GitHub removes Ubuntu 20.04 + continuous-integration action runners, which are used to test the older + C++ standard). XML output - Verilator currently supports XML parser output (enabled with `--xml-only`). - Support for `--xml-*` options will be deprecated no sooner than January 2026. + Verilator currently supports XML parser output (enabled with + `--xml-only`). Support for `--xml-*` options will be deprecated no + sooner than January 2026. `--make cmake` - The `--make cmake` options is deprecated and will be removed no sooner than - January 2026. Use `--make json` instead. Note that the CMake integration - shipping with Verilator (verilator-config.mk) already uses `--make json` so - no changes are necessary if using that. + The `--make cmake` options is deprecated and will be removed no sooner + than January 2026. Use `--make json` instead. Note that the CMake + integration shipping with Verilator (verilator-config.mk) already uses + `--make json` so no changes are necessary if using that. diff --git a/docs/guide/environment.rst b/docs/guide/environment.rst index f70d35763..ef1ac38b3 100644 --- a/docs/guide/environment.rst +++ b/docs/guide/environment.rst @@ -10,14 +10,14 @@ associated programs. .. option:: LD_LIBRARY_PATH A generic Linux/OS variable specifying what directories have shared - object (.so) files. This path should include SystemC and other - shared objects needed at simulation runtime. + object (.so) files. This path should include SystemC and other shared + objects needed at simulation runtime. .. option:: MAKE Names the executable of the make command invoked when using the - :vlopt:`--build` option. Some operating systems may require "gmake" to - this variable to launch GNU make. If this variable is not specified, + :vlopt:`--build` option. Some operating systems may require "gmake" to + this variable to launch GNU make. If this variable is not specified, "make" is used. .. option:: MAKEFLAGS @@ -29,33 +29,33 @@ associated programs. .. option:: OBJCACHE Optionally specifies a caching or distribution program to place in front - of all runs of the C++ compiler. For example, "ccache" or "sccache". If using - :command:`distcc` or :command:`icecc`/:command:`icecream`, they would - generally be run under :command:`ccache`; see the documentation for - those programs. If OBJCACHE is not set, and at configure time ccache + of all runs of the C++ compiler. For example, "ccache" or "sccache". If + using :command:`distcc` or :command:`icecc`/:command:`icecream`, they + would generally be run under :command:`ccache`; see the documentation + for those programs. If OBJCACHE is not set, and at configure time ccache was present, ccache will be used as a default. .. option:: SYSTEMC - Deprecated. Used only if :option:`SYSTEMC_INCLUDE` or - :option:`SYSTEMC_LIBDIR` is not set. If set, specifies the directory - containing the SystemC distribution. If not specified, it will come - from a default optionally specified at configure time (before Verilator - was compiled). + Deprecated. Used only if :option:`SYSTEMC_INCLUDE` or + :option:`SYSTEMC_LIBDIR` is not set. If set, specifies the directory + containing the SystemC distribution. If not specified, it will come from + a default optionally specified at configure time (before Verilator was + compiled). .. option:: SYSTEMC_ARCH - Deprecated. Used only if :option:`SYSTEMC_LIBDIR` is not set. - Specifies the architecture name used by the SystemC kit. This is the - part after the dash in the "lib-{...}" directory name created by a - :command:`make` in the SystemC distribution. If not set, Verilator will - try to intuit the proper setting, or use the default optionally - specified at configure time (before Verilator was compiled). + Deprecated. Used only if :option:`SYSTEMC_LIBDIR` is not set. Specifies + the architecture name used by the SystemC kit. This is the part after + the dash in the "lib-{...}" directory name created by a :command:`make` + in the SystemC distribution. If not set, Verilator will try to intuit + the proper setting, or use the default optionally specified at configure + time (before Verilator was compiled). .. option:: SYSTEMC_CXX_FLAGS Specifies additional flags that are required to be passed to GCC when - building the SystemC model. System 2.3.0 may need this set to + building the SystemC model. System 2.3.0 may need this set to "-pthread". .. option:: SYSTEMC_INCLUDE @@ -67,27 +67,27 @@ associated programs. .. option:: SYSTEMC_LIBDIR - If set, specifies the directory containing the libsystemc.a library. If + If set, specifies the directory containing the libsystemc.a library. If not specified, it will come from a default optionally specified at configure time (before Verilator was compiled), or computed from SYSTEMC/lib-SYSTEMC_ARCH. .. option:: VERILATOR_BIN - If set, specifies an alternative name of the ``verilator`` binary. May + If set, specifies an alternative name of the ``verilator`` binary. May be used for debugging and selecting between multiple operating system builds. .. option:: VERILATOR_COVERAGE_BIN If set, specifies an alternative name of the ``verilator_coverage`` - binary. May be used for debugging and selecting between multiple + binary. May be used for debugging and selecting between multiple operating system builds. .. option:: VERILATOR_GDB If set, the command to run when using the :vlopt:`--gdb` option, such as - "ddd". If not specified, it will use "gdb". + "ddd". If not specified, it will use "gdb". .. option:: VERILATOR_ROOT @@ -110,7 +110,7 @@ associated programs. If you are using a pre-compiled Verilator package, you should not need to set ``VERILATOR_ROOT`` - the value embedded in the binary should be - correct. In fact this option *does not work* with Verilator packages + correct. In fact this option *does not work* with Verilator packages that have been installed with ``make install``. If a Verilator package has been installed using ``./configure --prefix=/some/path && make install`` and then moved to another location, you cannot use @@ -121,13 +121,15 @@ associated programs. .. option:: VERILATOR_SOLVER If set, the command to run as a constrained randomization backend, such - as :command:`cvc4 --lang=smt2 --incremental`. If not specified, it will use - the one supplied or found during configure, or :command:`z3 --in` if empty. + as :command:`cvc4 --lang=smt2 --incremental`. If not specified, it will + use the one supplied or found during configure, or :command:`z3 --in` if + empty. .. option:: VERILATOR_VALGRIND - If set, the command to run when using the :vlopt:`--valgrind` option, such as - "valgrind --tool=callgrind". If not specified, it will use "valgrind". + If set, the command to run when using the :vlopt:`--valgrind` option, + such as "valgrind --tool=callgrind". If not specified, it will use + "valgrind". Make Variables @@ -146,7 +148,7 @@ set by passing them to make e.g. ``make CXX=my-gcc ...``. Optionally overrides the default compiler binary used by the Verilated makefiles. If CXX is not set, the version found at configure time is - used. Note the default flags passed to the compiler are determined at + used. Note the default flags passed to the compiler are determined at configuration time, so changing the CXX compiler version using this variable, as opposed to passing it at configuration time, may not give desired results. @@ -155,7 +157,7 @@ set by passing them to make e.g. ``make CXX=my-gcc ...``. Optionally overrides the default linker binary used by the Verilated makefiles. If LINK is not set, the version found at configure time is - used. Note the default flags passed to the linker are determined at + used. Note the default flags passed to the linker are determined at configuration time, so changing the LINK version using this variable, as opposed to passing it at configuration time, may not give desired results. diff --git a/docs/guide/example_binary.rst b/docs/guide/example_binary.rst index 1dfa4b62c..c8d656b52 100644 --- a/docs/guide/example_binary.rst +++ b/docs/guide/example_binary.rst @@ -6,9 +6,9 @@ Example Create-Binary Execution =============================== -We'll compile this SystemVerilog example into a Verilated simulation binary. For -an example that discusses the next level of detail see :ref:`Example C++ -Execution`. +We'll compile this SystemVerilog example into a Verilated simulation +binary. For an example that discusses the next level of detail see +:ref:`Example C++ Execution`. .. include:: example_common_install.rst @@ -16,20 +16,20 @@ Now, let's create an example Verilog file: .. code-block:: bash - mkdir test_our - cd test_our + mkdir test_our + cd test_our - cat >our.v <<'EOF' - module our; - initial begin $display("Hello World"); $finish; end - endmodule - EOF + cat >our.v <<'EOF' + module our; + initial begin $display("Hello World"); $finish; end + endmodule + EOF Now we run Verilator on our little example. .. code-block:: bash - verilator --binary -j 0 -Wall our.v + verilator --binary -j 0 -Wall our.v Breaking this command down: @@ -48,16 +48,16 @@ And now we run it: .. code-block:: bash - obj_dir/Vour + obj_dir/Vour And we get as output: .. code-block:: bash - Hello World - - our.v:2: Verilog $finish + Hello World + - our.v:2: Verilog $finish You're better off using a Makefile to run the steps for you, so when your -source changes, it will automatically run all of the appropriate steps. To -aid this, Verilator can create a makefile dependency file. For examples +source changes, it will automatically run all of the appropriate steps. To +aid this, Verilator can create a makefile dependency file. For examples that do this, see the :file:`examples` directory in the distribution. diff --git a/docs/guide/example_cc.rst b/docs/guide/example_cc.rst index 1df01228c..7278d7270 100644 --- a/docs/guide/example_cc.rst +++ b/docs/guide/example_cc.rst @@ -6,7 +6,7 @@ Example C++ Execution ===================== -We'll compile this example into C++. For an extended and commented version +We'll compile this example into C++. For an extended and commented version of what this C++ code is doing, see :file:`examples/make_tracing_c/sim_main.cpp` in the distribution. @@ -16,34 +16,34 @@ Now, let's create an example Verilog and C++ wrapper file: .. code-block:: bash - mkdir test_our - cd test_our + mkdir test_our + cd test_our - cat >our.v <<'EOF' - module our; - initial begin $display("Hello World"); $finish; end - endmodule - EOF + cat >our.v <<'EOF' + module our; + initial begin $display("Hello World"); $finish; end + endmodule + EOF - cat >sim_main.cpp <<'EOF' - #include "Vour.h" - #include "verilated.h" - int main(int argc, char** argv) { - VerilatedContext* contextp = new VerilatedContext; - contextp->commandArgs(argc, argv); - Vour* top = new Vour{contextp}; - while (!contextp->gotFinish()) { top->eval(); } - delete top; - delete contextp; - return 0; - } - EOF + cat >sim_main.cpp <<'EOF' + #include "Vour.h" + #include "verilated.h" + int main(int argc, char** argv) { + VerilatedContext* contextp = new VerilatedContext; + contextp->commandArgs(argc, argv); + Vour* top = new Vour{contextp}; + while (!contextp->gotFinish()) { top->eval(); } + delete top; + delete contextp; + return 0; + } + EOF Now we run Verilator on our little example; .. code-block:: bash - verilator --cc --exe --build -j 0 -Wall sim_main.cpp our.v + verilator --cc --exe --build -j 0 -Wall sim_main.cpp our.v Breaking this command down: @@ -70,7 +70,7 @@ Once Verilator completes we can see the generated C++ code under the .. code-block:: bash - ls -l obj_dir + ls -l obj_dir (See :ref:`Files Read/Written` for descriptions of some of the files that were created.) @@ -79,16 +79,16 @@ And now we run it: .. code-block:: bash - obj_dir/Vour + obj_dir/Vour And we get as output: .. code-block:: bash - Hello World - - our.v:2: Verilog $finish + Hello World + - our.v:2: Verilog $finish You're better off using a Makefile to run the steps for you, so when your -source changes, it will automatically run all of the appropriate steps. To -aid this, Verilator can create a makefile dependency file. For examples +source changes, it will automatically run all of the appropriate steps. To +aid this, Verilator can create a makefile dependency file. For examples that do this, see the :file:`examples` directory in the distribution. diff --git a/docs/guide/example_common_install.rst b/docs/guide/example_common_install.rst index ecf9f813b..9cff39c4a 100644 --- a/docs/guide/example_common_install.rst +++ b/docs/guide/example_common_install.rst @@ -1,16 +1,16 @@ .. Copyright 2003-2025 by Wilson Snyder. .. SPDX-License-Identifier: LGPL-3.0-only OR Artistic-2.0 -First you need Verilator installed, see :ref:`Installation`. In brief, if +First you need Verilator installed, see :ref:`Installation`. In brief, if you installed Verilator using the package manager of your operating system, or did a :command:`make install` to place Verilator into your default path, you do not need anything special in your environment, and should not have -VERILATOR_ROOT set. However, if you installed Verilator from sources and +VERILATOR_ROOT set. However, if you installed Verilator from sources and want to run Verilator out of where you compiled Verilator, you need to point to the kit: .. code-block:: bash - # See above; don't do this if using an OS-distributed Verilator - export VERILATOR_ROOT=/path/to/where/verilator/was/installed - export PATH=$VERILATOR_ROOT/bin:$PATH + # See above; don't do this if using an OS-distributed Verilator + export VERILATOR_ROOT=/path/to/where/verilator/was/installed + export PATH=$VERILATOR_ROOT/bin:$PATH diff --git a/docs/guide/example_dist.rst b/docs/guide/example_dist.rst index fa042ff3b..c7c619274 100644 --- a/docs/guide/example_dist.rst +++ b/docs/guide/example_dist.rst @@ -6,37 +6,47 @@ Examples in the Distribution ============================ -See the ``examples/`` directory that is part of the distribution, and -is installed (in an OS-specific place, often in e.g. -``/usr/local/share/verilator/examples``). These examples include: +See the ``examples/`` directory that is part of the distribution, and is +installed (in an OS-specific place, often in e.g. +``/usr/local/share/verilator/examples``). These examples include: examples/make_hello_binary Example GNU-make simple Verilog->binary conversion + examples/make_hello_c Example GNU-make simple Verilog->C++ conversion + examples/make_hello_sc Example GNU-make simple Verilog->SystemC conversion + examples/make_tracing_c Example GNU-make Verilog->C++ with tracing + examples/make_tracing_sc Example GNU-make Verilog->SystemC with tracing + examples/make_protect_lib Example using --protect-lib + examples/cmake_hello_c Example building make_hello_c with CMake + examples/cmake_hello_sc Example building make_hello_sc with CMake + examples/cmake_tracing_c Example building make_tracing_c with CMake + examples/cmake_tracing_sc Example building make_tracing_sc with CMake + examples/cmake_protect_lib Example building make_protect_lib with CMake To run an example copy the example to a new directory and run it. -:: +.. code-block:: bash - cp -rp {path_to}/examples/make_hello_c make_hello_c - cd make_hello_c - make + cp -rp {path_to}/examples/make_hello_c make_hello_c + cd make_hello_c + make diff --git a/docs/guide/example_sc.rst b/docs/guide/example_sc.rst index 3c448e8bc..98174449d 100644 --- a/docs/guide/example_sc.rst +++ b/docs/guide/example_sc.rst @@ -15,58 +15,58 @@ Now, let's create an example Verilog, and SystemC wrapper file: .. code-block:: bash - mkdir test_our_sc - cd test_our_sc + mkdir test_our_sc + cd test_our_sc - cat >our.v <<'EOF' - module our (clk); - input clk; // Clock is required to get initial activation - always @(posedge clk) - begin $display("Hello World"); $finish; end - endmodule - EOF + cat >our.v <<'EOF' + module our (clk); + input clk; // Clock is required to get initial activation + always @(posedge clk) + begin $display("Hello World"); $finish; end + endmodule + EOF - cat >sc_main.cpp <<'EOF' - #include "Vour.h" - using namespace sc_core; - int sc_main(int argc, char** argv) { - Verilated::commandArgs(argc, argv); - sc_clock clk{"clk", 10, SC_NS, 0.5, 3, SC_NS, true}; - Vour* top = new Vour{"top"}; - top->clk(clk); - while (!Verilated::gotFinish()) { sc_start(1, SC_NS); } - delete top; - return 0; - } - EOF + cat >sc_main.cpp <<'EOF' + #include "Vour.h" + using namespace sc_core; + int sc_main(int argc, char** argv) { + Verilated::commandArgs(argc, argv); + sc_clock clk{"clk", 10, SC_NS, 0.5, 3, SC_NS, true}; + Vour* top = new Vour{"top"}; + top->clk(clk); + while (!Verilated::gotFinish()) { sc_start(1, SC_NS); } + delete top; + return 0; + } + EOF Now we run Verilator on our little example: .. code-block:: bash - verilator --sc --exe -Wall sc_main.cpp our.v + verilator --sc --exe -Wall sc_main.cpp our.v This example does not use --build, therefore we need to explicitly compile it: .. code-block:: bash - make -j -C obj_dir -f Vour.mk Vour + make -j -C obj_dir -f Vour.mk Vour And now we run it: .. code-block:: bash - obj_dir/Vour + obj_dir/Vour And we get, after the SystemC banner, the same output as the C++ example: .. code-block:: bash - SystemC 2.3.3-Accellera + SystemC 2.3.3-Accellera - Hello World - - our.v:4: Verilog $finish + Hello World + - our.v:4: Verilog $finish Really, you're better off using a Makefile to run the steps for you so when your source changes it will automatically run all of the appropriate steps. diff --git a/docs/guide/exe_sim.rst b/docs/guide/exe_sim.rst index e79bcf537..1d572ffdb 100644 --- a/docs/guide/exe_sim.rst +++ b/docs/guide/exe_sim.rst @@ -8,7 +8,7 @@ Simulation Runtime Arguments The following are the arguments that may be passed to a Verilated executable, provided that executable calls -:code:`VerilatedContext*->commandArgs(argc, argv)`. +``VerilatedContext*->commandArgs(argc, argv)``. All simulation runtime arguments begin with "+verilator", so that the user's executable may skip over all "+verilator" arguments when parsing its @@ -18,15 +18,16 @@ Summary: .. include:: ../_build/gen/args_verilated.rst +Options: .. option:: +verilator+coverage+file+ When a model was Verilated using :vlopt:`--coverage`, sets the filename - to write coverage data into. Defaults to :file:`coverage.dat`. + to write coverage data into. Defaults to :file:`coverage.dat`. .. option:: +verilator+debug - Enable simulation runtime debugging. Equivalent to + Enable simulation runtime debugging. Equivalent to :vlopt:`+verilator+debugi+4 <+verilator+debugi+\>`. To be useful, the model typically must first be compiled with debug @@ -50,12 +51,12 @@ Summary: .. option:: +verilator+noassert Disable assert checking per runtime argument. This is the same as - calling :code:`VerilatedContext*->assertOn(false)` in the model. + calling ``VerilatedContext*->assertOn(false)`` in the model. .. option:: +verilator+prof+exec+file+ When a model was Verilated using :vlopt:`--prof-exec`, sets the - simulation runtime filename to dump to. Defaults to + simulation runtime filename to dump to. Defaults to :file:`profile_exec.dat`. .. option:: +verilator+prof+exec+start+ @@ -72,9 +73,9 @@ Summary: When a model was Verilated using :vlopt:`--prof-exec`, after $time reaches :vlopt:`+verilator+prof+exec+start+\`, Verilator will warm up the profiling for this number of eval() calls, then will capture - the profiling of this number of eval() calls. Defaults to 2, which - makes sense for a single-clock-domain module where it's typical to want - to capture one posedge eval() and one negedge eval(). + the profiling of this number of eval() calls. Defaults to 2, which makes + sense for a single-clock-domain module where it's typical to want to + capture one posedge eval() and one negedge eval(). .. option:: +verilator+prof+threads+file+ @@ -94,7 +95,7 @@ Summary: .. option:: +verilator+prof+vlt+file+ When a model was Verilated using :vlopt:`--prof-pgo`, sets the - profile-guided optimization data runtime filename to dump to. Defaults + profile-guided optimization data runtime filename to dump to. Defaults to :file:`profile.vlt`. .. option:: +verilator+quiet @@ -104,15 +105,15 @@ Summary: .. option:: +verilator+rand+reset+ - When a model was Verilated using - :vlopt:`--x-initial unique <--x-initial>`, sets the simulation runtime - initialization technique. 0 = Reset to zeros. 1 = Reset to all-ones. 2 - = Randomize. See :ref:`Unknown States`. + When a model was Verilated using :vlopt:`--x-initial unique + <--x-initial>`, sets the simulation runtime initialization technique. 0 + = Reset to zeros. 1 = Reset to all-ones. 2 = Randomize. See + :ref:`Unknown States`. .. option:: +verilator+seed+ For $random and :vlopt:`--x-initial unique <--x-initial>`, set the - simulation runtime random seed value. If zero or not specified picks a + simulation runtime random seed value. If zero or not specified picks a value from the system random number generator. .. option:: +verilator+V diff --git a/docs/guide/exe_verilator.rst b/docs/guide/exe_verilator.rst index 3e5337089..7d73e896d 100644 --- a/docs/guide/exe_verilator.rst +++ b/docs/guide/exe_verilator.rst @@ -21,18 +21,18 @@ Summary: the appropriate directory to your makefile's VPATH to find the file. If any files are specified in this way, Verilator will include a make - rule that uses these files when linking the module's executable. This + rule that uses these files when linking the module's executable. This generally is only useful when used with the :vlopt:`--exe` option. .. option:: Used with :vlopt:`--exe` to specify optional C++ files to be linked in - with the Verilog code. The file path should either be absolute, or + with the Verilog code. The file path should either be absolute, or relative to where the make will be executed from, or add to your makefile's VPATH the appropriate directory to find the file. See also :vlopt:`-CFLAGS` and :vlopt:`-LDFLAGS` options, which are - useful when the C++ files need special compiler flags. The compiler + useful when the C++ files need special compiler flags. The compiler flags add by default `-DVERILATOR=1`, so an `#ifdef VERILATOR` may be used to conditionally preprocess .cpp code for different simulators. @@ -83,7 +83,7 @@ Summary: ```begin_keywords`` is a SystemVerilog construct, which specifies *only* the set of keywords to be recognized. This also controls some - error messages that vary between language standards. At present, + error messages that vary between language standards. At present, Verilator tends to be overly permissive, e.g., it will accept many grammar and other semantic extensions which might not be legal when set to an older standard. @@ -94,8 +94,8 @@ Summary: Rarely needed - for developer use. With `--aslr`, do not change the system default as to using Linux address space layout randomization - (ASLR). With `--no-aslr` attempt to disable ASLR. If not specified, - ASLR will be disabled only when using :vlopt:`--debug` (or similar + (ASLR). With `--no-aslr` attempt to disable ASLR. If not specified, ASLR + will be disabled only when using :vlopt:`--debug` (or similar debug-related options), so that pointers have more deterministic values, aiding repeatability. @@ -115,18 +115,18 @@ Summary: .. option:: --autoflush - After every $display or $fdisplay, flush the output stream. This - ensures that messages will appear immediately but may reduce - performance. For best performance, call :code:`fflush(stdout)` - occasionally in the C++ main loop. Defaults to off, which will buffer - output as provided by the normal C/C++ standard library IO. + After every $display or $fdisplay, flush the output stream. This ensures + that messages will appear immediately but may reduce performance. For + best performance, call ``fflush(stdout)`` occasionally in the C++ main + loop. Defaults to off, which will buffer output as provided by the + normal C/C++ standard library IO. .. option:: --bbox-sys - Black box any unknown $system task or function calls. System tasks will + Black box any unknown $system task or function calls. System tasks will become no-operations, and system functions will be replaced with unsized - zero. Arguments to such functions will be parsed, but not otherwise - checked. This prevents errors when linting in the presence of + zero. Arguments to such functions will be parsed, but not otherwise + checked. This prevents errors when linting in the presence of company-specific PLI calls. Using this argument will likely cause incorrect simulation. @@ -135,14 +135,14 @@ Summary: Black box some unsupported language features, currently UDP tables, the cmos and tran gate primitives, deassign statements, and mixed edge - errors. This may enable linting of the rest of the design even when + errors. This may enable linting of the rest of the design even when unsupported constructs are present. Using this argument will likely cause incorrect simulation. .. option:: --binary - Create a Verilated simulator binary. Alias for :vlopt:`--main` + Create a Verilated simulator binary. Alias for :vlopt:`--main` :vlopt:`--exe` :vlopt:`--build` :vlopt:`--timing`. See also :vlopt:`-j`. @@ -151,7 +151,7 @@ Summary: After generating the SystemC/C++ code, Verilator will invoke the toolchain to build the model library (and executable when :vlopt:`--exe` - is also used). Verilator manages the build itself, and for this --build + is also used). Verilator manages the build itself, and for this --build requires GNU Make to be available on the platform. :vlopt:`--build` cannot be specified when using :vlopt:`-E`, @@ -159,20 +159,21 @@ Summary: .. option:: --build-dep-bin - Rarely needed. When a dependency (.d) file is created, this filename + Rarely needed. When a dependency (.d) file is created, this filename will become a source dependency, such that a change in this binary will - have ``make`` rebuild the output files. Defaults to the full path to - the Verilator binary. + have ``make`` rebuild the output files. Defaults to the full path to the + Verilator binary. This option was named `--bin` before version 4.228. .. option:: --build-jobs - Specify the level of parallelism for :vlopt:`--build`. If zero, uses the - number of threads available to the process, which is the number of threads - assigned by processor affinity (e.g. using `numactl`), or the number of - threads in the host hardware if unspecified. Otherwise, the must be - a positive integer specifying the maximum number of parallel build jobs. + Specify the level of parallelism for :vlopt:`--build`. If zero, uses the + number of threads available to the process, which is the number of + threads assigned by processor affinity (e.g. using `numactl`), or the + number of threads in the host hardware if unspecified. Otherwise, the + must be a positive integer specifying the maximum number of + parallel build jobs. If not provided, and :vlopt:`-j` is provided, the :vlopt:`-j` value is used. @@ -207,7 +208,7 @@ Summary: With :vlopt:`--clk`, the specified signal is marked as a clock signal. The provided signal name is specified using a RTL hierarchy path. For - example, v.foo.bar. If the signal is the input to the top-module, then + example, v.foo.bar. If the signal is the input to the top-module, then directly provide the signal name. Alternatively, use a :option:`/*verilator&32;clocker*/` metacomment in RTL file to mark the signal directly. @@ -233,26 +234,26 @@ Summary: .. option:: --compiler - Enables workarounds for the specified C++ compiler (list below). This + Enables workarounds for the specified C++ compiler (list below). This does not change any performance tuning options, but it may in the - future. This also does not change default compiler flags; these are + future. This also does not change default compiler flags; these are determined when Verilator was configured. clang - Tune for clang. This may reduce execution speed as it enables several - workarounds to avoid silly hard-coded limits in clang. This includes + Tune for clang. This may reduce execution speed as it enables several + workarounds to avoid silly hard-coded limits in clang. This includes breaking deep structures as for msvc, as described below. gcc Tune for GNU C++, although generated code should work on almost any - compliant C++ compiler. Currently, the default. + compliant C++ compiler. Currently, the default. msvc - Tune for Microsoft Visual C++. This may reduce execution speed as it + Tune for Microsoft Visual C++. This may reduce execution speed as it enables several workarounds to avoid silly hard-coded limits in - MSVC++. This includes breaking deeply nested parenthesized - expressions into sub-expressions to avoid error C1009, and breaking - deep blocks into functions to avoid error C1061. + MSVC++. This includes breaking deeply nested parenthesized expressions + into sub-expressions to avoid error C1009, and breaking deep blocks + into functions to avoid error C1061. .. option:: --compiler-include @@ -263,8 +264,8 @@ Summary: .. option:: --converge-limit - Rarely needed. Specifies the maximum number of runtime iterations - before creating a model failed to converge error. Defaults to 100. + Rarely needed. Specifies the maximum number of runtime iterations before + creating a model failed to converge error. Defaults to 100. .. option:: --coverage @@ -277,8 +278,8 @@ Summary: .. option:: --coverage-expr-max - Rarely needed. Specifies the maximum number of permutations able to be - covered for a given expression. Defaults to 32. Increasing may slow + Rarely needed. Specifies the maximum number of permutations able to be + covered for a given expression. Defaults to 32. Increasing may slow coverage simulations and make analyzing the results unwieldy. .. option:: --coverage-line @@ -287,38 +288,40 @@ Summary: .. option:: --coverage-max-width - Rarely needed. Specify the maximum bit width of a signal - subject to toggle coverage. Defaults to 256, as covering large vectors - may greatly slow coverage simulations. + Rarely needed. Specify the maximum bit width of a signal subject to + toggle coverage. Defaults to 256, as covering large vectors may greatly + slow coverage simulations. .. option:: --coverage-toggle - Enables adding signal toggle coverage. See :ref:`Toggle Coverage`. + Enables adding signal toggle coverage. See :ref:`Toggle Coverage`. .. option:: --coverage-underscore Enable coverage of signals that start with an underscore. Normally, - these signals are not covered. See also :vlopt:`--trace-underscore` + these signals are not covered. See also :vlopt:`--trace-underscore` option. .. option:: --coverage-user - Enables adding user-inserted functional coverage. See :ref:`User Coverage`. + Enables adding user-inserted functional coverage. See :ref:`User + Coverage`. .. option:: -D= - Defines the given preprocessor symbol. Similar to + Defines the given preprocessor symbol. Similar to :vlopt:`+define <+define+>`, but does not allow multiple - definitions with a single option using plus signs. "+define" is relatively - standard across Verilog tools, while "-D" is similar to + definitions with a single option using plus signs. ``+define`` is + relatively standard across Verilog tools, while ``-D`` is similar to :command:`gcc -D`. .. option:: --debug Run under debug. - * Select the debug executable of Verilator (if available). This - generally is a less-optimized binary with symbols present (so GDB can be used on it). + * Select the debug executable of Verilator (if available). This + generally is a less-optimized binary with symbols present (so GDB can + be used on it). * Enable debugging messages (equivalent to :vlopt:`--debugi 3 <--debugi>`). * Enable internal assertions (equivalent to :vlopt:`--debug-check`). * Enable intermediate form dump files (equivalent to @@ -330,8 +333,8 @@ Summary: .. option:: --debug-check - Rarely needed. Enable internal debugging assertion checks, without - changing debug verbosity. Enabled automatically with :vlopt:`--debug` + Rarely needed. Enable internal debugging assertion checks, without + changing debug verbosity. Enabled automatically with :vlopt:`--debug` option. .. option:: --no-debug-leak @@ -348,16 +351,16 @@ Summary: .. option:: --debugi - Rarely needed - for developer use. Set the internal debugging level + Rarely needed - for developer use. Set the internal debugging level globally to the specified debug level (1-10). Higher levels produce more detailed messages. .. option:: --debugi- - Rarely needed - for developer use. Set the specified Verilator source + Rarely needed - for developer use. Set the specified Verilator source file to the specified level (e.g., :vlopt:`--debugi-V3Width 9 <--debugi>`). Higher levels produce more - detailed messages. See :vlopt:`--debug` for other implications of + detailed messages. See :vlopt:`--debug` for other implications of enabling debug. .. option:: --no-decoration @@ -373,7 +376,7 @@ Summary: Minimize comments, white space, symbol names, and other decorative items, at the cost of reduced readability. This may assist C++ compile times. This will not typically change the ultimate model's - performance, but may in some cases. See also :vlopt:`--no-decoration` + performance, but may in some cases. See also :vlopt:`--no-decoration` option. With "--decorations medium", @@ -384,19 +387,19 @@ Summary: Include comments indicating what caused generation of the following text, including what node pointer (corresponding to :vlopt:`--dump-tree` .tree printed data), and the source Verilog - filename and line number. If subsequent following statements etc have - the same filename/line number these comments are omitted. This - enables easy debug when looking at the C++ code to determine what - Verilog source may be related. As node pointers are not stable - between different Verilator runs, this may harm compile caching and - should only be used for debug. + filename and line number. If subsequent following statements etc have + the same filename/line number these comments are omitted. This enables + easy debug when looking at the C++ code to determine what Verilog + source may be related. As node pointers are not stable between + different Verilator runs, this may harm compile caching and should + only be used for debug. .. option:: --default-language - Select the language used by default when first processing each - Verilog file. The language value must be "VAMS", "1364-1995", - "1364-2001", "1364-2001-noconfig", "1364-2005", "1800-2005", - "1800-2009", "1800-2012", "1800-2017", "1800-2023", or "1800+VAMS". + Select the language used by default when first processing each Verilog + file. The language value must be "VAMS", "1364-1995", "1364-2001", + "1364-2001-noconfig", "1364-2005", "1800-2005", "1800-2009", + "1800-2012", "1800-2017", "1800-2023", or "1800+VAMS". Any language associated with a particular file extension (see the various +*\ ext+ options) will be used in preference to the @@ -405,7 +408,7 @@ Summary: The :vlopt:`--default-language` is only recommended for legacy code using the same language in all source files, as the preferable option is to edit the code to repair new keywords, or add appropriate - :code:`\`begin_keywords`. For legacy mixed-language designs, the various + ``\`begin_keywords``. For legacy mixed-language designs, the various ``+ext+`` options should be used. If no language is specified, either by this option or ``+ext+`` @@ -417,7 +420,7 @@ Summary: .. option:: +define+=[+=][...] Defines the given preprocessor symbol, or multiple symbols if separated - by plus signs. Similar to :vlopt:`-D <-D>`; +define is relatively + by plus signs. Similar to :vlopt:`-D <-D>`; +define is relatively standard across Verilog tools while :vlopt:`-D <-D>` is similar to :command:`gcc -D`. @@ -425,7 +428,7 @@ Summary: Enables diagnostics output into a Static Analysis Results Interchange Format (SARIF) file, a standard, JSON-based format for the output of - static analysis tools such as linters. See + static analysis tools such as linters. See [SARIF](https://sarifweb.azurewebsites.net/), [sarif-tools](https://github.com/microsoft/sarif-tools), and the [SARIF web-based viewer](https://microsoft.github.io/sarif-web-component/). @@ -433,13 +436,13 @@ Summary: .. option:: --diagnostics-sarif-output Specifies the filename for the SARIF output file (`.sarif`) of - :vlopt:`--diagnostics-sarif`. Using this option automatically sets - :vlopt:`--diagnostics-sarif`. If not specified, output defaults to + :vlopt:`--diagnostics-sarif`. Using this option automatically sets + :vlopt:`--diagnostics-sarif`. If not specified, output defaults to :file:`.sarif`. .. option:: --dpi-hdr-only - Only generate the DPI header file. This option does not affect on the + Only generate the DPI header file. This option does not affect on the name or location of the emitted DPI header file, it is output in :vlopt:`--Mdir` as it would be without this option. @@ -461,82 +464,82 @@ Summary: .. option:: --dump-dfg - Rarely needed. Enable dumping DfgGraph .dot debug files with dumping + Rarely needed. Enable dumping DfgGraph .dot debug files with dumping level 3. .. option:: --dump-graph - Rarely needed. Enable dumping V3Graph .dot debug files with dumping - level 3. Before Verilator 4.228, :vlopt:`--dump-tree` used - to include this option. + Rarely needed. Enable dumping V3Graph .dot debug files with dumping + level 3. Before Verilator 4.228, :vlopt:`--dump-tree` used to include + this option. .. option:: --dump-inputs - Rarely needed. Enable dumping a *{prefix}*\ __inputs\ .vpp file which + Rarely needed. Enable dumping a *{prefix}*\ __inputs\ .vpp file which has all of the individual input files combined and pre-processed .. option:: --dump-tree - Rarely needed. Enable dumping Ast .tree debug files with dumping level 3, - which dumps the standard critical stages. For details on the format, see - the Verilator Internals manual. :vlopt:`--dump-tree` is enabled - automatically with :vlopt:`--debug`, so - :vlopt:`--debug --no-dump-tree <--dump-tree>` may be useful if the dump - files are large and not desired. + Rarely needed. Enable dumping Ast .tree debug files with dumping level + 3, which dumps the standard critical stages. For details on the format, + see the Verilator Internals manual. :vlopt:`--dump-tree` is enabled + automatically with :vlopt:`--debug`, so :vlopt:`--debug --no-dump-tree + <--dump-tree>` may be useful if the dump files are large and not + desired. .. option:: --dump-tree-addrids - Rarely needed - for developer use. Replace AST node addresses with - short identifiers in tree dumps to enhance readability. Each unique - pointer value is mapped to a unique identifier, but note that this is - not necessarily unique per node instance as an address might get reused - by a newly allocated node after a node with the same address has been - dumped and then freed. + Rarely needed - for developer use. Replace AST node addresses with short + identifiers in tree dumps to enhance readability. Each unique pointer + value is mapped to a unique identifier, but note that this is not + necessarily unique per node instance as an address might get reused by a + newly allocated node after a node with the same address has been dumped + and then freed. .. option:: --dump-tree-dot - Rarely needed - for developer use. Enable dumping Ast .tree.dot debug + Rarely needed - for developer use. Enable dumping Ast .tree.dot debug files in Graphviz Dot format. This option implies :vlopt:`--dump-tree`, unless :vlopt:`--dumpi-tree` was passed explicitly. .. option:: --dump-tree-json - Rarely needed. Enable dumping Ast .json.tree debug files with dumping level 3, - which dumps the standard critical stages. For details on the format, see - the Verilator Internals manual. + Rarely needed. Enable dumping Ast .json.tree debug files with dumping + level 3, which dumps the standard critical stages. For details on the + format, see the Verilator Internals manual. .. option:: --dumpi- Rarely needed - for developer use. Set the dumping level in the specified Verilator source file to the specified value (e.g., - `--dumpi-V3Order 9`). Level 0 disables dumps and is equivalent to - `--no-dump-`. Level 9 enables the dumping of everything. + `--dumpi-V3Order 9`). Level 0 disables dumps and is equivalent to + `--no-dump-`. Level 9 enables the dumping of everything. .. option:: --dumpi-dfg - Rarely needed - for developer use. Set the internal DfgGraph dumping level - globally to the specified value. + Rarely needed - for developer use. Set the internal DfgGraph dumping + level globally to the specified value. .. option:: --dumpi-graph - Rarely needed - for developer use. Set internal V3Graph dumping level + Rarely needed - for developer use. Set internal V3Graph dumping level globally to the specified value. .. option:: --dumpi-tree - Rarely needed - for developer use. Set internal Ast dumping level + Rarely needed - for developer use. Set internal Ast dumping level globally to the specified value. .. option:: --dumpi-tree-json - Rarely needed - for developer use. Set internal Ast JSON dumping level + Rarely needed - for developer use. Set internal Ast JSON dumping level globally to the specified value. .. option:: -E Preprocess the source code, but do not compile, similar to C++ - preprocessing using :command:`gcc -E`. Output is written to standard - out. Beware of enabling debugging messages, as they will also go to + preprocessing using :command:`gcc -E`. Output is written to standard + out. Beware of enabling debugging messages, as they will also go to standard out. See :vlopt:`--no-std`, which is implied by this. See also :vlopt:`--dump-defines`, :vlopt:`-P`, @@ -551,43 +554,42 @@ Summary: .. option:: --error-limit After this number of errors are encountered during Verilator run, exit. - Warnings are not counted in this limit. Defaults to 50. + Warnings are not counted in this limit. Defaults to 50. It does not affect simulation runtime errors, for those, see :vlopt:`+verilator+error+limit+\`. .. option:: --exe - Generate an executable. You will also need to pass additional .cpp - files on the command line that implement the main loop for your - simulation. + Generate an executable. You will also need to pass additional .cpp files + on the command line that implement the main loop for your simulation. .. option:: --expand-limit - Rarely needed. Fine-tune optimizations to set the maximum size of an + Rarely needed. Fine-tune optimizations to set the maximum size of an expression in 32-bit words to expand into separate word-based statements. .. option:: -F Read the specified file, and act as if all text inside it was specified - as command line arguments. Any relative paths are relative to the - directory containing the specified file. See also :vlopt:`-f` - option. Note :option:`-F` is relatively standard across Verilog tools. + as command line arguments. Any relative paths are relative to the + directory containing the specified file. See also :vlopt:`-f` option. + Note :option:`-F` is relatively standard across Verilog tools. .. option:: -f Read the specified file, and act as if all text inside it was specified - as command line arguments. Any relative paths are relative to the - current directory. See also :vlopt:`-F` option. Note :option:`-f` is + as command line arguments. Any relative paths are relative to the + current directory. See also :vlopt:`-F` option. Note :option:`-f` is relatively standard across Verilog tools. - The file may contain :code:`//` comments which are ignored until the end of - the line. It may also contain :code:`/* .. */` comments which are - ignored, be cautious that wildcards are not handled in -f files, and - that :code:`directory/*` is the beginning of a comment, not a wildcard. - Any :code:`$VAR`, :code:`$(VAR)`, or :code:`${VAR}` will be replaced - with the specified environment variable. + The file may contain ``//`` comments which are ignored until the end of + the line. It may also contain ``/* .. */`` comments which are ignored, + be cautious that wildcards are not handled in -f files, and that + ``directory/*`` is the beginning of a comment, not a wildcard. Any + ``$VAR``, ``$(VAR)``, or ``${VAR}`` will be replaced with the specified + environment variable. .. option:: -fdfg-synthesize-all @@ -595,12 +597,11 @@ Summary: .. option:: -FI - Force include of the specified C++ header file. All generated C++ files - will insert a #include of the specified file before any other - includes. The specified file might be used to contain define prototypes - of custom :code:`VL_VPRINTF` functions, and may need to include - :file:`verilatedos.h` as this file is included before any other standard - includes. + Force include of the specified C++ header file. All generated C++ files + will insert a #include of the specified file before any other includes. + The specified file might be used to contain define prototypes of custom + ``VL_VPRINTF`` functions, and may need to include :file:`verilatedos.h` + as this file is included before any other standard includes. .. option:: --flatten @@ -638,7 +639,7 @@ Summary: .. option:: -fno-dfg Rarely needed. Disable all use of the DFG-based combinational logic - optimizer. Alias for :vlopt:`-fno-dfg-pre-inline`, + optimizer. Alias for :vlopt:`-fno-dfg-pre-inline`, :vlopt:`-fno-dfg-post-inline` and :vlopt:`-fno-dfg-scoped`. .. option:: -fno-dfg-break-cycles @@ -723,32 +724,30 @@ Summary: .. option:: --fslice-element-limit - Rarely needed. Set the maximum array size (number of elements) - for slice optimization to avoid excessive memory usage. + Rarely needed. Set the maximum array size (number of elements) for slice + optimization to avoid excessive memory usage. .. option:: -future0