Skip navigation


1 2 3 Previous Next

Software Development Tools

177 posts

It’s DS-5 release time, and this release packs a bunch of new functionality and improvements. Note this release, DS-5 v5.26, is the last release that has support for 32-bit host platforms.


IDE, Compiler, Fixed Virtual Platforms

Most of the components in DS-5 Development Studio are updated in this release. Eclipse is upgraded to version 4.5.2 (Mars), ARM Compiler 6 is upgraded to version 6.6 (release notes), ARM Compiler 5 is upgraded to version 5.06u4 (release notes), and Fixed Virtual Platforms are upgraded to version 10.2.


DS-5 Debugger

As with every release, DS-5 includes support for the latest processors announced by ARM. This release implements support for the ARM Cortex-M23, ARM Cortex-M33, and ARM Cortex-R52 processors including new example code to demonstrate the architectural features (feature video, introduction to ARM Cortex-M23 and Cortex-M33). ARM Compiler 6 support and Fixed Virtual Platforms for the new processors are also included in the product.


The new example wizard helps to explore and import examples (feature video). As of this release, DS-5 eases DSTREAM firmware installations to notify and automatically update older versions of the firmware (feature video).


To simplify the debug of the pre-MMU boot stages of the Linux kernel this version introduces a new command option to set the physical memory address of the Linux kernel (feature video). The debugger events view has been extended to support custom (user written) ITM data decoders and also displays DWT data packets (feature video). Watchpoint functionality has been extended with the ability to take conditional action when it is triggered (feature video). Developers now have more control over the format of the data displayed in the memory view, and it enables fixed display widths regardless of the window size (feature video).


The Scripts view now has the ability to import and convert CMM scripts (feature video).


The native standalone debug hardware utilities have been removed in this version, and they are now replaced by equivalent functionality within the Eclipse IDE (See Platform Configuration, Debug Hardware Configure IP).



Streamline performance analyzer now has support for the Mali-G71 GPU. Data generated by the perf command-line tools can now be imported, so that it can be used to generate charts to visualize performance data in the Streamline Timeline views. There are also additional improvements for systems running with many cores and also a new ultra-high resolution mode at 1µS.


This is the first release of Streamline with support for bare-metal systems running a minimal operating system (feature video). The feature requires applications to be instrumented with a profiling library which gathers and stores data onto the target memory system.


Mali Graphics Debugger

Linux support for Vulkan is added to Mali Graphics Debugger, and the Android Vulkan loader is updated to a newer version. This enables profiling Vulkan on even more devices to optimize content.


The Frame capture feature is significantly enhanced to capture depth and stencil attachments (feature video). It also includes support for transient attachments and multiple subpasses. Together these features provide a powerful solution for Vulkan related analysis and debug.


The first professional edition feature, which requires a DS-5 license,  has been completed and it takes the form of full trace replay. This gives DS-5 the ability to replay trace back on the same target for further analysis.


Host OS support

This release, DS-5 v5.26, is the last release that has support for 32-bit Windows host platforms. The next release, DS-5 v5.27, will not contain support for any 32-bit host platforms.


Download DS-5 v5.26


We have some exciting updates to share related to ARM Cycle Models.


New SystemC Models


ARM has released new SystemC Cycle Models on ARM IP Exchange. This marks the first time cycle accurate models are available from ARM for SystemC simulation. Along with the new models, a number of example systems are available on ARM System Exchange. Users now have the choice of using SoC Designer or SystemC for creating virtual prototypes. This also provides EDA partners who provide simulation and virtual prototyping based on SystemC another option for ARM models.


Cycle Models are compiled directly from ARM RTL and retain complete functional and cycle accuracy. This enables users to confidently make architecture decisions, optimize performance or develop bare metal software. Cycle Models are used for IP evaluation, system architecture, performance optimization, and software development.


Improving Model Availability and Choice


One of the key Cycle Model improvements made in 2016 has been model availability. Recently, I summarized the difference of attending ARM Techcon before and after joining ARM. During 2016, more models were made available to ARM partners much sooner in the design process. This makes it possible to use models and virtual prototyping tools during the IP evaluation phase of a project to understand behavior and performance of IP. Cycle Models aim to meet the requirements needed to analyze the combination of hardware and software.



Requirements for pre-silicon performance analysis and benchmarking
Cycle accurate simulation
Access to models of candidate IP
Ability to generate multiple configurations of candidate IP
Tools to quickly assemble multiple systems for exploration
Ability to run and debug software
Analysis tools to understand performance and make decisions based on results



SystemC Models


SystemC models are the second major improvement for 2016. ARM is committed to providing models to both silicon and systems partners for virtual prototyping. Cycle Models are important to ARM partners for a number of reasons. They provide an easier way to work with ARM IP and are flexible enough to work in a variety of simulation environments.

