AXI 4KB Boundary Violation in Unaligned Burst Transactions

The AXI protocol enforces a 4KB boundary rule to ensure that burst transactions do not cross a 4KB address boundary. This rule is critical for maintaining system integrity, especially in systems with virtual memory management or memory protection units. The 4KB boundary rule is designed to prevent a single burst transaction from accessing multiple memory pages, which could lead to security vulnerabilities or system instability. However, the implementation of this rule becomes complex when dealing with unaligned burst transactions, where the starting address of the transaction is not aligned with the transfer size.

In the context of the provided discussion, the focus is on an AXI transaction with a start address of 4095 (0xFFF), a burst length of 1 (AWLEN = 0), and a transfer size of 16 bits (AWSIZE = 1). The transaction is of type INCR (incrementing burst). The question arises whether this transaction violates the 4KB boundary rule. The confusion stems from the fact that the start address is unaligned with respect to the transfer size, and the final address of the burst could potentially cross the 4KB boundary.

The AXI protocol allows for unaligned transfers, but the actual data transfer is still aligned with the transfer size. This means that even though the start address is unaligned, the data bus will only transfer the portion of the data that is aligned with the transfer size. In the case of a 16-bit transfer, the unaligned start address means that only the upper half of the 16-bit data bus will be used for the transfer. This has implications for the 4KB boundary rule, as the effective address range of the transaction may not extend beyond the 4KB boundary.

Misalignment of Start Address and Transfer Size

The primary cause of confusion in this scenario is the misalignment between the start address (AWADDR) and the transfer size (AWSIZE). In AXI, the transfer size specifies the number of bytes to be transferred in each beat of the burst. For example, a transfer size of 1 (AWSIZE = 1) indicates a 16-bit (2-byte) transfer. When the start address is not aligned with the transfer size, the AXI protocol still allows the transfer to proceed, but only the portion of the data that is aligned with the transfer size will be transferred.

In the given example, the start address is 4095 (0xFFF), which is not aligned with a 16-bit transfer size. This means that the first beat of the burst will only transfer the upper byte of the 16-bit data bus. The remaining beats of the burst, if any, will be aligned with the transfer size. However, since the burst length is 1 (AWLEN = 0), there is only one beat in the burst, and the effective address range of the transaction does not extend beyond the 4KB boundary.

The AXI protocol specifies that for INCR bursts, the address of each subsequent beat is incremented by the number of bytes transferred in the previous beat. In the case of an unaligned start address, the first beat will transfer only the aligned portion of the data, and the address will be incremented accordingly. This ensures that the effective address range of the burst does not cross the 4KB boundary, even if the start address is unaligned.

Implementing 4KB Boundary Checks in SystemVerilog Assertions

To ensure compliance with the 4KB boundary rule, it is essential to implement proper checks in the SystemVerilog Assertions (SVA). The provided SVA property checks whether the final address of the burst (AwAddrIncr) is within the same 4KB page as the start address (AWADDR). The property is defined as follows:

property AXI_ERRM_AWADDR_BOUNDARY;
  @(posedge `AXI_SVA_CLK)
  !($isunknown({AWVALID,AWBURST,AWADDR})) & AWVALID & (AWBURST == `AXI_ABURST_INCR)
  |-> (AwAddrIncr[ADDR_MAX:12] == AWADDR[ADDR_MAX:12]);
endproperty

In this property, AwAddrIncr is calculated as:

always @(AWSIZE or AWLEN or AWADDR) begin : p_WAddrIncrComb
  AwAddrIncr = AWADDR + (AWLEN << AWSIZE);
end

The property checks that the upper bits of the final address (AwAddrIncr[ADDR_MAX:12]) match the upper bits of the start address (AWADDR[ADDR_MAX:12]). If they do not match, it indicates that the burst has crossed a 4KB boundary, and the property will fail.

However, in the case of an unaligned start address, the calculation of AwAddrIncr must take into account the fact that only the aligned portion of the data is transferred in the first beat. This means that the effective address range of the burst may be smaller than the calculated AwAddrIncr. To address this, the SVA property should be modified to account for the unaligned start address and ensure that the effective address range does not cross the 4KB boundary.

One approach to modifying the SVA property is to calculate the effective address range based on the transfer size and the alignment of the start address. For example, if the start address is unaligned with respect to the transfer size, the effective address range should be adjusted to reflect the portion of the data that is actually transferred. This can be done by masking the lower bits of the start address and the final address to ensure that they fall within the same 4KB page.

