This blog has been written in conjunction with Elsense Limited, an engineering consulting company with 20+ years of experience in the automotive industry. Having written powertrain software for vehicles such as the Bugatti Veyron and McLaren sports cars, they have seen a number of changes in the way that reliable code is created.
An automobile today can contain ~100m lines of code in the software controlling its various systems, from engine management to atmospheric control, and this number is only getting larger. The increase in complexity of systems has led to widespread use of model-based control development tools, generating safety standard conforming, portable source code. Such a tool should be integrated seamlessly into a normal development flow.
But just getting functional code is not enough. The demand on resources is such that optimization of routines is paramount, whilst also working within the constraints that safety critical code may enforce.
In this article, we will show how relatively simple optimization techniques resulted in over 2x the performance of a real application (gear-shift control). This was achieved by making intelligent use of features of both the ASCET and Arm Compiler tools, as the result of the collaboration of ETAS and Arm.
ETAS, a subsidiary of Robert Bosch GmbH, provide ASCET DEVELOPER, a model-based software development (built on Eclipse IDE) and auto code generation tool for industrial control applications. This code conforms to appropriate coding standards, such as MISRA C, ensuring the code is safe, secure, and easily maintainable.
ASCET allows an engineer to program the control software in graphical diagrams or text. It is a very intuitive tool, with a close link between the schematic diagrams and the generated C code.
The canvas containing the block diagrams have a palette associated with them, which contain the operators that can be used on the canvas. The block diagrams and state machines are continuously translated into ESDL (Embedded Systems Description Language), allowing ASCET to validate the diagram before a build. ESDL itself is similar to the C language, allowing powerful static analysis, and code generation from ESDL to C in seconds, not minutes (or hours).
The Arm Compiler is a reliable, modern, C/C++ compiler, optimized for the Arm architecture. It retains source compatibility with open-source compilers for ease of use, and enables simple migration of existing code bases. The value is further enhanced by the availability of a Functional Safety qualified edition, for use in projects up to the highest SIL levels. The Arm Compiler is provided as a component of Arm Development Studio and Keil MDK. Development Studio provides an Eclipse-based IDE, with full project management functionality.
The control algorithm was set up entirely within the ASCET environment.
Source code was generated directly into a pre-configured Development Studio project folder, which included some platform specific initialization code, and a based scatter loading file. It is useful to note here that CMSIS software packs provide such code for 8000+ devices. This allowed for an easy iterative flow as the algorithm was developed, debugged, and optimized.
After building, the code was loaded to the target, and found to execute successfully. A worst case real-time performance of 23µs was observed.
Having set the baseline of performance, we looked at where general improvements could be made.
It was noted that the code included Value Range Limitation, to saturate inputs within defined bounds. On many Arm processors, there are a family of saturating operations, that can perform the task efficiently. The solution when writing code is to use intrinsic functions as defined by the Arm C Language Extensions (ACLE). For ASCET-generated code, this can be achieved by mapping to intrinsic functions via #define.
#include <arm_acle.h> #define ADDLIM_S16S16_S16(a,b) __QADD16(a, b)
ASCET is architected to pass data across various classes using data interface signals called messages. These translate to global variables in the generated code. To prevent an inconsistent state during execution because of pre-emption from another thread, a local copy is made inside the method automatically. However this might impact the performance when a lot of global data is passed into the function for read and write. Grouping these messages into a single structure allows for easy passing of just a pointer to that structure between modules. Within the supplied Arm C library, optimized implementations of memcpy are automatically called by the compiler to match the size and alignment of these structures.
The user can also control code and data layout within the scatter-file. Used in conjunction with ACLE extensions such as __attribute((section”name”))) related variables from multiple source files, such as calibration parameters, can be grouped together. You can also ensure that the most important routines are located into the fastest storage available, likely Tightly Coupled Memories (TCM). ASCET can be configured to generate the desired section name for code and data in a very non-invasive and flexible way.
The results of these simple translations can result in significant performance improvement. As the below illustrates, the application tuned using these basic techniques resulted in a worst case performance of 11µs, approximately 2.2x faster than the original.
We asked Elsense for their feedback on the usage of these tools:
We have seen that minor changes to our normal layout of our ASCET models can play to the strengths of the Arm Compiler. For reasons of portability, we have generally steered away from the use of intrinsics in our code, but when the tool can automatically insert intrinsic functions that are preferred by a processor family with such ease, and when the intrinsic functions are as powerful as they are, then it is difficult not to be convinced of the benefits. We recently saw a post from a competitor company showing four laptops, each with different tools on them, which intended to show the complexity of the systems that they were creating. For us, though, it simply said ‘our process is far too complex, and our tools do not integrate with each other’. Creating high safety integrity systems for ISO26262 or IEC61508 does not require a complex process, it requires a clean process with good traceability from end to end. Surely, therefore, if it is possible to contain as much of the process as possible in one application, and if that application leads to a clean workflow, then that should be our aim? For us, the combination of the Eclipse-based Arm Development Studio IDE and the Arm Compiler, freely available Eclipse version management plug-ins, good debugging support from multiple vendors, and model based graphical coding with ASCET gives us the ability to have the clean process that we are aiming for.
We have seen that minor changes to our normal layout of our ASCET models can play to the strengths of the Arm Compiler. For reasons of portability, we have generally steered away from the use of intrinsics in our code, but when the tool can automatically insert intrinsic functions that are preferred by a processor family with such ease, and when the intrinsic functions are as powerful as they are, then it is difficult not to be convinced of the benefits.
We recently saw a post from a competitor company showing four laptops, each with different tools on them, which intended to show the complexity of the systems that they were creating. For us, though, it simply said ‘our process is far too complex, and our tools do not integrate with each other’.
Creating high safety integrity systems for ISO26262 or IEC61508 does not require a complex process, it requires a clean process with good traceability from end to end. Surely, therefore, if it is possible to contain as much of the process as possible in one application, and if that application leads to a clean workflow, then that should be our aim?
For us, the combination of the Eclipse-based Arm Development Studio IDE and the Arm Compiler, freely available Eclipse version management plug-ins, good debugging support from multiple vendors, and model based graphical coding with ASCET gives us the ability to have the clean process that we are aiming for.
To demonstrate how effectively and easily this can be used, we have created this worked example on GitHub and developer guide. The example is for the NXP S32K144EVB evaluation board, a low-cost automotive evaluation board, powered by an Arm Cortex-M4 processor.
If you are new to these tools, a free 30-day Arm Development Studio evaluation is available. The evaluation gives access to the latest version of Arm Compiler, and the other components of the suite. Similarly a fully featured evaluation of ASCET-DEVELOPER is available from the ETAS website.
A webinar demonstrating the above in more will be available from January 2021. To register, or watch back on-demand, use the link below.
[CTAToken URL = "https://www.brighttalk.com/webcast/17792/460339?utm_source=Arm+Ltd&utm_medium=brighttalk&utm_campaign=460339" target="_blank" text="Join the Webinar" class ="green"]