Skip to content
STIMSMITH

Address Translation

Concept WIKI v2 · 8/16/2026

Address translation is a hardware mechanism that maps addresses between different address spaces. In conventional CPUs it converts data virtual addresses into physical addresses using page tables accelerated by TLBs, and it can also be expressed as PC-indexed translation that uses a load instruction's PC to obtain a page table entry. In distributed multi-GPU scale-up systems, a destination-side variant called reverse address translation maps Network Physical Addresses (NPAs) to System Physical Addresses (SPAs) using Link MMUs and Link TLBs. The article also covers specification-based test program generation for MMUs (MicroTESK, MMUSL) and IBM's DeepTrans/Genesys-Pro approach, which models address translation as a directed acyclic graph whose paths correspond to translation situations referenced from test templates.

Overview

Address translation is a hardware mechanism described in processor architecture specifications alongside interrupt handling and multi-tasking, and is treated as a complex functional unit that must be verified together with the rest of the processor design [1]. Its purpose is to convert addresses produced by software (or by a remote peer) into the addresses actually used by the underlying memory or interconnect hardware. Two principal variants appear in contemporary systems: conventional data address translation used by CPUs, and reverse address translation used by destination nodes that receive remote memory accesses over scale-up fabrics such as NVLink or UALink.

Data Address Translation

In a conventional processor, address translation converts the data virtual address of a load or store into a physical address by looking up a page table entry (PTE). Translation is normally accelerated by a Data Translation Lookaside Buffer (DTLB), with a Secondary TLB (STLB) backing the DTLB on misses [arxiv:2408.15878v2]. Address translation is performed by the Memory Management Unit (MMU), which comprises multi-level translation and caching structures [41d922b1-9197-4376-9a40-16ceb3eb8f29, 97acf9d4-0f82-4d68-885e-26a6b58b0435].

PC-Indexed Data Address Translation (PCAX)

Because a small subset of static loads is responsible for most DTLB misses, and because a dynamic instance of a static load frequently accesses the same PTE as the previous dynamic instance, alternative translation mechanisms have been proposed. PC-Indexed Data Address Translation (PCAX) uses the program counter (PC) of a load instruction, rather than the data virtual address, to obtain the PTE for the accessed data [arxiv:2408.15878v2]. PCAX-style tables can be accessed alongside instruction fetch and can therefore be slow while still frequently returning a valid PTE before data address calculation completes [arxiv:2408.15878v2]. Reported results include cutting the effective DTLB miss rate by a factor of 2–3× (and in some cases more), reducing STLB misses, achieving an average performance improvement of 1.7%, and reducing data address translation energy by 7% across 84 server traces [arxiv:2408.15878v2].

Reverse Address Translation

In distributed machine-learning systems built from multi-GPU, multi-node scale-up pods, Remote Direct Memory Access (RDMA) over fabrics such as NVLink and UALink introduces a destination-side translation step: translating Network Physical Addresses (NPAs) into System Physical Addresses (SPAs). This step is termed Reverse Address Translation [arxiv:2604.02473v1].

The translation is performed by Link MMUs equipped with Link TLBs [arxiv:2604.02473v1]. Empirical analysis using an extended ASTRA-sim framework with an OMNeT++ network backend shows that cold TLB misses dominate the latency of small, latency-sensitive collectives, causing up to 1.4× performance degradation, whereas larger collectives benefit from warmed TLBs and show diminishing returns from oversized structures [arxiv:2604.02473v1]. Two optimization avenues have been proposed: fused pre-translation kernels that overlap Reverse Address Translation with computation, and software-guided TLB prefetching that proactively populates likely-needed entries [arxiv:2604.02473v1].

Specification-Based Modeling and Test Program Generation

State-of-the-art MMUs are extremely complex devices comprising multi-level address translation and caching, which makes specification-based test program generation (TPG) one of the most promising directions in microprocessor verification [2].

DeepTrans (IBM)

IBM's DeepTrans uses a dedicated specification language in which address translation is depicted as a directed acyclic graph (DAG) whose vertices correspond to the process stages and whose edges relate to the transitions between the stages [2]. A path from the source of the DAG to the sink defines a particular situation in the address translation [2]. Such situations are referenced from high-level descriptions of test programs, called test templates (TTs), which are processed by Genesys-Pro [2]. The major advantage of the approach is the use of highly developed languages for modeling MMUs and describing TTs; a possible disadvantage is that the tool seems not to be able to automatically extract MMU-related dependencies between instructions [2].

