Running the Cortex-M7 r1p1 or r1p2 Integration Kit
Information in this article applies to:
How can I run the Cortex-M7 r1p1 or r1p2 Integration Kit (IK)?
The Arm Cortex-M7 Processor Integration and Implementation Manual (IIM) is a confidential document that is provided to chip designers who have licensed the Cortex-M7 RTL for their chip design.
This IIM has a chapter that describes the Integration Kit (IK). The IK is an example MCU environment with a set of test programs that can be run to confirm your configuration settings. The Cortex-M7 processor is instantiated in a simple MCU chip design, which is then instantiated in the execution testbench (execution_tb). You can migrate your own chip design into this environment, to test various aspects of your top-level chip, such as debug connectivity.
The section Running the testbench in the IIM describes how to run the example programs that are provided with the testbench. However, this article provides more information on useful settings and switches.
This knowledge article was originally written for the Cortex-M7 r1p1 release, but applies also to the r1p2 release. Licensees are recommended to migrate to r1p2 for ongoing designs. This patch release fixes a critical erratum, 1259864, described in the Cortex-M7 (AT610) and Cortex-M7 with FPU (AT611) Software Developer Errata Notice v8.0.
The example commands that are shown in the IIM for running the testbench illustrate the SIM option and the TESTNAME option. The SIM option allows you to choose between the three supported simulators. The TESTNAME option allows you to choose an individual test to run, or to run all tests by selecting “all”.
The command to run an individual test is also possible with the optional PLUSARGS switch. This supplies extra command line arguments to the CAD vendor toolchain. For multiple arguments, the list must be enclosed in double quotation marks (" ") as mentioned in the IIM. However, if only a single argument is used, the double quotation marks can be omitted. These arguments might be tool-specific, or they might give different results between different CAD toolchains. For example, the “-gui” argument that is shown in the IIM gives different and unexpected behaviors in different toolchains. Instead, use the GUI=yes switch when you want a GUI-based simulation.
The Makefile picks up the default argument settings from the make.cfg file, as summarized in the section Configuring the testbench in the IIM. These default argument settings can be modified by editing the make.cfg file, or by overriding the default setting on the command line. As can be seen in the make.cfg file, the default settings that are supplied by Arm are all “<argument> := no”. These settings can be changed by editing the file to say “<argument> := yes” or by adding “<argument>=yes” on the command line.
Note the difference in syntax “ := ” with spaces versus “=” with no space. Also, “yes” is lowercase in both instances (not “YES” or “Yes”).
Therefore, a typical invocation of the Makefile to run the “hello_world” test in VCS with the tarmac logging feature enabled might be:
make run SIM=vcs TESTNAME=hello_world TARMAC=yes
Tarmac logging is recommended for debugging any unexpected simulation results. To use tarmac logging, the Cortex-M7 needs the Google Protocol Buffers object to be linked to the simulation. As noted in the Cortex-M7 r1p1 00rel0 Release Note, the required version of Protobuf is 2.4.1, and it is specifically the 32-bit object that is needed. The relevant pathname to this object needs to be added to your shell environment.
The Release Note implies that newer versions of EDA tools than shown are also valid, but in the case of the Google Protocol Buffers this is not correct. Newer versions do not contain the exact file "libprotobuf.so.7", and therefore do not work with the supplied tarmac object file.
On a 64-bit architecture workstation or compute server, the simulator can be invoked in 64-bit mode using the “SIM_64BIT=yes” switch. However, the test cases that are provided and the execution_tb example design are small enough to run in the 32-bit version of the simulator. Note that when running with “SIM_64BIT=yes”, it is still the 32-bit Protobuf object that is required for tarmac logging. Selecting the 64-bit Protobuf object causes error messages:
../shared/tarmac/bin/cm7_tarmac_decode: error while loading shared libraries: libprotobuf.so.7: wrong ELF class: ELFCLASS64 ../shared/tarmac/bin/cm7_tarmac_decode: error while loading shared libraries: libprotobuf.so.7: wrong ELF class: ELFCLASS64 [cm7_tarmac] Error: could not write trace: Broken pipe [cm7_tarmac] Error: could not write trace: Broken pipe
The general purpose of the Integration Kit (IK) is to run all of the tests that are provided. The IIM explains how to modify the configuration parameters and configuration pins for the processor in the execution_tb design. The IIM also explains how to change the “EXPECTED_” values to match the changes in the design. When the tests are all run together, the Makefile finishes by printing a summary of the success or failure of each test, for example:
Test Summary Time: 7938170 Test count: 15 Passes: 14, Fails: 1, Kills: 0 Skipped: 0, Warnings: 0, ovls: 0 hello_world time: 103050 status: PASS tcm time: 116700 status: PASS romtable time: 1309310 status: FAIL config_check time: 1547970 status: PASS debug time: 1618810 status: PASS maxpwr time: 259190 status: PASS etm_i_trace time: 638300 status: PASS interrupt time: 498120 status: PASS dhrystone time: 140300 status: PASS mpu time: 169840 status: PASS vtor time: 104720 status: PASS reset time: 197040 status: PASS itm_trace time: 678410 status: PASS wfi time: 100960 status: PASS sleep time: 455450 status: PASS
These test results are determined by scanning the resulting log file from each simulation run, located in the ./logs/. subdirectory.
Similarly, when a single test is run, the Makefile reports the outcome from that single test, for example:
hello_world time: 103050 status: PASS
However, when the simulation is run using the GUI, the transcript is not automatically logged to the log file. This lack of automation means that the summary report at the end of the run incorrectly reports that the run did not complete:
hello_world time: 0 status: KILLED Did not complete
The true completion status can be seen in the simulator transcript pane, for example:
# ** TEST PASSED OK ** (Time: 103050)
Unlike the testbenches that are delivered with some other Cortex-M processors, the Cortex-M7 testbench does not, by default, print the simulation log into the shell window. This feature is available by adjusting the Makefile. The relevant definition of “TEE” is located near the top of the file:
# Swap the commented lines to send output to the screen #TEE = | tee TEE = >
The behavior of the PLUSARGS=”-gui” switch is inconsistent across the different simulators.
For example, on MTI (QuestaSim-64 vlog 10.5c_2 Compiler 2016.10), the PLUSARGS=”-gui” switch opens the GUI in the simulator. The simulation then starts and runs to completion. You are not able to interact with the GUI settings, for example by setting waveform traces. The simulation finishes with a popup window that asks “Are you sure you want to finish?”, but both the “Yes” and “No” buttons terminate the session.
On VCS (vcs/2017.03-SP1), the PLUSARGS=”-gui” switch causes simv to terminate prematurely as follows:
Error-[DEBUG-PRCWDBG] DVE/VERDI debug flag error DVE/VERDI debugging is not enabled at compile time Please recompile with '-debug_access+r' to enable minimum DVE/VERDI debugging. For more details, please refer to "Options For Debugging Using DVE and UCLI and VERDI".
On IUS (ncsim(64): 15.20-s008), the PLUSARGS=”-gui” switch is ignored, and the simulation runs as a normal non-GUI run.