Demystify Address Translation Services (ATS) in PCIe 6.0

By Anupriya K

June 23, 2026

Address Translation Services (ATS) is one of the toughest verification problems to solve as it is the fast lane for PCIe memory access, cutting delays by caching address translations directly on the device. It keeps software behavior consistent across both PCIe Devices and RC Integrated Endpoints, making performance gains simple to adopt.

Key Features updated for ATS

1. Translation Agent (TA):
   • Central entity, which is responsible for translating virtual addresses to physical addresses that validates and returns translated addresses to requesting devices
2. Address Translation Cache (ATC): Cache within a PCIe Function to store translated addresses
3. Address Translation and Protection Table (ATPT) – Optional feature contains the set of address translations accessed by a TA to process PCIe requests.
4. AT Field in TLPs: Indicates whether a memory address in a transaction is translated
5. Support for Multi-Function Devices: ATS can be implemented per Function
   • Shared ATC resources must behave consistently with independent ATCs
6. Shadow Functions:
   • ATS supports Shadow Functions, which share ATC and translation resources with a main Function

 Here is a diagram illustrating the interaction flow of Address Translation Services (ATS) in PCI Express:

Translation Request /Completion exchange

Address translation and caching are performed with the help of Memory Request transmitted from ATC to TA. Upon reception of the Translation Request, TA determines whether the translation can be provided to the function and indicates the success or failure of the request by generating a translation completion with the right response status.

Invalidate Request/Completion exchange

When a translation changes, the TA sends an Invalidation Request, so the ATC stays in sync with the ATPT. This request is a MsgD transaction that tells the ATC to remove specific address-range entries.

The Invalidate Completion message includes tags from the original request, so the TA can identify which function finished the invalidate operation.

Page Request/PRG Response message exchange

Page Request helps a PCIe endpoint (like a storage device) to request a page in a specific virtual memory address by transmitting a Msg TLP to RC. To notify a Function that the page request(s) associated with the corresponding PRG has (have) been satisfied with a PRG Response Message is a PCIe Message Request that is Routed by ID back to the requesting Function.

Basic Rules and Requirements

• Translation Validity:
  • A Function must not issue TLPs with the AT field set unless the address was obtained via ATS. ATC entries must only be populated using the ATS protocol
• Ordering and Routing:
  • ATS Translation Requests follow standard PCIe routing and ordering rules
• Access Permissions:
  • Translated addresses must have appropriate permissions (Read, Write)
• Consistency:
  • Shared ATC implementations must behave as if each Function has an independent ATC. Shadow Functions must be treated identically to their main Function by the TA

Advance requirements with other features

ATS and PASID (Process Address Space ID)

ATS works with PASID to translate a process’s virtual addresses into physical addresses. An ATS Translation Request can carry a PASID to identify the target process address space. The ATS response then returns both the translation and the allowed access rights (Read, Write, Execute) for that PASID.

ATS and IDE (Integrity and Data Encryption)

ATS interacts with IDE to ensure that address translations and memory access remain secure by following all rules mentioned in the IDE section.

Key Interactions:

• IDE TLPs and ATS:
  • ATS must ensure that translations used in IDE TLPs are valid and not tampered with
  • IDE Streams must be configured to reject TLPs with invalid or misrouted translations
• Security Enforcement:
  • ATS must comply with IDE’s security model, especially when used with Selective IDE Streams, which allow TLPs to pass through switches

ATS and segments

All standard segment rules apply to ATS-related TLPs. This is especially important for Invalidate Request/Completion and Page Request/PRG Response TLPs, since they are Msg TLPs with OHC-A4 and include a destination segment. If these TLPs are IDE encrypted, it must also follow Requester Segment rules, and IDE-specific Segment Base rules.

Randomization considerations

Randomization testing always helps to catch corner case scenarios. The main parameters that can be tested are:

ATS verification challenges and solutions

Cadence PCIe VIP verification test suite is built to solve challenges like the ones described above, by delivering a verification solution in terms of test cases and coverage model. It provides a golden reference that can fully verify any specification defined feature by applying randomization and cross feature verification. Our test suite includes self-checks or protocol checks, error injections, checker evaluation, callback verification, user configurable parameters and coverage model to make sure the feature is thoroughly verified. Cadence test suite eliminates the verification gap, and customers can effectively validate their design by using the provided test suite.

PCIe Express VIP Verification testbench architecture

  More information:

• For more info on how Cadence PCIe Verification IP and TripleCheck VIP enable users to confidently verify PCIe 6.0, see our VIP for PCI Express, VIP for Compute Express Link and TripleCheck for PCI Express 
• See the PCI-SIG website for more details on PCIe in general and the different PCI standards.
• For more details, connect directly with Cadence Verification IP experts at talk_to_vip_expert@cadence.com.