The following SystemC Cycle Models are now available on ARM IP Exchange:


ARM IP Exchange also has a new Request Model menu item to request models which are not currently available.


SoC Designer 9.0.0

SoC Designer version 9.0.0 is now available on ARM IP Exchange and supports the latest ARM Fast Models, version 10.2.

Cycle Model Studio 9.0.0

Cycle Model Studio version 9.0.0 is also available on ARM IP Exchange.


With this release the Cycle Model Compiler includes partial SystemVerilog Interfaces support. For details about supported and unsupported SystemVerilog Interface related features please refer to Cycle Model Compiler User Manual.


Licensing Changes

One very important note: Carbon licenses will not work with this release and new ARM licenses are required.


As part of the transition of Cycle Model products from Carbon to ARM, all Cycle Model products have transitioned from using the carbond license daemon to the armlmd license daemon. This change applies to Cycle Model Studio, SoC Designer, and all Cycle Models for SoC Designer and SystemC. This transition aligns Cycle Model products with other ARM software development tools, simplifying the license generation process and management of licenses.


For more information:


Branding Changes

All products have updated branding as part of the transition from Carbon to ARM. No functional changes are expected, but products look different from previous versions. The installation file names and some documentation file names have also changed.




Improved model availability for Cycle Models means more partners can take advantage of models earlier in the design cycle. The addition of SystemC models has given users more choice for simulation and virtual prototyping products.

Christopher Seidl

MDK v5.22 released

Posted by Christopher Seidl 21-Nov-2016

Last week, we have released MDK v5.22. This release includes support for ARM Cortex-M33 and ARM Cortex-M23 devices based on the ARMv8-M architecture. MDK v5.22 adds ARM Compiler 6.6 which is required for the new processors. For using Cortex-M33 and Cortex-M23 a MDK-Professional Edition is required.


ARM CMSIS 5.0.0 now supports the ARMv8-M architecture including TrustZone® for ARMv8-M hardware security extensions and the ARM Cortex-M23 and ARM Cortex-M33 processors. We have added the CMSIS-RTOS V2 API which extends the CMSIS-RTOS v1 API by supporting the ARMv8-M architecture, dynamic object creation, provisions for multi-core systems, and binary compatible interface across ABI compliant compilers.


The new Keil MDK Middleware 7.3.0 added debug library variants for Networking, USB, and File System with Event Recorder support. Event Recorder shows dynamic execution status and event information of software components. Our next webinar will demonstrate how this helps to analyze the operation of third-party software components: Dynamic software analysis with MDK event recorder


As always, you can download MDK here.



Coming up in November and December are a series of webinars not to miss. Sign up today to reserve your place.


Using TrustZone on Cortex-M23 and Cortex-M33

November, 17 | 9:00am GMT or 1:00pm CDT


ARM recently announced the first two processors using the ARMv8-M architecture, ARM Cortex-M23 and Cortex-M33. ARM TrustZone for ARMv8-M adds security features to these cores that allow applications and services to operate securely while safeguarding the secure resources from being misused, corrupted or inspected by intruders. The webinar will explain how to program secure and non-secure domains on a processor with TrustZone.



Manage software complexity on heterogeneous systems (*In Mandarin Chinese*)

November, 18 | 4:00pm CST


Heterogeneous devices, such as the NXP i.MX series, utilize the best of both worlds on a single device: a Cortex-A processor running Linux for complex application software such as data analytics, graphics, or complex networking is combined with a smaller Cortex-M processor for real-time behavior with minimum power consumption. While heterogeneous computing has many benefits, software development becomes challenging when managing Linux application development, classic embedded microcontroller software and inter-process communication. This webinar will show how the new DS-MDK simplifies software development on heterogeneous devices by enabling Cortex-M/A bare-metal debug and Linux application debug in a single powerful tool.



Dynamic software analysis with MDK event recorder

December, 1 | 9:00am GMT or 1:00pm CDT


Today, flexible and easy-to-use software components are essential for microcontroller applications. These software components are frequently a "black box" to the application programmer, which makes the analysis of potential issues challenging. This webinar will introduce the Keil MDK Event Recorder and explain how it enables programmers understand and analyze the operation of software components. The webinar will also discuss how to use the provided infrastructure to add specific MDK debugger views to user applications and third party middleware.



What’s new in CMSIS-RTOS2 and Keil RTX5

December, 8 | 9:00am GMT or 1:00pm CDT


The new CMSIS-RTOS API v2 addresses new requirements such as dynamic object creation, support for ARMv8-M, message passing in multi-core systems, and full support of C++ run-time environments. This webinar will compare the CMSIS-RTOS API versions and will show how to migrate source code and utilize the new features in Keil RTX5, as it is the first real-time operating system that implements the new API as its native RTOS interface for ARM Cortex-M processor-based devices.


