Next: , Previous: Simulation and run time, Up: Simulation and run time



4.1 Simulation options

In most system environments, it is possible to pass options while invoking a program. Contrary to most programming language, there is no standard method in VHDL to obtain the arguments or to set the exit status.

In GHDL, it is impossible to pass parameters to your design. A later version could do it through the generics interfaces of the top entity.

However, the GHDL run time behaviour can be modified with some options; for example, it is possible to stop simulation after a certain time.

The exit status of the simulation is EXIT_SUCCESS (0) if the simulation completes, or EXIT_FAILURE (1) in case of error (assertion failure, overflow or any constraint error).

Here is the list of the most useful options. Some debugging options are also available, but not described here. The --help options lists all options available, including the debugging one.

--assert-level=LEVEL
Select the assertion level at which an assertion violation stops the simulation. LEVEL is the name from the severity_level enumerated type defined in the standard package or the none name.

By default, only assertion violation of severity level failure stops the simulation.

For example, if LEVEL was warning, any assertion violation with severity level warning, error or failure would stop simulation, but the assertion violation at the note severity level would only display a message.

--assert-level=none prevents any assertion violation to stop simulation.

--stop-time=TIME
Stop the simulation after TIME. TIME is expressed as a time value, without any space. The time is the simulation time, not the real clock time.

For examples:

          $ ./my_design --stop-time=10ns
          $ ./my_design --stop-time=ps
     

--stop-delta=N
Stop the simulation after N delta cycles in the same current time.
--disp-time
Display the time and delta cycle number as simulation advances.
--disp-tree[=KIND]
Display the design hierarchy as a tree of instantiated design entities. This may be useful to understand the structure of a complex design. KIND is optional, but if set must be one of:
none
Do not display hierarchy. Same as if the option was not present.
inst
Display entities, architectures, instances, blocks and generates statements.
proc
Like inst but also display processes.
port
Like proc but display ports and signals too.
If KIND is not specified, the hierarchy is displayed with the port mode.
--no-run
Do not simulate, only elaborate. This may be used with --disp-tree to display the tree without simulating the whole design.
--vcd=FILENAME
Dump into the VCD file FILENAME the signal values before each non-delta cycle. If FILENAME is -, then the standard output is used, otherwise a file is created or overwritten.

VCD (value change dump) is a file format defined by the verilog standard and used by virtually any wave viewer.

Since it comes from verilog, only a few VHDL types can be dumped. GHDL dumps only signals whose base type is of the following:

I have successfully used gtkwave to view VCD files.

Currently, there is no way to select signals to be dumped: all signals are dumped, which can generate big files.

It is very unfortunate there is no standard or well-known wave file format supporting VHDL types. If you are aware of such a free format, please mail me (see Reporting bugs).

--wave=FILENAME
Write the waveforms into a ghw (GHdl Waveform) file. Currently, all the signals are dumped into the waveform file, you cannot select a hierarchy of signals to be dumped.

The format of this file was defined by myself and is not yet completly fixed. It may change slightly.

There is a patch against gtkwave 1.3.56 on the ghdl website at ghdl.free.fr, so that it can read such files.

Contrary to VCD files, any VHDL type can be dumped into a GHW file.

--sdf=PATH=FILENAME
--sdf=min=PATH=FILENAME
--sdf=typ=PATH=FILENAME
--sdf=max=PATH=FILENAME
Do VITAL annotation on PATH with SDF file FILENAME.

PATH is a path of instances, separated with . or /. Any separator can be used. Instances are component instantiation labels, generate labels or block labels. Currently, you cannot use an indexed name.

If the option contains a type of delay, that is min=, typ= or max=, the annotator use respectively minimum, typical or maximum values. If the option does not contain a type of delay, the annotator use the typical delay.

See Backannotation, for more details.

--stack-max-size=SIZE
Set the maximum size in bytes of the non-sensitized processes stacks.

If the value SIZE is followed (without any space) by the k, K, kb, Kb, ko or Ko multiplier, then the size is the numeric value multiplied by 1024.

If the value SIZE is followed (without any space) by the m, M, mb, Mb, mo or Mo multiplier, then the size is the numeric value multiplied by 1024 * 1024 = 1048576.

Each non-sensitized process has its own stack, while the sensitized processes share the same and main stack. This stack is the stack created by the operating system.

Using too small stacks may result in simulation failure due to lack of memory. Using too big stacks may reduce the maximum number of processes.

--stack-size=SIZE
Set the initial size in bytes of the non-sensitized processes stack. The SIZE value has the same format as the previous option.

The stack of the non-sensitized processes grows until reaching the maximum size limit.

--help
Display a short description of the options accepted by the run time library.