[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  Voneline
  WFH
General Info
  Papers

Verilator Frequently Asked Questions (FAQ)

Does it run under Windows?

Yes, using Cygwin. Verilated output should also compile under Microsoft Visual C++ Version 7 or newer.

Can you provide binaries?

Verilator is available as a RPM for SuSE and perhaps other systems; this is done by porters and may slightly lag the primary distribution. If there isn't a binary build for your distribution, how about you set one up? Please contact the authors for assistance.

Note people sometimes request binaries when they are having problems with their C++ compiler. Alas, binaries won't help this, as in the end a fully working C++ compiler is required to compile the output of Verilator.

How can Verilator be faster than (name-the-simulator)?

Generally, the implied part of the question is ``... with all of their manpower they can put into it.''

Most commercial simulators have to be Verilog compliant, meaning event driven. This prevents them from being able to reorder blocks and make netlist-style optimizations, which are where most of the gains come from.

Non-compliance shouldn't be scary. Your synthesis program isn't compliant, so your simulator shouldn't have to be -- and Verilator is closer to the synthesis interpretation, so this is a good thing for getting working silicon.

May programs I create with Verilator remain under my own copyright?

Yes, it's just like using GCC on your programs. If you change Verilator itself, you must make the source code available under the GNU Public License. However, the include and generated files use the GNU Lesser Public License, which means that files using them are NOT required to be released.

You also have the option of using the Perl Artistic License, which again does not require you release your Verilog or generated code.

Why is running Verilator so slow?

Verilator needs more memory than the resulting simulator will require, as Verilator creates internally all of the state of the resulting simulator in order to optimize it. If it takes more than a minute or so (and you're not using --debug), see if your machine is paging; most likely you need to run it on a machine with more memory. Verilator is a full 64 bit application and may use more than 4GB, but about 1GB is the maximum typically needed.

How do I generate waveforms (traces) in C++ or SystemC?

See the next question for tracing in SystemPerl mode.

Add the --trace switch to Verilator, and make sure the SystemPerl package is installed. SystemC itself does not need to be installed for C++ only tracing. You do not even need to compile SystemPerl; you may simply untar the SystemPerl kit and point the SYSTEMPERL environment variable to the untarred directory.

In your top level C code, call Verilated::traceEverOn(true). Then create a SpTraceVcdC object, and in your main loop call ``trace_object->dump(time)'' every time step, and finally call ``trace_object->close()''. For an example, see the call to SpTraceVcdC in the test_c/sim_main.cpp file of the distribution.

You also need to compile SpTraceVcdC.cpp and add it to your link. This is done for you if using the Verilator --exe flag.

How do I generate waveforms (traces) in SystemPerl?

Add the --trace switch to Verilator, and make sure the SystemPerl package is installed.

In your top level C sc_main code, call Verilated::traceEverOn(true). Then create a SpTraceFile object as you would create a normal SystemC trace file. For an example, see the call to SpTraceFile in the test_sp/sc_main.cpp file of the distribution.

How do I view waveforms (traces)?

Verilator makes standard VCD (Value Change Dump) files. They are viewable with the public domain Dinotrace or GtkWave programs, or any of the many commercial offerings.

Where is the translate_off command? (How do I ignore a construct?)

Translate on/off pragmas are generally a bad idea, as it's easy to have mismatched pairs, and you can't see what another tool sees by just preprocessing the code. Instead, use the preprocessor; Verilator defines the ``verilator'' define for you, so just wrap the code in a ifndef region: `endif

`ifndef verilator
  Something_Verilator_Dislikes;

Why do I get ``unexpected `do''' or ``unexpected `bit''' errors?

Do, bit, ref, return, and other words are now SystemVerilog keywords. You should change your code to not use them to insure it works with newer tools. Alternatively, surround them by the Verilog 2005/SystemVerilog begin_keywords pragma to indicate Verilog 2001 code. `end_keywords

`begin_keywords "1364-2001" 
  integer bit; initial bit = 1;

If you want the whole file to be parsed as Verilog 2001, just create a file with

`begin_keywords "1364-2001"

and add it before other Verilog files on the command line. (Note this will also change the default for --prefix, so if you're not using --prefix, you will now need to.)

How do I prevent my assertions from firing during reset?

Call Verilated::assertOn(false) before you first call the model, then turn it back on after reset. It defaults to true. When false, all assertions controlled by --assert are disabled.

Why do I get ``undefined reference to `sc_time_stamp()'''?

In C++ (non SystemC) code you need to define this function so that the simulator knows the current time. See the ``CONNECTING TO C++'' examples in the documentation.

Why do I get ``undefined reference to `VL_RAND_RESET_I' or `Verilated::...'''?

You need to link your compiled Verilated code against the verilated.cpp file found in the include directory of the Verilator kit.

Is the PLI supported?

No.

More specifically, the common PLI-ish calls $display, $finish, $stop, $time, $write are converted to C++ equivalents. If you want something more complex, since Verilator emits standard C++ code, you can simply write your own C++ routines that can access and modify signal values without needing any PLI interface code, and call it with $c(``{any_c++_statement}'').

How do I make a Verilog module that contain a C++ object?

You need to add the object to the structure that Verilator creates, then use $c to call a method inside your object. The test_regress/t/t_extend_class files show an example of how to do this.

How do I get faster build times?

Between GCC 3.0 to 3.3, each compiled progressively slower, thus if you can use GCC 2.95, or GCC 3.4 you'll have faster builds. Two ways to cheat are to compile on parallel machines and avoid compilations altogether. See the --output-split option, and the web for the ccache, distcc and icecream packages, and the Make::Cache package available from http://www.veripool.org/. Make::Cache will skip GCC runs between identical source builds, even across different users.

Why do so many files need to recompile when I add a signal?

Adding a new signal requires the symbol table to be recompiled. Verilator uses one large symbol table, as that results in 2-3 less assembly instructions for each signal access. This makes the execution time 10-15% faster, but can result in more compilations when something changes.

How do I access signals in C?

First, declare the signals you will be accessing with a /*verilator public*/ comment before the closing semicolon. Then scope into the C++ class to read the value of the signal, as you would any other member variable.

Signals are the smallest of 8 bit chars, 16 bit shorts, 32 bit longs, or 64 bit long longs that fits the width of the signal. Generally, you can use just uint32_t's for 1 to 32 bits, or uint64_t for 1 to 64 bits, and the compiler will properly up-convert smaller entities.

Signals wider than 64 bits are stored as an array of 32-bit uint32_t's. Thus to read bits 31:0, access signal0, and for bits 63:32, access signal1. Unused bits (for example bit numbers 65-96 of a 65 bit vector) will always be zero. if you change the value you must make sure to pack zeros in the unused bits or core-dumps may result. (Because Verilator strips array bound checks where it believes them to be unnecessary.)

In the SYSTEMC example above, if you had in our.v:

input clk /*verilator public*/;

From the sc_main.cpp file, you'd then: #include "Vour_our.h" cout << "clock is " << top->v.clk << endl;

#include "Vour.h"

In this example, clk is a bool you can read or set as any other variable. The value of normal signals may be set, though clocks shouldn't be changed by your code or you'll get strange results.

Should a module be in Verilog or SystemC?

Sometimes there is a block that just interconnects cells, and have a choice as to if you write it in Verilog or SystemC. Everything else being equal, best performance is when Verilator sees all of the design. So, look at the hierarchy of your design, labeling cells as to if they are SystemC or Verilog. Then:

A module with only SystemC cells below must be SystemC.

A module with a mix of Verilog and SystemC cells below must be SystemC. (As Verilator cannot connect to lower-level SystemC cells.)

A module with only Verilog cells below can be either, but for best performance should be Verilog. (The exception is if you have a design that is instantiated many times; in this case Verilating one of the lower modules and instantiating that Verilated cells multiple times into a SystemC module may be faster.)