The race is on. The path to secure end-to-end IoT is now paved with the announcement of the ARM® Cortex®-M23  and Cortex-M33  processors. They are the first deeply embedded processors to include ARM TrustZone® for ARMv8-M techcnology, which means that hardened protection against security threats will soon be available in even the smallest of microcontrollers. All of a sudden, market forecasts such as IDC’s 30 billion connected IoT endpoints in 2020 seem closer than ever. So if you are planning to be at the forefront of IoT, there is more good news: ARM also provides complete ARMv8-M software development cockpits to help accelerate your software project. Being developed and optimized alongside each processor architecture, ARM software development tools and models enable scalable software development to be kicked off months ahead of silicon availability. Here are some ARM development tools you should know about.


1. Virtual Platforms: Secure IoT starts now


One of the highlights of the new ARMv8-M architecture is the introduction of secure and non-secure software partitioning model. This new capability, enabled by TrustZone technology, allows software applications to be designed so as to restrict access to sensitive firmware, peripherals and I/O to only the trusted portion of the whole program. This logical separation reduces attack surface and can dramatically simplify security testing. TrustZone for ARMv8-M security extensions will start to appear in microcontrollers sometime in 2017, but in the fast-paced IoT market a few months separate pioneers and late entrants. For this reason, both ARM Keil® MDK  and ARM DS-5 Development Studio include ARMv8-M-capable Fixed Virtual Platforms (FVP). FVPs are programmer’s view models that enable agile software development and testing on PC platforms. From within MDK or DS-5 integrated development environments (IDE), developers can go through the bulk of the development cycle using virtual platforms until hardware prototypes become available. Many ARM partners have relied on virtual platforms built on ARM Fast Models to be ready with their software stacks before chips arrive on the market.



figure 1: TrustZone for ARMv8-M software compartmentalization



2. MDK-ARM: Efficient microcontroller software development


The Keil MDK-ARM toolkit includes all components required to write, build, optimize and debug embedded applications on ARMv8-M based microcontrollers. From highly tuned C/C++ code generation for Cortex-M23/Cortex-M33 processors with ARM Compiler 6 to TrustZone-aware debug connections and compartmentalized project manager, every aspect of the tool suite has been extended to help software engineers easily navigate between secure and non-secure states. It can be used for early software development today on FPGA and virtual platforms, including the Cortex-M Prototyping System MPS2+ board and FVP (included). Moreover, the concept of Software Packs provides users with a variety of software building blocks from ARM and third party vendors to further speed up product deployment. These include, for instance, device support packs and royalty-free middleware components for security, encryption and networking. Everything to help you focus on your own value-add IoT application, not on standard software stacks.



figure 2: Partitioned software project and ARMv8-M SAU setup


3. DS-5: Complex SoCs, simplified


For those bringing up or developing software for complex multi-core SoCs that include ARMv8-M processors, like IoT gateways for example, the DS-5 toolkit offers high-performance tools to debug, trace and analyze in detail any class of Cortex processors. As the flagship toolkit from ARM for SoC developers, DS-5 covers the entire development lifecycle, from SoC validation/testing on RTL simulators all the way to optimization of Android applications for big.LITTLE systems. With the DS-5 Debugger, for instance, it is possible to simultaneously connect to one or more peripheral microcontrollers and the main application processor to analyze and debug issues arising from inter-processor communication. The tool suite fully supports all the latest architectures and processors from ARM, including the recently announced Cortex-R52 processor.


DS-5 PCE.png

figure 3: Auto-detection of a heterogenous Cortex-A9 and Cortex-M3 SoC with all associated ARM CoreSight™ components


Try for yourself


Like many of our lead silicon partners, you can start developing software for ARMv8-M architecture, including TrustZone technology, using our development tools available now (links below). Towards the end of November, MDK-ARM version 5.22 and DS-5 version 5.26 are arriving bringing public support for the recently announced Cortex-M23, Cortex-M33 and Cortex-R52 processors along with exciting new features.


Evaluate ARM Keil MDK


Evaluate ARM DS-5 Development Studio


Evaluate ARM Fast Models


Get notified when new ARM tools are released

SOMNIUM are pleased to announce that we will be exhibiting at ARM TechCon again this year!


We love coming to TechCon! It's one of our busiest shows and one of the best opportunities for us to meet our US based customers.


Just like last year, we will be launching the newest release of SOMNIUM DRT on the first day of the expo. This time, we will be launching v3.5 which is a major update to many of DRT's features and also includes support for macOS making us the only professional tools available on all 3 major operating systems! You can find out more about our presence and book an appointment to chat to us on the SOMNIUM Website.


We'll post next week with full details of DRT 3.5 so keep an eye on here, our website and our twitter feed.

