Skip to content
STIMSMITH

Architectural Variable (AV)

Concept WIKI v1 · 6/6/2026

An Architectural Variable (AV) is a state variable of a hardware module (processor or accelerator) as modeled within an Instruction-Level Abstraction (ILA). AVs are the named, abstract state elements whose values define the observable architectural state of a design, and they are the units of equivalence that are checked (AV-Check) and transferred (AV-Swap) between a high-level Instruction-Level Execution Model (ILEM) and an RTL-based Execution Model (RTEM) during tandem simulation.

Overview

An Architectural Variable (AV) is a state variable in an Instruction-Level Abstraction (ILA) that captures the abstract, observable state of a processor or accelerator at the instruction level. AVs generalize the notion of architectural state — historically tied to processor ISAs — to hardware accelerators and other SoC components, enabling uniform instruction-level modeling and verification across heterogeneous designs.

In an ILA, a design is described by:

  • A set S of architectural variables (the AVs),
  • A set W of inputs (e.g., MMIO interface signals for accelerators),
  • An initial-state mapping S0,
  • A set of instructions I, each defined by a decode function D (trigger condition) and a state-update function N (a state transition function over the AVs).

The ISA of a processor is treated as a special case of an ILA, where the architectural state corresponds to the conventional visible processor state (registers, program counter, etc.).

Examples

In an AES cryptographic accelerator modeled as an ILA, the architectural variables include:

  • key — the encryption key,
  • length — the length of text to encrypt,
  • addr — the address of the text,
  • status — operation status,
  • data_mem — internal data memory,
  • output_data — encryption output.

Inputs W (e.g., addr_in, data_in, cmd) are distinct from AVs and represent the interface signals through which the host processor (or firmware) issues loads/stores to the accelerator.

Role in Tandem Simulation

AVs are the central objects checked and exchanged during tandem simulation:

  • AV-Check — At the end of each instruction (or at predefined checkpoints), the corresponding instruction-level architectural variables (ILAVs) from the ILEM are compared against the RTL architectural variables (RTAVs) of the RTEM. A mismatch indicates a potential bug, which can be localized using nearby instructions.
  • AV-Swap — Values of AVs are transferred from the ILEM to the RTEM, allowing a high-level simulation to "jump-start" the RTL simulation, skipping the warm-up phase and improving simulation speed.

Because the RTL implementation contains additional micro-architectural variables beyond those in the ILA, AV-Swapping requires careful handling to ensure the extra micro-architectural state is set consistently.

Hierarchy

ILAs support child-ILAs, allowing complex instructions (e.g., START_ENCRYPT in the AES example) to be decomposed into child-instructions (Load, Encrypt, Store). In hierarchical ILA models, architectural variables may be defined at the parent or child level, and state transitions propagate through the hierarchy.

See Also

CITATIONS

7 sources
7 citations
[1] An ILA model is defined as a tuple ⟨S, W, S0, D, N⟩, where S is the set of architectural variables (AVs) and W is the set of inputs. Generalizing Tandem Simulation: Connecting High-level and RTL Simulation Models
[2] The ISA can be viewed as a special case of an ILA, and the ILA for accelerators specifies a set of instructions and AVs. Generalizing Tandem Simulation: Connecting High-level and RTL Simulation Models
[3] In the AES accelerator example, the AVs include the encryption key, text length, address, status, data_mem, and output_data, while the inputs are MMIO interface signals such as addr_in, data_in, and cmd. Generalizing Tandem Simulation: Connecting High-level and RTL Simulation Models
[4] The state update function N is a state transition function for the architectural variables, which lends itself to direct translation to an ILEM for co-simulation. Generalizing Tandem Simulation: Connecting High-level and RTL Simulation Models
[5] Tandem simulation performs AV-Check at the end of each instruction (or at checkpoints) to verify that ILAVs and RTAVs are equivalent. Generalizing Tandem Simulation: Connecting High-level and RTL Simulation Models
[6] Tandem simulation supports AV-Swap, transferring values of AVs from the ILEM to the RTEM to jump-start the RTL simulation and reduce warm-up time. Generalizing Tandem Simulation: Connecting High-level and RTL Simulation Models
[7] ILAs support hierarchy through child-ILAs, enabling complex instructions (e.g., START_ENCRYPT) to be decomposed into child-instructions. Generalizing Tandem Simulation: Connecting High-level and RTL Simulation Models