Services - tools - models - for embedded software development
Embecosm divider strip
Prev  Next

6.2.  Accessing Signals in Verilator Models

6.2.1. Module Hierarchy When Accessing Signals
6.2.2. Direct Access to Verilator Model Signals
6.2.3. Access to Verilator Model Signals via Tasks and Functions
6.2.4. Good Coding Practice when Accessing Verilator Signals

By default Verilator does not provide access to internal signals within the Verilog hierarchy. However it provides two mechanisms for such access:

In either case, values of up to 64 bits are stored in the smallest appropriate C++ unsigned type. (uint8_t, uint16_t, uint32_t, uint64_t).

In practice SystemC programs will just use bool, uint32_t and uint64_t for the results, relying on C++ to automatically cast the values. This is then consistent with the set of types used for SystemC module signals.

Signals wider than 64-bits are represented as arrays of uint32_t, with the least significant bits in the lowest numbered element. Where the number of bits is not a multiple of 32, the odd bits are the least significant bits of the highest numbered element.

For example reg [47:0] r would be represented in a C++ array, uint32_t r[2]. Bits [31:0] would be in C++ array r[0] and bits [47:32] would be in the 16 least significant bits of the C++ array r[1].


Verilator cannot handle results wider than 64 bits from functions. For such signals either tasks must be used (with result via an output parameter), or the signal must be directly accessed.


With cycle accurate models, such as those created by Verilator it is only meaningful to update signals which are state-holding, that is the registers in sequential logic. Updating wires, or registers used only in combinatorial logic, will have no effect.

Embecosm divider strip