business card map.png

Visit us at stand 807 for a demo of DRT, to see DRT running on macOS and to speak with our software experts.


We hope to see you there!

ARM's latest embedded newsletter is now available. In this month’s edition we talk about the new ARM Cortex-R52, ARM's most advanced safety processor, in addition to efficient pre-silicon software development and the demise of the headphone jack. There are also a series of free training webinars and events. View the newsletter »


To receive this straight to your inbox, sign up for ARM’s developer newsletters »

The ARM® Cortex®-R52 processor is the most advanced processor for functional safety and the first implementation of the ARMv8-R architecture. Along with the announcement of the Cortex-R52, ARM offers a number of development tools to help partners speed up their path to market. This is especially helpful for a new architecture which highlights software separation for safety and security. This article summarizes the available tools and explains what’s new for the Cortex-R52.


About the Cortex-R52         


The Cortex-R52 is the first ARMv8-R processor. ARMv8-R brings real-time virtualization to Cortex-R in the form of a new privilege Level, EL-2, which provides exclusive access to a second stage Memory Protection Unit (MPU). This enables bare metal hypervisors to maintain software separation for multiple operating systems and tasks.


Many partners will be interested in the differences between the Cortex-R52 and previous designs, such as the Cortex-R5 and Cortex-R7. The Cortex-R52 evolves the Cortex-R5 microarchitecture by providing fast, deterministic interrupt response and low latency at a performance level which is better than Cortex-R7 on some real-time workloads. Cortex-R52 also offers a dedicated, read-only, low-latency flash interface which conforms to the AXI4 specification.


ARM Fast Models and Cycle Models enable virtual prototyping for software partners to develop solutions for the new Cortex-R52 before silicon is available.


DS-5 Development Studio


DS-5 Development Studio is the ARM tool suite for embedded C/C++ software development on any ARM-based SoC. DS-5 features the ARM Compiler, DS-5 Debugger, and Streamline system profiler. Also included is a comprehensive and intuitive IDE, based on the popular and widely-used Eclipse platform.


The DS-5 Debugger is developed in close co-operation with ARM processor and subsystem IP. DS-5 is used inside ARM as part of the development and verification cycle and is extensively tested against models, early FPGA implementations and (as soon as it is available) silicon. The DS-5 Debugger provides early-access debug and trace support to ARM lead partners working with leading-edge IP. This enables mature, stable, validated debug and trace support for Cortex-R52 to be included in the upcoming DS-5 release, version 5.26.


ARM Compiler 6


ARM Compiler 6 is the latest compilation toolchain for the ARM architecture, and is included in the DS-5 Development Studio. ARM Compiler 6 brings together the modern LLVM compiler infrastructure and the highly optimized ARM C libraries to produce performance and power optimized embedded software for the ARM architecture.


ARM Compiler 6 is developed closely with ARM IP and provides early-access support to lead partners. As with core support in all compilers code generation, performance, and code size improve over time, with improvements driven by experience and feedback from real-world use-cases. The upcoming release of ARM Compiler 6, version 6.6, will feature full support of link time optimization and enhanced instruction scheduling support, giving an improvement of nearly 10 percent for Cortex-R52 in key benchmark scores. Combined with significant improvements in code size, ARM Compiler 6 is a comprehensive choice for the Cortex-R52.


Cortex-R52 provides a compelling opportunity for users to migrate from ARM Compiler 5 to ARM Compiler 6. The ARM Compiler migration and compatibility guide aids the evaluation process by comparing the command line options, source code differences, assembly syntax, and other topics of interest.


If existing code needs to be updated from ARM Compiler 5 to ARM Compiler 6, the first step is to get the code to successfully compile. This generally takes a combination of Makefile changes to invoke the new compiler as well as source code adaptations.


First, compiler invocation needs to be switched from armcc to armclang. Other tools like armasm and armlink are included in ARM Compiler 6 and can continue to be used.

For example, when changing from Cortex-R7 to Cortex-R52 a few compiler command line option changes will be required:


ARM Compiler 5

ARM Compiler 6




--target= armv8r-arm-none-eabi –mcpu=cortex-r52




-Os / -Oz

-Onum (default is 2)

-Onum (default is 0)


The migration guide provides further details related to specific switches, but these are the basics to get going. Some compiler switches may need to be removed because they are specific to armcc; for example,  --apcs /interwork and --no_inline are not needed with armclang and can be removed.


Fast Models


Fast Models are an accurate, flexible programmer's view models of ARM IP, allowing you to develop software such as drivers, firmware, operating systems and applications prior to silicon availability. They allow full control over the simulation, including profiling, debug and trace. Fast Models can be exported to SystemC, allowing integration into the wider SoC design process.


