Multicore software developers gain code coverage tool

May 04, 2015

Bernard Cole-May 04, 2015

Code coverage, the required DO-178C testing method for most software in avionics and military designs, is now being considered as a requirement in other areas, such as automotive, where functional safety is paramount. DO-178C is also being used in applications where security needs to be water-tight.

In simplest terms, the aim of code coverage testing is to ensure that all of program’s source code can be traced back to a set of requirements. In the case of mil/aero, that is the DO-178C standard in avionics and ISO 26262 for automotive. In both cases this requires a degree of attention to detail not normally required in most software designs.

In short, it is a real pain. But necessary.

Among other things, the code coverage tests include determining whether or not each subroutine in a program has been called, and if each statement and each branch from it has been executed. In addition, both the automotive and mil/aero specifications require that every point of entry and exit in the program has been invoked at least once, and every decision in the program has been tested on all possible outcomes at least once.

Automotive ISO26262 code coverage requirementsClick here for larger image
Automotive ISO26262 code coverage requirements
Click here for larger image

If the state of the art in embedded applications was still single-core MCU designs, the use of code coverage would trouble only the developers of the applications that require it. But the problem is that, historically, coverage metrics have all been based on the assumption of examining sequential source-code executing on a single processor.

With the current generation of code coverage tools, the only way developers can do the necessary analysis of software in a multicore environment is through the use of some proprietary methodology or by doing it on a core by core basis. Alternatively, traditional static or dynamic tools can be used, or, as a last resort, laborious manual methods. Whatever the method, it is expensive and time consuming and does not allow the developer to take advantage of the many power-saving, task-sharing capabilities of a multicore design.

Building on research funded as a part of the European Union's ParMERASA Project, Rapita Systems has developed multicore friendly code coverage capability which it has incorporated into Version 3.3 of its Verification Suite (RVS). The new version allows developers to identify which cores execute specific code with sufficient detail to meet the strictest DO-178C or ISO 26262 requirements.

If the company is right, such a tool capability would be of enormous benefit to multicore developers no matter what the environment. On a multicore design, just knowing that the code runs is not enough. Knowing where the code runs and how it is behaving is not only piece of mind for the multicore developer. The visibility into multicore software opens up all sorts of avenues for performance and power optimizations.

Core affinity and synchronization
The problems with doing safety- and security-critical code coverage in a multicore environment relate to core affinity and the bewildering array of synchronization mechanisms that must be tracked.

To deal with core affinity — correlating sections of code to the cores on which they execute — most developers assume a fixed mapping in which specific applications are permanently assigned to specific cores. But when multiple applications run on multiple cores, that is hard to do. In addition it is necessary to protect access to shared resources but at the same time make sure they do not step on one another’s toes.

Rapita tool incorporates features that allow complete code coverage.
Rapita tool incorporates features that allow complete code coverage.

It is also necessary to deal with the synchronization, common to all multicore apps, so that there is consistency of data across an architecture where each core accesses a local memory or cache. What makes code coverage difficult is that synchronization may be necessary at any time from many different locations in the code, and in any number of different ways.

Continue reading the next page on Embedded's sister site, EE Times: "Effective code coverage comes to multicore software."

Join over 2,000 technical professionals and embedded systems hardware, software, and firmware developers at ESC Boston May 6-7, 2015, and learn about the latest techniques and tips for reducing time, cost, and complexity in the development process.

Passes for the ESC Boston 2015 Technical Conference are available at the conference's official site, with discounted advance pricing until May 1, 2015. Make sure to follow updates about ESC Boston's other talks, programs, and announcements via the Destination ESC blog on and social media accounts Twitter, Facebook, LinkedIn, and Google+.

The Embedded Systems Conference, EE Times, and are owned by UBM Canon.

Loading comments...