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:

Mark the signal with a verilator public comment. It may then be accessed directly from the SystemC test bench.
Define a function and/or task to access the signal, and mark it with a verilator public comment. This is the preferred approach.

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].

	Caution
	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.

	Caution
	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.