.. program:: ghdl .. _USING:Simulation: Simulation and runtime ###################### .. _simulation_options: Simulation options ================== In most system environments, it is possible to pass options while invoking a program. Contrary to most programming languages, there is no standard method in VHDL to obtain the arguments or to set the exit status. However, the GHDL runtime behaviour can be modified with some options. For example, it is possible to pass parameters to your design through the generic interfaces of the top entity. It is also 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 :option:`--help` option lists all options available, including the debugging ones. .. option:: -gGENERIC=VALUE Set value `VALUE` to generic with name `GENERIC`. .. WARNING:: This is currently a run option; but in the future it will be deprecated to become an elaboration option only. .. option:: --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. Option :option:`--assert-level=none` prevents any assertion violation from stopping simulation. .. option:: --ieee-asserts<=POLICY> Select how the assertions from ``ieee`` units are handled. `POLICY` can be ``enable`` (the default), ``disable`` which disables all assertions from ``ieee`` packages and ``disable-at-0`` which disables only at the start of simulation. This option can be useful to avoid assertion messages from ``ieee.numeric_std`` (and other ``ieee`` packages). .. option:: --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 example:: $ ./my_design --stop-time=10ns $ ./my_design --stop-time=ps .. option:: --stop-delta<=N> Stop the simulation after `N` delta cycles in the same current time. The default is 5000. .. index:: display time .. option:: --disp-time Display the time and delta cycle number as simulation advances. .. option:: --unbuffered Disable buffering on stdout, stderr and files opened in write or append mode (TEXTIO). .. option:: --max-stack-alloc<=N> Emit an error message in case of allocation on the stack of an object larger than `N` KB. Use 0 to disable these checks. .. option:: --sdf<=PATH=FILENAME> Do VITAL annotation on `PATH` with SDF file :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. Specifying a delay:: --sdf=min=PATH=FILENAME --sdf=typ=PATH=FILENAME --sdf=max=PATH=FILENAME 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 uses the typical delay. See section :ref:`Backannotation`, for more details. .. option:: --vpi<=FILENAME> Load VPI module. .. option:: --vpi-trace<=FILE> Trace vpi calls to FILE. .. option:: --help Display a short description of the options accepted by the runtime library. .. _export_waves: Export waveforms ================ .. option:: --read-wave-opt= Filter signals to be dumped to the wave file according to the wave option file provided. Here is a description of the wave option file format currently supported :: $ version = 1.1 # Optional # Path format for signals in packages : my_pkg.global_signal_a # Path format for signals in entities : /top/sub/clk # Dump every signal named reset in first level sub entities of top /top/*/reset # Dump every signal named reset in recursive sub entities of top /top/**/reset # Dump every signal of sub2 which could be anywhere in the design except # on the top level /**/sub2/* # Dump every signal of sub3 which must be a first level sub entity of the # top level /*/sub3/* # Dump every signal of the first level sub entities of sub3 (but not # those of sub3) /**/sub3/*/* .. option:: --write-wave-opt= If the wave option file doesn't exist, creates it with all the signals of the design. Otherwise throws an error, because it won't erase an existing file. .. option:: --vcd<=FILENAME> .. option:: --vcdgz<=FILENAME> .. index:: vcd .. index:: value change dump .. index:: dump of signals Option :option:`--vcd` dumps 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. The :option:`--vcdgz` option is the same as the *--vcd* option, but the output is compressed using the `zlib` (`gzip` compression). However, you can't use the ``-`` filename. Furthermore, only one VCD file can be written. :dfn:`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: * types defined in the ``std.standard`` package: * ``bit`` * ``bit_vector`` * types defined in the ``ieee.std_logic_1164`` package: * ``std_ulogic`` * ``std_logic`` (because it is a subtype of ``std_ulogic``) * ``std_ulogic_vector`` * ``std_logic_vector`` * any integer type 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 (:ref:`Reporting_bugs`). .. option:: --vcd-nodate Do not write date in the VCD file. .. option:: --fst<=FILENAME> Write the waveforms into an `fst` file that can be displayed by `gtkwave`. The `fst` files are much smaller than VCD or `GHW` files, but it handles only the same signals as the VCD format. .. option:: --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 completely fixed. It may change slightly. The ``gtkwave`` tool can read the GHW files. Contrary to VCD files, any VHDL type can be dumped into a GHW f
/*
    ChibiOS/RT - Copyright (C) 2006,2007,2008,2009,2010,
                 2011 Giovanni Di Sirio.

    This file is part of ChibiOS/RT.

    ChibiOS/RT is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 3 of the License, or
    (at your option) any later version.

    ChibiOS/RT is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

/**
 * @file    chmsg.c
 * @brief   Messages code.
 *
 * @addtogroup messages
 * @details Synchronous inter-thread messages APIs and services.
 *          <h2>Operation Mode</h2>
 *          Synchronous messages are an easy to use and fast IPC mechanism,
 *          threads can both act as message servers and/or message clients,
 *          the mechanism allows data to be carried in both directions. Note
 *          that messages are not copied between the client and server threads
 *          but just a pointer passed so the exchange is very time
 *          efficient.<br>
 *          Messages are scalar data types of type @p msg_t that are guaranteed
 *          to be size compatible with data pointers. Note that on some
 *          architectures function pointers can be larger that @p msg_t.<br>
 *          Messages are usually processed in FIFO order but it is possible to
 *          process them in priority order by enabling the
 *          @p CH_USE_MESSAGES_PRIORITY option in @p chconf.h.<br>
 * @pre     In order to use the message APIs the @p CH_USE_MESSAGES option
 *          must be enabled in @p chconf.h.
 * @post    Enabling messages requires 6-12 (depending on the architecture)
 *          extra bytes in the @p Thread structure.
 * @{
 */

