Resolving BP140 Memory Size Configuration Issues in ARM Cycle Models

BP140 Memory Range Limitation Leading to Data Abort Exceptions

The core issue revolves around the BP140 memory model in an ARM-based cycle model platform, which includes an A55x2 cluster, CCI550 interconnect, GIC600 interrupt controller, NIC400 network interconnect, and BP140_trickbox. The problem manifests when executing load (LDR) instructions targeting memory addresses above 0x1000_0000, resulting in a data abort exception. Store (STR) operations to the same address range succeed without issues, indicating a discrepancy between the memory model’s write and read capabilities. The BP140 memory model is configured as the default slave for the NIC400 interconnect, with a declared address range of [0, 0xFFFF_FFFF]. However, empirical evidence suggests that the BP140 memory model only supports a smaller address range of [0, 0x0FFF_FFFF], leading to the observed data abort exceptions during read operations.

The tarmac trace provided highlights the sequence of events leading to the data abort exception. A MOV instruction loads the address 0x2800_0000 into register r4, followed by a successful STR operation to this address. However, the subsequent LDR operation from the same address triggers a data abort exception, with the Data Fault Address Register (DFAR) correctly capturing the faulting address (0x2800_0000). This behavior strongly indicates that the BP140 memory model is not correctly configured to handle memory accesses beyond the 0x0FFF_FFFF boundary, despite the NIC400 interconnect being configured to route such accesses to the BP140.

Misconfigured BP140 Memory Model and NIC400 Address Decoding

The root cause of this issue lies in the misconfiguration of the BP140 memory model and the NIC400 interconnect’s address decoding logic. The BP140 memory model is a behavioral memory model used in ARM cycle models for simulation and verification purposes. It is designed to emulate a memory subsystem with configurable size, latency, and other parameters. However, the default configuration of the BP140 memory model often does not match the intended memory map of the system, leading to access violations and data abort exceptions.

In this specific case, the BP140 memory model is likely instantiated with a default memory size of 256MB (0x0FFF_FFFF), while the NIC400 interconnect is configured to route all memory accesses in the range [0, 0xFFFF_FFFF] to the BP140. This mismatch between the BP140’s actual memory size and the NIC400’s address decoding logic results in successful write operations (due to the BP140’s write-through behavior) but failed read operations (due to the BP140’s inability to service reads beyond its configured memory size).

Additionally, the BP140_trickbox, which is often used to inject faults or modify memory behavior during simulation, may also contribute to the issue if it is not correctly configured to handle the extended memory range. The trickbox typically operates in conjunction with the BP140 memory model, and any misconfiguration in the trickbox can exacerbate the memory range limitation.

Reconfiguring BP140 Memory Size and NIC400 Address Decoding

To resolve this issue, the BP140 memory model must be reconfigured to support the full memory range specified in the NIC400 interconnect’s address decoding logic. This involves modifying the BP140’s configuration parameters to extend its memory size to 4GB (0xFFFF_FFFF). The following steps outline the necessary actions to achieve this:

1. Modify BP140 Memory Model Configuration: The BP140 memory model’s configuration file or instantiation parameters must be updated to reflect the desired memory size. This typically involves setting the memory_size parameter to 0xFFFF_FFFF. The exact method for modifying this parameter depends on the simulation environment and the specific instantiation of the BP140 memory model. For example, in a SystemVerilog-based simulation environment, the BP140 memory model might be instantiated with a parameter override:

   bp140_memory_model #(
       .MEMORY_SIZE(32'hFFFF_FFFF)
   u_bp140 (
       .clk(clk),
       .resetn(resetn),
       .address(address),
       .write_data(write_data),
       .read_data(read_data),
       .write_enable(write_enable),
       .read_enable(read_enable)
   );
   

2. Verify NIC400 Address Decoding Logic: Ensure that the NIC400 interconnect’s address decoding logic is correctly configured to route memory accesses in the range [0, 0xFFFF_FFFF] to the BP140 memory model. This involves reviewing the NIC400’s configuration registers or RTL code to confirm that the BP140 is correctly mapped as the default slave for the specified address range. Any discrepancies in the address decoding logic must be corrected to align with the BP140’s reconfigured memory size.

3. Update BP140_trickbox Configuration: If the BP140_trickbox is used in the simulation, its configuration must also be updated to support the extended memory range. This may involve modifying the trickbox’s address range parameters or ensuring that it correctly interfaces with the reconfigured BP140 memory model. The trickbox’s configuration should be reviewed to ensure that it does not inadvertently restrict memory accesses or introduce faults in the extended address range.

4. Re-run Simulation and Verify Behavior: After reconfiguring the BP140 memory model and NIC400 address decoding logic, re-run the simulation to verify that the data abort exceptions no longer occur. The tarmac trace should be reviewed to confirm that LDR operations to addresses above 0x1000_0000 now succeed without triggering data abort exceptions. Additionally, the simulation should be tested with a variety of memory access patterns to ensure that the BP140 memory model behaves as expected across the entire address range.

5. Validate System-Level Functionality: Finally, validate the system-level functionality to ensure that the reconfiguration of the BP140 memory model and NIC400 interconnect does not introduce any unintended side effects. This includes verifying that other components in the system, such as the A55x2 cluster, CCI550 interconnect, and GIC600 interrupt controller, continue to operate correctly with the updated memory configuration. Any system-level tests or benchmarks should be re-executed to confirm that the overall system performance and functionality remain intact.

By following these steps, the BP140 memory model can be correctly configured to support the full memory range specified in the NIC400 interconnect’s address decoding logic, eliminating the data abort exceptions and ensuring reliable memory access across the entire address space. This approach not only resolves the immediate issue but also provides a systematic method for configuring and verifying memory models in ARM-based SoC designs.