AXI4 Protocol Evolution: The Absence of WID
The Advanced eXtensible Interface (AXI) protocol, developed by ARM, has undergone significant evolution from AXI3 to AXI4. One of the most notable changes in AXI4 is the removal of the Write ID (WID) signal, which was present in AXI3. The WID signal in AXI3 was used to support write data interleaving, a feature that allowed multiple write transactions to be interleaved at the data bus level. This interleaving was particularly useful in systems where multiple masters could issue write transactions concurrently, and the interconnect needed to manage the ordering and completion of these writes efficiently.
In AXI4, the removal of WID is a deliberate design choice aimed at simplifying the protocol and reducing the complexity of the interconnect logic. The AXI4 protocol no longer supports write data interleaving, which means that write transactions must be completed in the order they are issued. This change has significant implications for system-on-chip (SoC) designers, particularly those transitioning from AXI3 to AXI4 or integrating legacy AXI3 components into an AXI4-based system.
The removal of WID in AXI4 is documented in section A5.4.1 of the AXI protocol specification. This section explains that the WID signal was necessary in AXI3 to support write data interleaving, but since AXI4 does not support this feature, the WID signal is no longer required. Furthermore, section A5.4.2 of the specification provides guidance for designers who need to integrate legacy AXI3 components that still require a WID input. In such cases, the WID can be generated using the ID conveyed on the AWID signal.
Impact of WID Removal on SoC Design and Verification
The removal of WID in AXI4 has several implications for SoC design and verification. First, it simplifies the design of the interconnect and reduces the number of signals that need to be routed between components. This reduction in signal count can lead to a decrease in the overall complexity of the SoC, potentially reducing the area and power consumption of the design. However, the removal of WID also means that the system must handle write transactions differently, particularly in systems that previously relied on write data interleaving to achieve high performance.
In AXI3, write data interleaving allowed multiple write transactions to be interleaved on the data bus, which could improve the efficiency of the system by allowing multiple masters to issue writes concurrently. In AXI4, since write data interleaving is no longer supported, write transactions must be completed in the order they are issued. This change can impact the performance of the system, particularly in scenarios where multiple masters are issuing write transactions to the same slave.
For SoC designers, the removal of WID in AXI4 requires careful consideration of the system’s performance requirements and the potential impact on the design. In some cases, the loss of write data interleaving may necessitate changes to the system architecture, such as the addition of more write buffers or the use of a different interconnect topology to maintain performance. Additionally, designers must ensure that any legacy AXI3 components that require a WID input are properly integrated into the AXI4 system, as described in section A5.4.2 of the AXI protocol specification.
From a verification perspective, the removal of WID in AXI4 introduces new challenges. Verification engineers must ensure that the system correctly handles write transactions in the absence of write data interleaving. This includes verifying that write transactions are completed in the correct order and that the system does not attempt to interleave write data. Additionally, verification engineers must ensure that any legacy AXI3 components that require a WID input are properly integrated into the AXI4 system and that the WID is correctly generated from the AWID signal.
Strategies for Handling WID Removal in AXI4-Based SoCs
To address the challenges posed by the removal of WID in AXI4, SoC designers and verification engineers can adopt several strategies. First, designers should carefully review the system’s performance requirements and determine whether the loss of write data interleaving will impact the system’s performance. If the system relies heavily on write data interleaving, designers may need to consider alternative approaches to maintain performance, such as increasing the number of write buffers or using a different interconnect topology.
For systems that include legacy AXI3 components, designers must ensure that these components are properly integrated into the AXI4 system. This includes generating the WID signal from the AWID signal, as described in section A5.4.2 of the AXI protocol specification. Designers should also verify that the legacy components are compatible with the AXI4 protocol and that they do not rely on write data interleaving.
From a verification perspective, engineers should develop test cases that specifically target the handling of write transactions in the absence of WID. These test cases should verify that write transactions are completed in the correct order and that the system does not attempt to interleave write data. Additionally, verification engineers should develop test cases to ensure that any legacy AXI3 components are properly integrated into the AXI4 system and that the WID is correctly generated from the AWID signal.
In conclusion, the removal of WID in AXI4 represents a significant change in the AXI protocol, with important implications for SoC design and verification. By understanding the reasons for this change and adopting appropriate strategies, designers and verification engineers can ensure that their AXI4-based systems are both efficient and reliable. The key to success lies in careful analysis of the system’s requirements, proper integration of legacy components, and thorough verification of the system’s behavior in the absence of write data interleaving.
