ARM Community: Using the ARM Profiler with the Cadence Virtual System Platform - ARM Community

One of the most common requests from software engineers running software on a Virtual Platform is to be able to profile the executing software. In this document I will describe how to use the ARM Profiler included in RVDS Professional with the Fast Models from ARM that are commonly used to create SystemC Virtual Platforms with the Cadence Virtual System Platform (VSP). As you can see from the introduction there is a combination of products that all work together to enable non-intrusive profiling of embedded software, but at times the HOW TO details of profiling can be a bit of a mystery and knowing where to look to find the details may not be obvious. In fact, a recent VSP user tried to setup profiling by himself and was not successful and wasn’t really sure where to look. As a result I created the following information that I’m sure would be valuable to many other readers.

The design I used for testing the flow uses the ARM Cortex-M3 CPU running the Quantum Platform lightweight, open-source framework. The example uses a SystemC TLM Virtual Platform executing on VSP to run the Dining Philosophers Problem (DPP) Application Note.

Here are my assumptions about the environment:

• RVDS is installed and working (including licenses), I used version 4.1 on Linux
• VSP is installed and running (including licenses)

Using the ARM Profiler requires a two step process:

• Running a simulation to collect profiling data
• View the profiling results

Collecting the data requires two separate processes:

• Running a data collector program from RVDS named armprocap
• Running a virtual platform simulation with VSP which instantiates a Fast Model of an ARM CPU

Configuring the Profiler to Collect Data
Collecting the profiling data is done using a utility from RVDS called armprocap. This utility runs as a separate process from the actual simulation and communicates with the simulation to receive the profiling data and stores it into a set of data files, the profiling output. The first step to use the profiler is to configure and run armprocap.

The first challenge is that the RVDS environment setup script, RVDS41env.posh doesn’t include the LD_LIBRARY_PATH setting for armprocap and does not put the directory with armprocap in the PATH.

Things will be much easier if you add these settings to your shell environment. I added them after I sourced RVDS41env.posh so I can use ARMROOT to find the profiler.

For csh:


For bash:


Check to make sure armprocap is now in your path:


Now it’s time to start armprocap to collect the profile data. Create a script to start it, I named the script prof.sh and it contains:


There are 3 key inputs to armprocap:

• The output directory where the profiling information will be written
• The image that is loaded and running on the Fast Model
• The instance name of the Fast Model being profiled

The trick is to get the instance name correct. If this is not correct, you will get an error during the simulation.

One way to find out the instance name is to use the ARM modeldebugger. With VSP this can be started using the –ARMFM modeldebugger option. When modeldebugger appears use File -> Connect to Model. When the first dialog appears select the running simulation, and then examine the next dialog to see the instance name of the Fast Model to profile.



When the armprocap script is run it does a few things:

• Confirms the image file (it reads the image file later when the simulator connects)
• Generates an output script
• Waits for a simulation to connect

The generated script is the argument passed in the –create_connection_script option. This script has some environment variables in it that should be set before the simulation is started. For this example the generated file name is script.sh and the contents are:


The output from armprocap looks like this:


Running the Simulation
Running the simulation is the same as usual for any virtual platform run with VSP, except for two extra steps required to make the ARM Profiler data collection occur.

• Set the environment variable loads the Fast Model Model Trace Interface (MTI) plug-in that does the actual profiling
• Set the environment variables in the script generated by armprocap

The first step is easy as it automatically set by the RVDS environment setup, RVDS41env.posh.

The name of the variable is FM_TRACE_PLUGINS and should be set to $ARMROOT/RVDS/ProfilerPlugIn/2.1/3/plugins/Linux_GCC-3.4/FMProfilerPlugin.so

The second step is a bit trickier depending on your shell. If you use bash you can just source the armprocap output script and run simulation. For this example, the simulation is run using a script called RUNME_QP so I do:


If you use csh it’s a little trickier. One way is to add the simulation command at the bottom of script.sh and run it. I added a line to script.sh so it looks like:


If I didn’t do this the connection script will not inherit the FM_TRACE_PLUGINS setting which is a common difficulty. It would be useful to have an option to generate a csh compatible script from armprocap.

Then I just run the generated script from the csh prompt:


Verifying Collection is Working
If the setup is correct, the simulation will start and load the ARM Profiler plug-in. If things are correct you will get a message like this when the simulation starts up:


If the setup is not correct, you will get a message like this:


It may mean the instance name is not correct, or something else is wrong.

The armprocap script should now receive a connection from the simulation and you see messages like:


The results collected are located in the location specified by the –output option to armprocap, in this case the profout.apd/ directory.

Analyzing the Results
To analyze the results start up the ARM Workbench IDE.

If the ARM Profiler Data tab is not already visible in eclipse, use Window -> Show View -> Other and then select -> ARM Profiler -> ARM Profiler Data to make it visible.



Now the ARM Profiler Data tab is visible in the lower left hand area of eclipse.

Use the folder to add a new directory containing profile data. Don’t add the profout.apd/ directory, just the directory containing profout.apd, this is one directory above where the actual profiling data is.



If this works correctly you will see an entry in the ARM Profiler Data tab and you can start exploring the ARM Profiler data!!



Below is my screen showing the data from QP run on the M3. There are many things to investigate in the profiler output, but the tricky part of collecting the data is done. Using the ARM Workbench IDE is the easy part to explore and understand. I found it’s the collection process that causes most of the confusion.



To learn more about the Cadence Virtual System Platform with ARM Fast Models, see our recent webinar on “Debugging Linux-based systems on Multi-core SoCs”.

Jason Andrews is an Architect at Cadence Design Systems, where he is responsible for embedded software and hardware/software co-verification products and methodology. He is the author of the book "Co-Verification of Hardware and Software for ARM SoC Design" and lives in Minneapolis with wife Deborah and six wonderful children.

ARM welcomes its wealth of Partners in the ARM Connected Community (CC) to submit guest blogs to be published on our multiple community blogs. If interested in participating please submit email inquiries to Tell.Us@arm.com.

The ARM Connected Community (CC) is an extensive ecosystem covering all aspects of ARM processor-based design, from chip implementation through to system and device design. The CC provides a platform for collaborative innovation, with multiple types of forums for members to work with one another, and with customers, to solve industry challenges, all with the purpose of enabling designers to focus on differentiating features and an accelerated time-to-market for ARM powered solutions.