Triggering Simulation Stop in Corstone-300 MPS3 FVP via Application Code

Application-Triggered Simulation Stop Requirement in Corstone-300 MPS3 FVP

In the context of ARM-based SoC verification, particularly when using the Corstone-300 MPS3 Fixed Virtual Platform (FVP), a common challenge arises when attempting to trigger a simulation stop directly from the application code. This requirement is critical for automating test suites, ensuring that the simulation terminates cleanly upon test completion or failure, without relying on external monitoring mechanisms such as UART output parsing. The Corstone-300 FVP, which integrates ARM Cortex-M processors and other system components, is widely used for pre-silicon validation and software development. However, the lack of a straightforward mechanism to halt the simulation programmatically can lead to inefficiencies and unreliable test automation workflows.

The primary issue revolves around the need for a robust and clean method to terminate the simulation from within the application code. Currently, many developers resort to workarounds, such as monitoring UART outputs or manually stopping the simulation, which are neither scalable nor reliable for large-scale verification environments. This problem is particularly pronounced in scenarios where thousands of tests are executed in sequence, and manual intervention is impractical. The absence of a native mechanism to trigger a simulation stop from the application code complicates the verification process, especially when integrating with continuous integration (CI) pipelines or automated regression testing frameworks.

Semi-Hosting as a Solution for Simulation Control

The root cause of this challenge lies in the limited interaction between the application code running on the ARM Cortex-M processor and the simulation environment provided by the Corstone-300 MPS3 FVP. The FVP, which is based on ARM Fast Models, does not natively expose APIs or mechanisms for the application code to communicate directly with the simulation environment. This limitation necessitates the use of semi-hosting, a technique that allows the embedded application to communicate with the host system running the simulation.

Semi-hosting is a feature supported by ARM Fast Models that enables the embedded software to perform operations such as file I/O, debugging, and, crucially, simulation control by making service calls to the host system. These service calls are intercepted by the Fast Model simulation environment, which then executes the corresponding actions on the host. In the context of the Corstone-300 MPS3 FVP, semi-hosting can be leveraged to trigger a simulation stop by invoking specific semi-hosting calls from the application code. This approach provides a cleaner and more robust alternative to external monitoring mechanisms, as it allows the application to directly control the simulation lifecycle.

However, the implementation of semi-hosting requires careful configuration of both the application code and the simulation environment. The application must be compiled with semi-hosting support enabled, and the FVP must be configured to recognize and process semi-hosting calls. Additionally, the specific semi-hosting call used to trigger a simulation stop must be identified and integrated into the application code. This process involves understanding the ARM Fast Models documentation and the specific semi-hosting capabilities supported by the Corstone-300 FVP.

Implementing Semi-Hosting for Simulation Stop in Corstone-300 FVP

To address the challenge of triggering a simulation stop from application code in the Corstone-300 MPS3 FVP, the following steps can be taken:

1. Enable Semi-Hosting Support in the Application Code: The first step is to ensure that the application code is compiled with semi-hosting support enabled. This typically involves adding specific compiler flags, such as --specs=rdimon.specs for ARM GCC, which link the application against the semi-hosting library. This library provides the necessary stubs for semi-hosting calls, allowing the application to communicate with the simulation environment.

2. Identify the Appropriate Semi-Hosting Call: ARM Fast Models support a range of semi-hosting calls, each identified by a unique number. To trigger a simulation stop, the application must invoke the appropriate semi-hosting call. For example, the SYS_EXIT semi-hosting call (number 0x18) can be used to terminate the simulation. This call is typically implemented using the __asm keyword in C/C++ code, as shown below:

   __asm("mov r0, #0x18\n"  // SYS_EXIT call number
         "mov r1, #0x00\n"  // Exit code (0 for success)
         "bkpt 0xAB");
   

   This assembly code places the semi-hosting call number in register r0, the exit code in register r1, and triggers the semi-hosting operation using the bkpt instruction.

3. Configure the Corstone-300 FVP to Recognize Semi-Hosting Calls: The FVP must be configured to recognize and process semi-hosting calls from the application code. This is typically done by enabling semi-hosting support in the FVP configuration file or command-line arguments. For example, the --semihosting flag can be used to enable semi-hosting when launching the FVP:

   ./FVP_Corstone-300 --semihosting
   

   This ensures that the FVP intercepts semi-hosting calls from the application and performs the corresponding actions, such as terminating the simulation.

4. Integrate the Simulation Stop Mechanism into the Test Framework: Once semi-hosting is enabled and the appropriate semi-hosting call is identified, the simulation stop mechanism can be integrated into the test framework. This involves adding the semi-hosting call at the end of each test case or in the event of a test failure. For example:

   void test_case() {
       // Test logic
       if (test_passed) {
           // Trigger simulation stop with success code
           __asm("mov r0, #0x18\n"
                 "mov r1, #0x00\n"
                 "bkpt 0xAB");
       } else {
           // Trigger simulation stop with failure code
           __asm("mov r0, #0x18\n"
                 "mov r1, #0x01\n"
                 "bkpt 0xAB");
       }
   }
   

   This ensures that the simulation terminates cleanly after each test, providing a clear indication of the test outcome.

5. Validate the Implementation: The final step is to validate the implementation by running the test suite on the Corstone-300 FVP and verifying that the simulation stops correctly after each test. This involves checking the simulation logs and ensuring that the semi-hosting calls are being processed as expected. Any issues, such as incorrect semi-hosting call numbers or misconfigured FVP settings, should be identified and resolved during this phase.

By following these steps, developers can implement a robust and clean mechanism to trigger simulation stops from application code in the Corstone-300 MPS3 FVP. This approach eliminates the need for external monitoring mechanisms and provides a more reliable and scalable solution for automated test execution. Additionally, it leverages the semi-hosting capabilities of ARM Fast Models, ensuring compatibility with the broader ARM ecosystem and facilitating integration with existing verification workflows.

In conclusion, the use of semi-hosting to trigger simulation stops in the Corstone-300 MPS3 FVP represents a significant improvement over traditional methods, offering a cleaner, more reliable, and scalable solution for automated test execution. By enabling semi-hosting support in the application code, identifying the appropriate semi-hosting call, configuring the FVP, and integrating the mechanism into the test framework, developers can achieve precise control over the simulation lifecycle, enhancing the efficiency and reliability of the verification process.