Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
Arm Community blogs
Arm Community blogs
Tools, Software and IDEs blog Collecting Trace from Fixed Virtual Platforms in DS-5
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded and Microcontrollers blog

  • Internet of Things (IoT) blog

  • Laptops and Desktops blog

  • Mobile, Graphics, and Gaming blog

  • Operating Systems blog

  • Servers and Cloud Computing blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tags
  • ds-5
  • Trace
  • simulation_model
  • fvp
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

Collecting Trace from Fixed Virtual Platforms in DS-5

Joe Alderson
Joe Alderson
November 28, 2014
3 minute read time.

Chinese Version 中文版: 使用DS-5从FVP中收集Trace数据

One of the new features for ARM DS-5 Development Studio in v5.20 is instruction trace for our Fixed Virtual Platform (FVP) simulation models. This enables you to capture a trace of program execution in the models that are included by default in DS-5: an ARMv7 FVP (in Professional Edition and Ultimate Edition) and ARMv8 FVP (in Ultimate Edition). If you want to try it out, you can download DS-5 Ultimate Edition and generate a 30-day eval license.

What is trace and why is it useful?

Trace is the continuous collection of information which represents the execution of software on a system. In real hardware, it is non-invasive, meaning it doesn't slow a processor down. The raw trace data is highly compressed and must be decompressed to be useful. In the case of DS-5, it helps us to see the proportion of time spent in a function, along with the machine instructions which were executed at any point in the trace capture. ARM's debug and trace infrastructure is called CoreSight (which is not modeled directly in our Fast Models and FVPs).

It is used at every stage of a design process, from modelling the system through to in-field failure analysis. Trace is particularly useful for bare-metal or Linux kernel debugging.

Since ARM Fast Models and FVPs are instruction accurate, collecting instruction trace is a natural extension to the debug functionality that DS-5 already provides for models, making the experience as close as possible to writing software for a real device. It's important to remember that Fast Models and FVPs are not cycle accurate, so the actual time it takes to execute a function won't correlate with the time it would take on the real silicon (though the proportion of time spent in that function would remain fairly consistent). Now that debug configurations have been added for the three previously mentioned FVPs, it’s easy to use it in practice. Currently, there is no support for adding trace to other models in DS-5 or for collection of data trace (where address and register values are also recorded from load and store instructions). Edit - if you have your own Fast Model based platform and would like to see trace supported on it in DS-5, then please contact ARM.

Making use of model trace

You will notice in the DS-5 Debug Configurations panel that model trace is only available for bare-metal and Linux kernel debug connections. Trace isn't the right solution for debugging Linux applications, as the extra level of complexity that an OS adds would mean sifting through an unmanageable amount of trace data.

Model-Trace-Debug-Configuration.png

The best way to test out model trace is to import an example. There are bare-metal examples for everything from simple Hello World programs to more complex RTOS programs. In the example below, I've imported the "traffic lights" program which runs on the Keil RTX RTOS.

All of our FVP bare-metal examples have been reconfigured to collect model trace, but you can also use your own images. Once trace is configured, it behaves exactly like trace on real hardware, using the same trace view in DS-5.

Our trace is being collected into a circular buffer. This is fairly common in ARM SoCs, which use an Embedded Trace Buffer (ETB) to collect a record of software execution, which is constantly overwritten and refreshed (or alternatively, just filled once).

Trace will start automatically whenever you run through a debug session, unless you set trace start and stop points manually. This can be useful for just tracing the function that you’re interested in. In the screenshot below, you can see the trace collected on start-up of the RTX Traffic Lights example (which was set to debug from main):

Model-Trace-Initial-Collection.png

It’s important to note that DS-5 doesn't automatically overwrite the contents of the trace view each time you collect more trace. If you've set trace start and stop points, clearing the trace view before running will show only the trace between these two points. In this example, I've started collecting trace when the traffic light timer is between the defined start and end times that the user sets in the program.

Model-Trace-Start-Point.png

How does model trace work?

Model trace isn't a direct model of CoreSight. Instead, it collects model events (instructions executed and exceptions) directly. DS-5 then interprets this and displays it in the same trace view used for CoreSight trace. Model trace will slow down the execution of the model on your host machine, unlike a real life system, where the CoreSight infrastructure reports trace non-invasively.

Anonymous
Tools, Software and IDEs blog
  • GCC 15: Continuously Improving

    Tamar Christina
    Tamar Christina
    GCC 15 brings major Arm optimizations: enhanced vectorization, FP8 support, Neoverse tuning, and 3–5% performance gains on SPEC CPU 2017.
    • June 26, 2025
  • GitHub and Arm are transforming development on Windows for developers

    Pareena Verma
    Pareena Verma
    Develop, test, and deploy natively on Windows on Arm with GitHub-hosted Arm runners—faster CI/CD, AI tooling, and full dev stack, no emulation needed.
    • May 20, 2025
  • What is new in LLVM 20?

    Volodymyr Turanskyy
    Volodymyr Turanskyy
    Discover what's new in LLVM 20, including Armv9.6-A support, SVE2.1 features, and key performance and code generation improvements.
    • April 29, 2025