MicroTESK and MMUSL

ISP RAS's MicroTESK is an open-source, extensible, and reconfigurable TPG framework that combines (1) an architecture-independent test generation core and (2) an architecture specification/model [707c78d7-a004-45ad-9f26-de4bea8fecde, 97acf9d4-0f82-4d68-885e-26a6b58b0435]. The tool uses a dialect of the nML language for specifying instruction set architectures (ISA) and a dedicated problem-oriented language called MMUSL (MMU Specification Language) for specifying memory management mechanisms such as translation lookaside buffers, page tables, table lookup units, and caches [707c78d7-a004-45ad-9f26-de4bea8fecde, b2437db9-5c05-469a-b833-6cabcd1542c1].

In MMUSL, address translation can be expressed as a flat segment that performs a direct mapping from a virtual address range to a physical address without using TLBs and tables [3]. For example, the XKPHYS segment of the MIPS64 MMU is specified as a range-to-physical-address mapping that copies selected bits of the virtual address and extracts a cache-coherence attribute (CCA) field [3]. Buffers (TLBs, caches, page tables, etc.) are specified using parameters such as associativity (ways), number of sets (sets), entry format (entry), index calculation function (index), tag calculation function (tag), and data eviction policy (policy) [3].

Processing of memory access instructions is specified by requesting segments and buffers using constructs such as B(A).hit (the buffer B contains an entry for address A), E = B(A) (read entry E from buffer B for address A), and B(A) = E (write entry E to buffer B for address A) [3]. A MIPS64 MMU fragment, for instance, defines read logic that calls TranslateAddress(va) for address translation and then performs L1 cache access on hit or updates the L1 entry on miss [3].

MicroTESK analyzes the MMUSL specifications to extract all possible instruction execution paths as well as all possible inter-path dependencies [4]. Test templates are written in Ruby and processed by MicroTESK, which builds symbolic test programs that are instantiated with appropriate test data through symbolic execution and constraint solving [707c78d7-a004-45ad-9f26-de4bea8fecde, b2437db9-5c05-469a-b833-6cabcd1542c1]. Different versions of MicroTESK have been applied to several industrial microprocessors and have revealed a large number of critical bugs that had not been detected by randomly generated test programs [5].

A key practical lesson reported by the MicroTESK team is that domain-specific languages (DSLs) are convenient for specifying ISAs and MMUs, because they ease extraction of testing knowledge and simplify learning of the TPG tool, while dynamic programming languages such as Ruby and Python suit well for describing test templates [5]. A negative experience is mostly connected with low performance of the tool — constraint solving needs to be optimized [5].

Verification

Verification of address translation is treated as part of hardware processor design verification. Verification tasks are described in two domains: the operation domain of operands, instructions, and instruction sequences, and the hardware domain of resources and functional units such as registers, memory, address translation, cache, and pipeline [6].

Typical operand-level verification tasks related to address translation include:

  • Accessing an operand address that is either aligned to or crosses a page boundary [6]
  • Accessing an operand address such that a page fault occurs [6]
  • Accessing an operand address such that a cache hit occurs [6]
  • Accessing an operand that ends on a cache line boundary such that a cache miss occurs [6]

These tasks are enumerated and combined as part of Architecture Verification Programs (AVP) and Implementation Verification Programs (IVP) generated to exercise both the architectural definition and the implementation of the address-translation functional unit [2d34e1b4-8375-4347-b2b5-44e2074308ab, ea1aee7d-873d-4c35-851e-bd9274dedec1].

See Also

LINKED ENTITIES

2 links
DeepTrans IMPLEMENTS
memory management unit PART_OF

CITATIONS