Fast Models typical use cases:

  • Functional software debugging
  • Software profiling and optimization
  • Software validation and continuous integration


The Fast Model for the Cortex-R52 is being released in late September as part of Fast Models 10.1.


Cycle Models


Cycle models are compiled directly from ARM RTL and retain complete functional accuracy. This enables users to confidently make architecture decisions, optimize performance or develop bare metal software. Cycle Models run in SoC Designer or any SystemC simulator, including the Accellera reference simulator and simulators from EDA partners.


Cycle Models typical use cases:

  • IP selection and configuration
  • Analysis of HW/SW interaction
  • Benchmarking and system optimization


The Cortex-R52 SystemC Cycle Model supports a number of features which help with performance analysis:

  • SystemC signal interface
  • SystemC ARM TLM interface
  • Instruction trace (tarmac)
  • PMU event trace
  • Waveform generation


The Cycle Model for the Cortex-R52 is being released in late September and will be available on ARM IP Exchange.


Frequently asked questions about getting started with Cortex-R52


Does Cortex-R52 require DS-5 Ultimate Edition?

Yes, DS-5 Ultimate Edition is required for debugging with Cortex-R52.


What are the switches for ARM Compiler 6 to select Cortex-R52?

For ARM Compiler 6.6 use the armclang switches: --target=armv8r-arm-none-eabi -mcpu=cortex-r52

For ARM Compiler 6.5 use the armclang switches: --target=armv8r-arm-none-eabi -mcpu=kite


Can DS-5 be used for software debugging with a simulation model?

Yes, before silicon is available DS-5 can be used to develop and debug software using the Cortex-R52 Fast Model. The Fast Model can be used for functional software development, checking compliance with the ARMv8-R architecture, and software optimization. DS-5 with the Fast Model makes an ideal development environment for hypervisors, schedulers, real-time operating systems, and communication stacks.


Is there a model available for verification which works in EDA simulators?

Yes, the Cortex-R52 Cycle Model can be used in any EDA simulator. It has a SystemC wrapper which can be instantiated in a Verilog or VHDL design. It provides 100% cycle accuracy.


Is there a way to run benchmarks to compare Cortex-R52 to another core such as Cortex-R5 or Cortex-R7?

Yes, the Cortex-R52 Cycle Model instruments the Performance Monitor Unit (PMU) and provides a tarmac trace to run benchmarks and evaluate performance.


The Cortex-R52 CPU model doesn’t seem to start running after reset, is the model broken?

No, the most common cause is the CPUHALTx input is asserted and stopping the core from running.


Do Cortex-R52 models allow simulation of booting from TCM?

Yes, both the Fast Model and the Cycle Model can boot from TCM. The CFGTCMBOOTx enables the ATCM from reset on the Cycle Model and the Fast Model provides the tcm.a.enable parameter to do the same thing.




A full suite of development tools is available for the Cortex-R52, which enables developers to do more, earlier with the most advanced ARM processor for functional safety and learn about the ARMv8-R architecture. Please refer to for more information on ARM Development Tools.

DS-MDK, the software development solution for heterogeneous computing, now supports additional devices from NXP and a new development board.


NXP i.MX 6SoloX processors offer an ARM Cortex-A9 core together with an ARM Cortex-M4. The corresponding SABRE development board is now fully supported by DS-MDK, using the i.MX 6 software pack. Learn how to use the SABRE board together with DS-MDK on the reference page.


Furthermore, DS-MDK now supports PHYTEC phyBOARD-i.MX7-Zeta. This single-board computer (SBC) is a two-PCB counterpart to the phyCORE-i.MX7 SOM. The SOM itself serves as the CPU core of the SBC which interfaces to a carrier board via high density connectors. This carrier board breaks out major interface signals to plug-and-play or pin-level connectors and offers a JTAG connector for debugging purposes. Learn how to connect DS-MDK to the phyBOARD-i.MX7-Zeta on the reference page.

Public Webinar

If you want to learn more about DS-MDK, register for our public webinar on September 28th.



Check out our new YouTube playlist dedicated to our debugging features. Learn more about our Live Expression viewing, MTB Trace and Fault Diagnosis tools:

Additional core support

DS-5 v5.25 Professional and Ultimate Editions support cache visibility for Cortex-A5 and Cortex-A7 cores. Ultimate Edition also supports cache and MMU visibility for Cortex-A73, and debug support for ARMv8.1-A and ARMv8.2-A cores.


Additional Fixed Virtual Platforms

DS-5 v5.25 Professional Edition includes a license for single-core Cortex-M3 and Cortex-R4 Fixed Virtual Platforms (FVP). Ultimate Edition now includes a license for a wide range of single-core, multi-core, and big.LITTLE FVPs. The virtual platforms are delivered as part of the DS-5 installation package.