#include "ch.h"

#if CH_USE_MESSAGES || defined(__DOXYGEN__)

#if CH_USE_MESSAGES_PRIORITY
#define msg_insert(tp, qp) prio_insert(tp, qp)
#else
#define msg_insert(tp, qp) queue_insert(tp, qp)
#endif

/**
 * @brief   Sends a message to the specified thread.
 * @details The sender is stopped until the receiver executes a
 *          @p chMsgRelease()after receiving the message.
 *
 * @param[in] tp        the pointer to the thread
 * @param[in] msg       the message
 * @return              The answer message from @p chMsgRelease().
 *
 * @api
 */
msg_t chMsgSend(Thread *tp, msg_t msg) {
  Thread *ctp = currp;

  chDbgCheck(tp != NULL, "chMsgSend");

  chSysLock();
  ctp->p_msg = msg;
  ctp->p_u.wtobjp = &tp->p_msgqueue;
  msg_insert(ctp, &tp->p_msgqueue);
  if (tp->p_state == THD_STATE_WTMSG)
    chSchReadyI(tp);
  chSchGoSleepS(THD_STATE_SNDMSGQ);
  msg = ctp->p_u.rdymsg;
  chSysUnlock();
  return msg;
}

/**
 * @brief   Suspends the thread and waits for an incoming message.
 * @post    After receiving a message the function @p chMsgGet() must be
 *          called in order to retrieve the message and then @p chMsgRelease()
 *          must be invoked in order to acknowledge the reception and send
 *          the answer.
 * @note    If the message is a pointer then you can assume that the data
 *          pointed by the message is stable until you invoke @p chMsgRelease()
 *          because the sending thread is suspended until then.
 *
 * @return              A reference to the thread carrying the message.
 *
 * @api
 */
Thread *chMsgWait(void) {
  Thread *tp;

  chSysLock();
  if (!chMsgIsPendingI(currp))
    chSchGoSleepS(THD_STATE_WTMSG);
  tp = fifo_remove(&currp->p_msgqueue);
  tp->p_state = THD_STATE_SNDMSG;
  chSysUnlock();
  return tp;
}

/**
 * @brief   Releases a sender thread specifying a response message.
 * @pre     Invoke this function only after a message has been received
 *          using @p chMsgWait().
 *
 * @param[in] tp        pointer to the thread
 * @param[in] msg       message to be returned to the sender
 *
 * @api
 */
void chMsgRelease(Thread *tp, msg_t msg) {

  chSysLock();
  chDbgAssert(tp->p_state == THD_STATE_SNDMSG,
              "chMsgRelease(), #1", "invalid state");
  chMsgReleaseS(tp, msg);
  chSysUnlock();
}

#endif /* CH_USE_MESSAGES */

/** @} */
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-13 20:37:10 +0000