AXI INCR Burst Transfer Mismatch Between 64-bit Data and 32-bit Bus
When designing an ARM-based SoC, one common challenge is handling AXI INCR (Incrementing) burst transfers when the data width of the transaction does not match the bus width. In this case, the issue arises when a 64-bit data transaction needs to be transferred over a 32-bit AXI bus. The AXI protocol supports burst transfers, including INCR bursts, which are widely used for sequential memory access. However, the protocol does not inherently handle data width conversion, leaving it to the designer to implement the necessary logic.
The AXI INCR burst type is designed to handle sequential addresses, where each transfer in the burst increments the address by the size of the data transfer. For example, a 64-bit INCR burst with a length of 4 would transfer 256 bits of data across 4 beats, with the address incrementing by 8 bytes (64 bits) after each beat. However, when the bus width is only 32 bits, the 64-bit data must be split into two 32-bit transfers, effectively doubling the number of beats required to complete the burst.
This mismatch introduces several challenges. First, the address increment logic must be adjusted to account for the narrower bus width. Second, the burst length must be recalculated to ensure that all data is transferred correctly. Third, the handshaking signals (such as AWREADY, WVALID, and BVALID) must be managed carefully to avoid protocol violations. Finally, the downsizing logic must ensure that the data integrity is maintained throughout the transfer.
Data Width Conversion Logic and Burst Length Adjustment
The root cause of the issue lies in the mismatch between the data width of the transaction and the bus width. AXI does not provide built-in support for data width conversion, so the designer must implement custom logic to handle this scenario. This logic must perform two key functions: data width conversion and burst length adjustment.
For data width conversion, the 64-bit data must be split into two 32-bit chunks. The lower 32 bits are transferred first, followed by the upper 32 bits. This requires additional logic to manage the data splitting and reassembly. The address increment logic must also be modified to account for the narrower bus width. In a 64-bit transaction, the address increments by 8 bytes after each beat. However, when the data is split into 32-bit chunks, the address must increment by 4 bytes after each beat.
Burst length adjustment is another critical aspect. In AXI, the burst length is specified in the AWLEN signal, which indicates the number of beats in the burst. For a 64-bit transaction with a burst length of 4, the AWLEN signal would be set to 3 (since AXI uses zero-based counting). However, when the data is split into 32-bit chunks, the burst length must be doubled to 8 beats. This requires modifying the AWLEN signal and ensuring that the downstream logic can handle the increased burst length.
The downsizing logic must also handle potential protocol violations. For example, if the original 64-bit transaction has a burst length that exceeds the maximum allowed by the AXI protocol, the downsizing logic must split the transaction into multiple bursts. This introduces additional complexity, as the logic must manage multiple bursts while maintaining data integrity and protocol compliance.
Implementing Data Width Conversion and Protocol Compliance
To address the challenges of transferring a 64-bit INCR burst over a 32-bit AXI bus, the following steps can be taken:
Data Width Conversion Logic
The first step is to implement data width conversion logic. This logic splits the 64-bit data into two 32-bit chunks and reassembles the data at the destination. The conversion logic must handle the following tasks:
-
Data Splitting: The 64-bit data is split into two 32-bit chunks. The lower 32 bits are transferred first, followed by the upper 32 bits. This requires additional registers to store the intermediate data.
-
Address Increment Adjustment: The address increment logic must be modified to account for the narrower bus width. In a 64-bit transaction, the address increments by 8 bytes after each beat. However, when the data is split into 32-bit chunks, the address must increment by 4 bytes after each beat.
-
Burst Length Adjustment: The burst length must be doubled to account for the increased number of beats. For example, a 64-bit burst with a length of 4 must be converted to a 32-bit burst with a length of 8.
-
Handshaking Signal Management: The handshaking signals (
AWREADY,WVALID,BVALID, etc.) must be managed carefully to avoid protocol violations. The conversion logic must ensure that the signals are asserted and deasserted at the correct times.
Protocol Compliance
The downsizing logic must ensure that the AXI protocol is followed correctly. This includes:
-
Burst Splitting: If the original 64-bit burst exceeds the maximum allowed burst length, the downsizing logic must split the burst into multiple smaller bursts. Each burst must comply with the AXI protocol, including proper handling of the
AWLEN,AWSIZE, andAWBURSTsignals. -
Data Integrity: The downsizing logic must ensure that the data integrity is maintained throughout the transfer. This includes proper handling of the
WSTRBsignal, which indicates which bytes of the data are valid. -
Error Handling: The downsizing logic must handle errors gracefully. For example, if an error occurs during the transfer, the logic must ensure that the error is propagated correctly and that the transaction is terminated properly.
Verification Strategy
To verify the correctness of the downsizing logic, a comprehensive verification strategy must be implemented. This includes:
-
Functional Verification: The downsizing logic must be verified to ensure that it correctly converts 64-bit bursts to 32-bit bursts. This includes testing various burst lengths, address increments, and data patterns.
-
Protocol Compliance Verification: The downsizing logic must be verified to ensure that it complies with the AXI protocol. This includes testing various scenarios, such as burst splitting, error handling, and handshaking signal management.
-
Performance Verification: The downsizing logic must be verified to ensure that it does not introduce significant performance overhead. This includes testing the latency and throughput of the downsizing logic under various conditions.
-
Corner Case Testing: The downsizing logic must be tested against various corner cases, such as maximum burst lengths, unusual address increments, and unexpected error conditions.
Example Implementation
Below is an example implementation of the downsizing logic in SystemVerilog:
module axi_width_converter (
input logic ACLK,
input logic ARESETn,
// AXI Master Interface (64-bit)
input logic [63:0] M_AXI_WDATA,
input logic [7:0] M_AXI_WSTRB,
input logic M_AXI_WVALID,
output logic M_AXI_WREADY,
// AXI Slave Interface (32-bit)
output logic [31:0] S_AXI_WDATA,
output logic [3:0] S_AXI_WSTRB,
output logic S_AXI_WVALID,
input logic S_AXI_WREADY
);
logic [31:0] lower_data;
logic [31:0] upper_data;
logic [3:0] lower_strb;
logic [3:0] upper_strb;
logic lower_valid;
logic upper_valid;
always_ff @(posedge ACLK or negedge ARESETn) begin
if (!ARESETn) begin
lower_data <= 32'h0;
upper_data <= 32'h0;
lower_strb <= 4'h0;
upper_strb <= 4'h0;
lower_valid <= 1'b0;
upper_valid <= 1'b0;
end else begin
if (M_AXI_WVALID && M_AXI_WREADY) begin
lower_data <= M_AXI_WDATA[31:0];
upper_data <= M_AXI_WDATA[63:32];
lower_strb <= M_AXI_WSTRB[3:0];
upper_strb <= M_AXI_WSTRB[7:4];
lower_valid <= 1'b1;
upper_valid <= 1'b1;
end else if (S_AXI_WREADY) begin
lower_valid <= 1'b0;
upper_valid <= 1'b0;
end
end
end
assign S_AXI_WDATA = lower_valid ? lower_data : upper_data;
assign S_AXI_WSTRB = lower_valid ? lower_strb : upper_strb;
assign S_AXI_WVALID = lower_valid || upper_valid;
assign M_AXI_WREADY = S_AXI_WREADY && !(lower_valid || upper_valid);
endmodule
This example demonstrates how the 64-bit data is split into two 32-bit chunks and how the handshaking signals are managed to ensure protocol compliance.
Conclusion
Handling AXI INCR burst transfers with mismatched data and bus widths is a complex but manageable challenge. By implementing custom data width conversion logic and carefully managing the AXI protocol signals, it is possible to transfer 64-bit data over a 32-bit bus without violating the protocol. A comprehensive verification strategy is essential to ensure the correctness and performance of the downsizing logic. With careful design and thorough testing, this challenge can be successfully addressed in ARM-based SoC designs.