Core FamilyFixed Virtual PlatformCommunityProfessionalUltimate
Cortex-MFVP_MPS2_Cortex-M0, FVP_MPS2_Cortex-M0plus, FVP_MPS2_Cortex-M4, FVP_MPS2_Cortex-M7
FVP_VE_Cortex-R5x1, FVP_VE_Cortex-R7x1, FVP_VE_Cortex-R8x1
FVP_VE_Cortex-A5x1, FVP_VE_Cortex-A7x1, FVP_VE_Cortex-A15x1, FVP_VE_Cortex-A15x4-A7x4, FVP_VE_Cortex-A17x1
Cortex-v8AFVP_Base_Cortex-A53x1, FVP_Base_Cortex-A57x1, FVP_Base_Cortex-A72x1, FVP_Base_Cortex-A73x1, FVP_Base_Cortex-A32x1, FVP_Base_Cortex-A35x1, FVP_Base_Cortex-A57x2-A53x4, FVP_Base_Cortex-A72x2-A53x4, Cortex-A73x2-A53x4, FVP_Base_AEMv8A
Foundation Platform (v8) Not license managed



Revised Host Support

DS-5 v5.25 adds support for Windows 10 64-bit and Red Hat Enterprise Linux 7 Workstation 64-bit. Support for Linux 32-bit hosts has been dropped in this release.



DS-5 Professional and Ultimate

DS-5 Community

ARM Compiler 5.06u3

ARM Compiler 6.5

Fast Models 10.0

Windows 7 SP1 Professional Edition 32-bit*
Windows 7 SP1 Professional Edition 64-bit
Windows 7 SP1 Enterprise Edition 32-bit*
Windows 7 SP1 Enterprise Edition 64-bit
Windows 8.1 64-bit
Windows Server 2012 64-bit
Windows 10 64-bit
Red Hat Enterprise Linux 6 Workstation 32-bit
Red Hat Enterprise Linux 6 Workstation 64-bit**
Red Hat Enterprise Linux 7 Workstation 64-bit
Ubuntu Desktop Edition 12.04 LTS 32-bit
Ubuntu Desktop Edition 12.04 LTS 64-bit**
Ubuntu Desktop Edition 14.04 LTS 64-bit


* Not delivered in DS-5, but exists as a standalone product

** Requires additional GCC runtime libraries


Mali Graphics Debugger

DS-5 v5.25 includes the Mali Graphics Debugger. This enables DS-5 users to trace Vulkan, OpenGL ES, EGL, and OpenCL API calls


Enhanced debugger functionality

DS-5 debugger functionality has been enhanced in a number of areas, each of which is described in a separate blog:


The ARM Embedded Logic Analyzer (ELA) brings particular challenges to a debugger. The flexibility of the ELA and the broad range of implementation choices and potential uses, all place demands on a debugger. The debugger must present a high level of functionality with high potential for flexibility and customisation. However because most of the customisation must be carried out by the user, the debugger must also present a high level of usability.


A comprehensive scripting interface is the obvious way to address the challenges presented by the ARM ELA, and enables the debugger user to customise and extend the functionality of the debugger. However scripts bring their own challenges, which escalate rapidly as script library size and script complexity grow.


ARM DS-5 debugger now includes a comprehensive script management system aimed at helping users leverage the power of scripts and handle the challenges that scripts bring. Here we look at some of the challenges brought by the ARM ELA, and discuss some of the generic challenges brought by script complexity. We’ll then investigate how the DS-5 script management system enables users to address these challenges with an ease of use not seen in any other ARM debugger.


The ARM Embedded Logic Analyser

The ARM ELA enables developers to drive the highest levels of performance and efficiency from their ARM-based design. The key functionality of the ARM ELA is to monitor (and give the developer visibility of) signals deep within an ARM-based SoC. Signal information can be processed in one of two ways:

  1. Information about signals can be captured to an on-chip buffer for later analysis
  2. The ELA contains a comprehensive state machine. Transition between states is controlled by signal changes and comparisons, and the final state produces events that can be propagated over the CoreSight cross-trigger network

The ARM ELA is able to monitor, and provide visibility of, complex interactions and event chains taking place deep within the SoC. However SoC designers have a wide range of implementation options for the ARM ELA. The ELA could for example, monitor signals inside an ARM core. Or it could monitor signals in the bus interconnects: the ARM ELA is particularly useful for analysing throughput and identifying bottlenecks. Such is the flexibility of the ELA, the range of implementation options, and the range of challenges that it might be used to address, it’s impossible to hardcode ELA support into a debugger. The device is controlled by a large number of inter-dependent registers, which need to be used in harmony with each other. The only practical way for a debugger to provide support for the ARM ELA is through a comprehensive and highly functional scripting interface. This enables SoC designers and software developers to leverage the power of the ELA for their particular needs.

