You copied the Doc URL to your clipboard.

Running the Cortex-M7 r1p1 or r1p2 Integration Kit

Information in this article applies to:

  • Cortex-M7


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 "", 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: wrong ELF class: ELFCLASS64
  ../shared/tarmac/bin/cm7_tarmac_decode: error while loading shared libraries: 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.





Related Information


Was this page helpful? Yes No