Custom Accelerator Integration Challenges with ARM CoreLink CMN-600
Integrating a custom accelerator with ARM CoreLink CMN-600 using the CHI (Coherent Hub Interface) or ACE-Lite (AXI Coherency Extensions Lite) interface presents several technical challenges. The CoreLink CMN-600 is a highly configurable interconnect designed for high-performance SoCs, supporting both coherent and non-coherent transactions. The CHI protocol is a packet-based, high-performance interface optimized for coherent data transfers, while ACE-Lite is a simplified version of the ACE protocol, supporting I/O coherency but not full system coherency. The custom accelerator must adhere to the specific requirements of these protocols to ensure seamless integration with the CMN-600.
The primary challenge lies in implementing the CHI or ACE-Lite interface on the custom accelerator. This involves understanding the protocol specifications, designing the interface logic, and ensuring compliance with the timing and functional requirements of the CMN-600. Additionally, the custom accelerator must handle coherency and memory ordering correctly, especially when interacting with other system components such as CPUs, GPUs, and memory controllers. The complexity of these protocols, combined with the need for high performance and low latency, makes this a non-trivial task.
Another challenge is the lack of readily available tools for generating RTL code for CHI or ACE-Lite interfaces. While ARM provides extensive documentation and specifications for these protocols, there is no automated tool that can generate the RTL code for the interface. This means that the design team must manually implement the interface, which requires a deep understanding of the protocol and careful attention to detail to avoid errors that could lead to functional or timing issues.
Protocol Specification Gaps and Tool Limitations
One of the main reasons for the difficulty in integrating a custom accelerator with the CoreLink CMN-600 is the complexity of the CHI and ACE-Lite protocols. These protocols are designed to support high-performance, low-latency communication between multiple system components, but they also introduce significant complexity in terms of protocol state machines, transaction ordering, and coherency management. The CHI protocol, in particular, is highly optimized for coherent data transfers and includes features such as snoop filtering, home node management, and distributed virtual memory (DVM) operations. These features require careful implementation to ensure correct operation and compliance with the protocol.
The ACE-Lite protocol, while simpler than CHI, still requires careful handling of coherency and memory ordering. ACE-Lite supports I/O coherency, which allows I/O devices to access cached data without requiring explicit cache maintenance operations. However, this requires the custom accelerator to correctly implement the ACE-Lite signals, such as AxDOMAIN, AxSNOOP, and AxBAR, which control the coherency and memory attributes of transactions. Incorrect implementation of these signals can lead to coherency violations, data corruption, or system deadlocks.
Another issue is the lack of automated tools for generating RTL code for CHI or ACE-Lite interfaces. While ARM provides detailed specifications and documentation for these protocols, there is no tool that can automatically generate the RTL code for the interface. This means that the design team must manually implement the interface, which is a time-consuming and error-prone process. The lack of automated tools also makes it difficult to verify the correctness of the interface, as the design team must rely on simulation and formal verification to ensure compliance with the protocol.
Manual RTL Implementation and Verification Strategies
Given the lack of automated tools for generating RTL code for CHI or ACE-Lite interfaces, the design team must manually implement the interface. This involves several steps, including protocol analysis, interface design, RTL coding, and verification. The first step is to thoroughly analyze the CHI or ACE-Lite protocol specifications to understand the requirements for the interface. This includes understanding the protocol state machines, transaction types, and coherency rules. The design team must also consider the specific requirements of the CoreLink CMN-600, such as the supported transaction sizes, burst lengths, and latency requirements.
Once the protocol requirements are understood, the next step is to design the interface logic. This involves defining the interface signals, state machines, and transaction handling logic. The interface must be designed to handle all possible transaction types and coherency scenarios, including read and write transactions, cache maintenance operations, and DVM operations. The design team must also consider the timing requirements of the interface, ensuring that the interface logic meets the setup and hold times for all signals.
After the interface logic is designed, the next step is to implement the RTL code. This involves coding the interface logic in a hardware description language such as SystemVerilog or VHDL. The RTL code must be carefully written to ensure that it correctly implements the interface logic and complies with the protocol specifications. The design team must also consider the synthesis and timing constraints for the interface, ensuring that the RTL code can be synthesized into a gate-level netlist that meets the timing requirements of the target technology.
Once the RTL code is implemented, the next step is to verify the interface. This involves both simulation and formal verification. Simulation is used to verify the functional correctness of the interface, ensuring that it correctly handles all transaction types and coherency scenarios. The design team must create a comprehensive testbench that includes all possible transaction types and coherency scenarios, as well as corner cases and error conditions. The testbench must also include models of the CoreLink CMN-600 and other system components to ensure that the interface correctly interacts with these components.
Formal verification is