Scripting support in an ARM debugger

Good scripting support is a critical part of any modern ARM debugger, and scripting is sometimes the only way to reach the level of functionality and flexibility needed by a complex ARM-based design. A highly functional scripting API is the only practical way for a debugger to address a number of challenges in modern ARM-based designs:

  • There is a trend of growing complexity and individuality in ARM-based designs. In particular there’s growth in the size and complexity of the CoreSight cross-trigger and trace systems, with new devices and a variety of trace storage options distributed across the design
  • There may be a need for custom debugger functionality with is tailored to a specific debug target, or even a specific debugging challenge
  • As designers strive to keep power consumption to a minimum and gain maximum advantage from the flexibility of the ARM architecture, power management strategies are becoming more aggressive and can present significant challenges to a debugger
  • A key strength of ARM IP is its high suitability for a mixed implementation that also contains non-ARM IP. It can be very useful to get a measure of control and visibility of ARM and non-ARM IP in the same debugger


A comprehensive scripting API enables the user to handle both complexity and individuality in an ARM-based design. A scripting API enables the creation of custom debugger functionality to address the needs of an individual design, or the needs of a particular debug session. Because the needs of a debugger can be tightly bound to an individual SoC design or to the characteristics and causes of an individual software defect, enabling the user to create custom debugger functionality can be highly valuable.


However as script number and complexity rise, usability challenges start to appear. Particular problems might be found in script configuration, and with non-trivial scripts it’s common for their functionality to depend upon command-line arguments. This solution can suffer problems in scalability: the user needs to remember which command-line options are valid for which scripts. Each option has a range of valid values and options may be inter-related. With a significant library of complex and flexible scripts, the requirements on the user can quickly grow to a point where the value of the scripts starts to degrade. These problems can be compounded when scripts are shared between team members (and other teams), meaning users have to drive value from scripts with which they are unfamiliar.


DS-5 Use-Case Scripts

The ARM DS-5 debugger recently added a new script management system, aimed at addressing some of the problems found with large libraries of complex scripts. A key innovation is the ability to embed custom visual controls in the script itself: this is an extension of the existing functionality that has been successfully used by DS-5 DTSL (Debug and Trace Services Layer) scripts for a number of years.


Because controls can be represented graphically on custom control tabs, it’s easy to see at a glance which options are available for a particular script. Command line options which can take a range of values can be implemented as drop-down selection boxes, allowing value (and spelling) discovery at a glance. Options which take numerical or string values can be represented as text edit boxes, with bounds checking also embedded in the script. Controls can appear as hierarchies, with child controls becoming enabled only when parent controls are activated.
This screen capture shows a control tab from one of the use-case scripts shipped with DS-5 v5.25 as part of the support for the ARM ELA. Command line options for the script are represented as visual controls, removing the need for the user to carry deep familiarity with the script and to remember all details of all possible options. The controls are arranged on a number of control tabs, grouping areas of related functionality (in this case, giving a fine degree of control over movements between stages of the ELA internal state machine). Users can gain familiarity with the possibilities and functionality of the script very easily – the visualisation of command line arguments as custom controls significantly reduces the learning curve faced by script users.


On the left side of the careen capture can be seen a number of configuration “profiles”. Sets of control values can be saved as named configuration profiles to be used later. Directories of DS-5 use-case scripts, and sets of named configuration profiles containing pre-built collections of control values to address various needs, can be shared between DS-5 users.



Modern ARM-based designs can present a number of challenges to a debugger user, and devices such as the ARM ELA present particular challenges because of their high levels of flexibility, functionality, and implementation options. The only practical way to address these challenges is by using a comprehensive debugger scripting API, but users are likely to encounter scalability problems as the complexity and number of scripts rises.


The ARM DS-5 “Use-Case” script management system aims to resolve these problems and enable users to leverage the full power of their scripts. By visualising script command line options as custom controls complete with value, relationship, and bounds checking, DS-5 significantly reduces the learning curve and information required when using scripts. Named configuration profiles, and the ability to share script libraries and profiles between users and teams, increase this ease of use and flexibility.


For details of other changes in DS-5 v5.25, take a look at Key Changes in DS-5 Debugger v5.25

In order to keep costs, power consumption, and size to a minimum, many embedded products based on ARM Cortex-R cores have limited on-chip memory. In particular, the size of the Tightly Coupled Memory (TCM) can be restricted. Because TCM has very low latency, significant performance gains can be realised when running code in TCM. Therefore limiting TCM size can impose performance challenges: a trade-off to be considered by the SoC design team.


