CMN700 Register Read Requests Not Serviced by CMN700 Directly
The core issue revolves around the inability of an ARM N1 core to successfully read a CMN700 register in a FastModel simulation environment. The ARM N1 core initiates a read request targeting a CMN700 register at address 0x42d1d80, but the request is not serviced directly by the CMN700. Instead, the request traverses through multiple components, including the CMN700, NI700, PVBusDecoder, and CMN700_APB slave port, ultimately resulting in a DECERR (Decode Error) or SLVERR (Slave Error). This behavior indicates a breakdown in the communication path between the ARM N1 core and the CMN700 register, preventing the successful retrieval of the register’s value.
The CMN700 is configured in the FastModel simulation using a YAML file (cmn700_nxc_topology.yml) that defines the topology of the mesh interconnect. The CFGM_PERIPHBASE_PARAM is set to 0x400000000, which should theoretically map the CMN700 registers to the correct address space. However, the read request fails, suggesting a misconfiguration or an issue in the address translation or routing logic within the CMN700 or its associated components.
The PVBusLogger, a debugging tool integrated into the simulation, captures the transaction flow and reveals that the request from the ARM N1 core is correctly issued but encounters errors at multiple stages. Specifically, the request is first logged as a DECERR at the CMN700 level, followed by a SLVERR at the PVBusDecoder and NI700 levels. This sequence of errors indicates that the request is either being misrouted, encountering an unsupported address range, or failing due to an incorrect configuration of the CMN700 or its peripheral interfaces.
Misconfigured CMN700 YAML File and Address Mapping Issues
One of the primary causes of the CMN700 register access failure is the potential misconfiguration of the CMN700 YAML file. The CMN700 model in FastModel relies on a YAML file generated by Arm Socrates to define the topology and configuration of the interconnect. If the YAML file is not correctly formatted or does not accurately reflect the intended system configuration, the CMN700 may fail to initialize properly, leading to incorrect address mapping and routing of transactions.
The CFGM_PERIPHBASE_PARAM parameter, set to 0x400000000, is intended to define the base address for the CMN700 configuration space. However, if this parameter does not align with the address map defined in the YAML file or if the YAML file itself contains errors, the CMN700 may not recognize the register address 0x42d1d80 as valid. This misalignment can result in the DECERR observed at the CMN700 level, as the interconnect fails to decode the address correctly.
Additionally, the use of a baremetal ARM64 program to access the CMN700 register introduces another layer of complexity. The ARM N1 core system, particularly in the context of the N1 edge reference design, is typically designed to work with the Arm Reference Design software stack. Running a baremetal application on this system may not account for the necessary firmware initialization steps required to configure the CMN700 and its address map. Without proper firmware initialization, the CMN700 may not be fully operational, leading to the SLVERR observed at the PVBusDecoder and NI700 levels.
The PVBusDecoder and NI700 components play a critical role in routing transactions between the ARM N1 core and the CMN700. If these components are not correctly configured or if there is a mismatch in the address decoding logic, they may fail to route the request to the correct CMN700_APB slave port. This failure can manifest as a SLVERR, indicating that the request could not be serviced by the intended destination.
Correcting CMN700 YAML Configuration and Firmware Initialization
To resolve the CMN700 register access failures, a systematic approach is required to address both the configuration of the CMN700 YAML file and the initialization of the system firmware. The following steps outline the troubleshooting process and potential solutions:
Step 1: Validate the CMN700 YAML File
The first step is to ensure that the CMN700 YAML file (cmn700_nxc_topology.yml) is correctly formatted and accurately reflects the intended system topology. The YAML file must be generated using Arm Socrates, as the CMN700 model in FastModel does not support other formats. Verify that the CFGM_PERIPHBASE_PARAM parameter in the YAML file aligns with the address map defined in the system. If necessary, regenerate the YAML file using Arm Socrates to ensure compatibility with the CMN700 model.
Step 2: Verify Address Mapping and Routing Logic
Next, verify the address mapping and routing logic within the CMN700 and its associated components. Ensure that the address 0x42d1d80 falls within the valid address range defined by the CFGM_PERIPHBASE_PARAM and the YAML file. Use the PVBusLogger to trace the transaction flow and identify any discrepancies in the address decoding or routing logic. If the address mapping is incorrect, adjust the CFGM_PERIPHBASE_PARAM or modify the YAML file to correct the address range.
Step 3: Initialize CMN700 Firmware
The CMN700 requires firmware initialization to configure its address map and operational parameters. If the ARM N1 core system is based on the N1 edge reference design, ensure that the Arm Reference Design software stack is used to initialize the CMN700. The software stack includes the necessary firmware to configure the CMN700 and its address map, ensuring that the interconnect is fully operational before the baremetal application attempts to access the CMN700 registers. If the baremetal application must be used, incorporate the necessary firmware initialization steps into the application to configure the CMN700.
Step 4: Debug PVBusDecoder and NI700 Configuration
The PVBusDecoder and NI700 components must be correctly configured to route transactions between the ARM N1 core and the CMN700. Use the PVBusLogger to capture the transaction flow and identify any errors or misconfigurations in these components. Verify that the address decoding logic in the PVBusDecoder and NI700 aligns with the address map defined in the CMN700 YAML file. If necessary, adjust the configuration of these components to ensure that requests are correctly routed to the CMN700_APB slave port.
Step 5: Implement Data Synchronization Barriers
In some cases, the CMN700 register access failures may be caused by timing or synchronization issues between the ARM N1 core and the CMN700. Implement data synchronization barriers (DSB) in the baremetal application to ensure that the ARM N1 core waits for the completion of the CMN700 register access before proceeding with subsequent instructions. This approach can help mitigate timing-related issues and improve the reliability of the register access.
Step 6: Engage Arm Technical Support
If the above steps do not resolve the issue, consider engaging Arm technical support for further assistance. Arm provides technical support for Fast Models products, and their expertise can help identify and resolve complex issues related to CMN700 configuration and simulation. Provide detailed logs and configuration files to Arm support to facilitate a thorough analysis of the problem.
By following these troubleshooting steps and addressing the potential causes of the CMN700 register access failures, the issue can be resolved, enabling successful simulation and verification of the ARM N1 core system with the CMN700 interconnect.