22 sources
22 citations
[1] Address translation is one of the main hardware mechanisms described in a processor's architecture specification, alongside interrupt handling and multi-tasking. Test program generator - International Business Machines Corporation
[2] Modern computer architectures treat address translation as a complex functional unit whose behavior must be verified together with the rest of the processor design. Test program generator - International Business Machines Corporation
[3] In conventional processors, address translation converts a data virtual address into a physical address by looking up a page table entry, accelerated by a DTLB with an STLB on misses. PC-Indexed Data Address Translation
[4] PCAX uses the PC of a load instruction, not the data virtual address, to obtain the PTE for the data accessed by a load instruction, and is intended for a small subset of static loads. PC-Indexed Data Address Translation
[5] With PCAX, the effective DTLB miss rate can be cut by 2–3× in many cases (and more in some cases), STLB misses are reduced, average performance improves by 1.7%, and data address translation energy is reduced by 7% across 84 server traces. PC-Indexed Data Address Translation
[6] In multi-GPU scale-up pods, Remote Direct Memory Access over fabrics such as NVLink and UALink requires destination-side translation from NPAs to SPAs, termed Reverse Address Translation. Analyzing Reverse Address Translation Overheads in Multi-GPU Scale-Up Pods
[7] Reverse Address Translation is performed by Link MMUs equipped with Link TLBs. Analyzing Reverse Address Translation Overheads in Multi-GPU Scale-Up Pods
[8] Cold TLB misses dominate latency for small latency-sensitive collectives (up to 1.4× degradation), while larger collectives benefit from warmed caches and show diminishing returns from oversized TLBs. Analyzing Reverse Address Translation Overheads in Multi-GPU Scale-Up Pods
[9] Proposed optimizations for reverse address translation include fused pre-translation kernels overlapping translation with computation, and software-guided TLB prefetching. Analyzing Reverse Address Translation Overheads in Multi-GPU Scale-Up Pods
[10] State-of-the-art MMUs are extremely complex devices comprising multi-level address translation and caching, making specification-based TPG one of the most promising directions in microprocessor verification. Specification-Based Test Program Generation for MIPS64 Memory Management Units
[11] IBM's DeepTrans depicts address translation as a DAG whose vertices correspond to process stages and edges to transitions; a path from source to sink defines a translation situation referenced from test templates processed by Genesys-Pro. Specification-Based Test Program Generation for MIPS64 Memory Management Units
[12] MicroTESK is an open-source TPG framework combining an architecture-independent test generation core with an architecture specification/model, and has been applied to several industrial microprocessors where it revealed many critical bugs not detected by random test programs. Specification-Based Test Program Generation for MIPS64 Memory Management Units
[13] MicroTESK uses a dialect of nML for ISA specifications and the dedicated MMUSL language for specifying MMU mechanisms such as TLBs, page tables, table lookup units, and caches. Specification-Based Test Program Generation for MIPS64 Memory Management Units
[14] In MMUSL, address translation can be expressed as a flat segment that performs a direct range-to-physical-address mapping without using TLBs and tables (e.g., the XKPHYS MIPS64 segment). Specification-Based Test Program Generation for MIPS64 Memory Management Units
[15] MMUSL specifies buffers (TLBs, caches, page tables) using parameters including associativity (ways), number of sets (sets), entry format, index function, tag function, and eviction policy. Specification-Based Test Program Generation for MIPS64 Memory Management Units
[16] MMUSL uses constructs such as B(A).hit, E=B(A), and B(A)=E to request segments and buffers when specifying memory access instruction processing. Specification-Based Test Program Generation for MIPS64 Memory Management Units
[17] A MIPS64 MMU specification in MMUSL defines read logic that calls TranslateAddress(va) for address translation and then performs L1 cache hit/miss handling. Specification-Based Test Program Generation for MIPS64 Memory Management Units
[18] MicroTESK analyzes MMUSL specifications to extract all possible instruction execution paths and inter-path dependencies, then uses Ruby-written test templates, symbolic execution, and constraint solving to instantiate test programs. Specification-Based Test Program Generation for MIPS64 Memory Management Units
[19] Domain-specific languages ease extraction of testing knowledge and learning of TPG tools; dynamic languages such as Ruby and Python suit well for describing test templates; constraint-solving performance is a remaining bottleneck. Specification-Based Test Program Generation for MIPS64 Memory Management Units
[20] Verification tasks are described using terms from two domains: the operation domain (operands, instructions, instruction sequences) and the hardware domain (resources and functional units such as registers, memory, address translation, cache, pipeline). Test program generator - International Business Machines Corporation
[21] Operand-level verification tasks related to address translation include accessing an operand address aligned to or crossing a page boundary, causing a page fault, causing a cache hit, and causing a cache miss at a cache line boundary. Test program generator - International Business Machines Corporation
[22] Architecture Verification Programs (AVP) and Implementation Verification Programs (IVP) are generated to exercise both the architectural definition and the implementation of address-translation functional units. Test program generator - International Business Machines Corporation

VERSION HISTORY

v2 · 8/16/2026 · minimax/minimax-m3 (current)
v1 · 6/13/2026 · minimax/minimax-m3