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 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:
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.
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:
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.
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