Another approach is to use a more sophisticated calculation of the final address that takes into account the alignment of the start address. For example, the final address could be calculated as:

always @(AWSIZE or AWLEN or AWADDR) begin : p_WAddrIncrComb
  AwAddrIncr = AWADDR + ((AWLEN + 1) << AWSIZE) - (AWADDR % (1 << AWSIZE));
end

This calculation ensures that the final address is adjusted based on the alignment of the start address, and the effective address range does not cross the 4KB boundary.

In conclusion, the 4KB boundary rule in AXI is a critical requirement that must be carefully implemented in both the RTL design and the verification environment. When dealing with unaligned burst transactions, it is essential to account for the alignment of the start address and the transfer size to ensure that the effective address range does not cross the 4KB boundary. By modifying the SVA property to account for unaligned start addresses, designers and verification engineers can ensure compliance with the 4KB boundary rule and avoid potential system issues.

Similar Posts

ARMv7-M VFP S16-S31 Register Access Issue: Causes and Solutions

ARMv7-M VFP S16-S31 Register Access Issue: Causes and Solutions

BySystem on Chips

ARMv7-M VFP S16-S31 Register Access and Reset Behavior The ARMv7-M architecture, which includes the Cortex-M series of processors, features a Floating-Point Unit (FPU) known as the Vector Floating-Point (VFP) unit. The VFP unit provides hardware support for floating-point operations and includes a register bank consisting of 32 single-precision registers, labeled S0 through S31. These registers

ARM Cortex-R5 MPU Region Configuration and Background Region Setup

ARM Cortex-R5 MPU Region Configuration and Background Region Setup

BySystem on Chips

ARM Cortex-R5 MPU Region Constraints and DDR Memory Partitioning The ARM Cortex-R5 processor, based on the ARMv7-R architecture, provides a Memory Protection Unit (MPU) that allows developers to define memory regions with specific attributes such as caching, access permissions, and execute-never (XN) settings. The MPU is a critical component for ensuring memory safety, performance optimization,

ARM Cortex-A53 Exception Switching Failure: aarch64 EL3 to aarch64 EL1

ARM Cortex-A53 Exception Switching Failure: aarch64 EL3 to aarch64 EL1

BySystem on Chips

ARM Cortex-A53 Exception Handling and Mode Switching Fundamentals The ARM Cortex-A53 processor, part of the ARMv8-A architecture, supports multiple exception levels (ELs) and execution states (aarch32 and aarch64). Exception levels provide a hierarchical privilege model, with EL3 being the highest privilege level typically used for secure monitor code, EL2 for hypervisor functionality, and EL1 for

ARM Cortex-M4 Immediate Value Rotation and Shift Support Issues in STM32F4

ARM Cortex-M4 Immediate Value Rotation and Shift Support Issues in STM32F4

BySystem on Chips

ARM Cortex-M4 Immediate Value Encoding Limitations in MOV Instructions The ARM Cortex-M4 processor, as part of the ARMv7-M architecture, employs a specific instruction set that includes both Thumb and Thumb-2 instructions. One of the key features of this architecture is its ability to handle immediate values in data processing instructions, such as the MOV instruction.

Enforcing Instruction Execution Order in ARM AArch64 with ISB Barriers

Enforcing Instruction Execution Order in ARM AArch64 with ISB Barriers

BySystem on Chips

ARM Cortex-A Series Instruction Reordering and System Register Synchronization In ARM AArch64 architectures, particularly in the Cortex-A series, the processor’s out-of-order execution capabilities can lead to subtle issues when dealing with system registers and memory operations. The specific scenario involves ensuring that a write to the Performance Monitors Control Register (PMCR_EL0) is completed before a

ARM Cortex-M4 Single-Cycle STR.W Instruction Execution Explained

ARM Cortex-M4 Single-Cycle STR.W Instruction Execution Explained

BySystem on Chips

ARM Cortex-M4 Store Instruction Pipeline Optimization The ARM Cortex-M4 processor, like many modern microprocessors, employs a variety of techniques to optimize instruction execution. One such optimization involves the pipelining of memory access instructions, specifically the STR.W (Store Register) instruction. This optimization allows consecutive STR.W instructions to complete in a single cycle under certain conditions. The

Leave a Reply

Your email address will not be published. Required fields are marked *