One way to reduce the impact of restricted TCM is to use an overlay manager. Code is organised into a number of overlays which share the same memory area. When executing code in the same overlay, no changes are necessary and the overlay stays resident in low-latency TCM. However when a call is made to a non-resident overlay, the overlay manager needs to load the correct overlay into the TCM. This load needs to be performed as efficiently as possible, and the debugger needs to be overlay-aware and present the correct information to the user. For example, the debugger needs to step over overlay veneers: effectively making the overlay manager invisible to the debugger user. In DS-5 v5.25 we’ve added overlay support to both the ARM Compiler and the DS-5 debugger. When overlays are enabled, the compiler leaves overlay information in the symbol file. The debugger reads this information when the symbol file is loaded, and can enable overlay support automatically. As well as handling the debug implications of overlays and automatically stepping over the overlay veneers, DS-5 debugger presents overlay information through additional debugger commands or through the new Overlays view, for example:



Here we can see the address and size of a number of overlays, and we can see instantly which overlays are currently loaded. Information has been expanded for one of the overlays, so that we can see at a glance the functions contained in that overlay. The matching overlay support in the ARM Compiler and DS-5 debugger makes it easy to manage overlays and drive significant performance enhancements from efficient use of fast on-chip memory.


For details of other changes in DS-5 v5.25, take a look at Key Changes in DS-5 Debugger v5.25

In DS-5 v5.24, we added the Stack View to the debugger. This view displays stack information that used to be displayed in the Debug Control View, giving two advantages. Firstly, the Debug Control View becomes less cluttered and more focussed: giving better clarity of information and an increase in debugger usability. Secondly, stack information can take a non-trivial amount of time to retrieve from the target: because the Stack View can be closed when not needed (and it’s possible to limit the stack depth displayed), stepping speed in the DS-5 debugger can be increased. This performance increase is particularly noticeable for debug targets with slow JTAG clocks or an extensive stack back-trace.


In DS-5 v5.25 we have enhanced the Stack View to display function parameters and local variables, for example:



Variables marked with a ‘P’ are function parameters, and can also be seen in the extended function prototype information. All the other variables shown are the function’s local variables. Arrays and structures can be expanded to display member variables, by right-clicking all variables can be displayed in the Variables or Memory views.


Retrieving variable information from the target can cause a degradation in debugger stepping performance, particularly for targets with very slow JTAG clocks or a large number of function parameters and local variables. To increase debugger stepping performance when parameter and variable information is not needed, display of parameters and variables can be disabled via the Stack View menu.


For details of other changes in DS-5 v5.25, take a look at Key Changes in DS-5 Debugger v5.25

The CoreSight cross-trigger network in a SoC is created from two components: Cross Trigger Matrix (CTM) devices form the backbone of the network and transport events around the SoC; and Cross Trigger Interface (CTI) devices which capture or deliver events to or from other components distributed around the SoC. Although the CoreSight cross trigger network has a variety of potential uses, by far the most common use encountered by DS-5 users is to synchronise cores.


This cross-trigger use-case enables related to cores to enter and exit debug state together. For example, when one core hits a breakpoint and enters debug state, this change in state is picked up by the CTI coupled to that core. The CTI passes the halt event into the cross-trigger matrix, where the CTMs route the event to the CTI coupled to other cores. These CTI issue halt requests to their cores, so that all related cores halt with minimal latency. The debugger doesn’t need to get involved with halting the cores: it just sets up the cross-trigger network so that events are routed correctly. This enables the very low latency which is critical on many SoCs to avoid undesirable effects such as kernel panics.


The ARM DS-5 debugger already supports cross-trigger network configuration and management, and the DS-5 Platform Configuration Editor (PCE) creates the necessary scripting when bringing up a new target platform in the debugger. However PCE currently only supports the most common core topologies: SMP and big.LITTLE. PCE cannot currently create the necessary DTSL scripts for other topologies: for example cross-triggering Cortex-A and Cortex-R/M cores in the same SoC, or halting cores when the on-chip trace buffer fills. These use-cases need custom scripting. DS-5 users can create custom DTSL scripts to drive the DS-5 debugger functionality they need, but there’s a learning curve to be considered. Complex cross-trigger requirements could mean more complexity in DTSL scripts than the average user might be prepared to take on. So in DS-5 v5.25 we’ve revised and enhanced the DTSL functionality around cross-triggering, and added a new DTSL class to make scripting easier and less complex.


These DTSL enhances make it easier and quicker to create custom cross-triggering support in DS-5, backed by groups of custom DSTL controls. This example shows a typical use-case, synchronising the watchdog timer with the Cortex-A57 cores in the ARM Juno reference platform:

In future DS-5 releases we’ll extend the DS-5 PCE to take advantage of this additional DTSL functionality. We’ll also review all the platform configurations that ship with DS-5, to see where DS-5 can leverage these changes to deliver additional value.

Filter Blog

By date:
By tag:

More Like This