Background

It is becoming harder and harder to source single-core devices and there is a growing need for increased processing capability with a smaller physical footprint in all applications. Devices with multiple cores can perform many processes at once, meaning it is difficult to establish (with sufficient evidence) whether or not these processes can be relied upon for safety-related purposes. Parallel processes need to access the same shared resources, including memory, cache and external interfaces, so they may contend for the same resources. Resource contention is a source of interference which can prevent or disrupt completion of the processes, meaning it is difficult to know with a defined uncertainty the maximum time each process will take to complete (Worst Case Execution Time, WCET) or whether the data stored in shared memory has been altered by other processes.

Multi- and manycore devices come with a range of architectures and varying levels of design data. Definitions of multicore and manycore differ across sources, but will be precisely defined in the context of the MCWG outputs to provide clarity in the outputs. An initial description is provided below, which will be improved as the WG activities progress.

Multicore devices have a relatively simple architecture of a number of cores sharing memory, such as:

Multicore devices can be considered in a similar context to multiple single core processors; containing up to tens of cores.

The precise boundary between multicore and manycore can be debated, but is described in terms of the implementation where traditional multi-processor techniques are no longer efficient due to resource contention in supplying data to the individual cores.

Manycore devices have a more complex architecture as they are specifically designed for a high degree of parallel processing. Manycore devices contain numerous (hundreds or thousands) processor cores and, unlike multicore devices, will only run efficiently when the software has been designed for implementation on multiple cores.

An example of simplified Manycore architecture is given below:

For some devices, a Network-on-Chip (NoC) is split into data transfer and control messages (i.e. two or more NoCs) connecting all cores. Memory allocation may be controlled by a memory controller on the chip for all cores (sometimes called ‘tiles’) or for clusters, where one core of the cluster controls input and output to the remainder of the cluster cores. In the simple architecture above, some memory allocation is controlled for all cores and implemented via connections from each core’s Cache to the NoC.

The range of architectures and implementations has caused many challenges for Design for Safety in that different device selections may lead to very different safety challenges. As some processing in safety-related systems requires processing vast quantities of data, there is now a need for a much wider range of processor architectures to be supported for systems where safety is a design requirement.

The position paper, CAST-32A, provided a good starting point for guidance on the assurance of multi- and manycore devices, but there is a need to provide device-agnostic guidance on how to assure multi- and manycore safety-related implementations. This needs to provide guidance on how much device-specific data is really essential to obtain sufficient safety assurance of the implementation. In addition, there is a need to provide guidance to designers of multi- and manycore devices to influence future device development.

This working group has been established to explore the future ways of assuring the safety of multi- and manycore implementations.

Co-chairs

Louise Harney

Lee Jacques

Please contact Lee in the first instance as Louise will soon be on leave. Both co-chairs will receive emails to MCWG@scsc.uk.

Membership

If you would like to become a member of the MCWG, please contact us at MCWG@scsc.uk.

Membership is open to all, and we welcome members from all areas of industry, academia, regulatory and everything in between.

Meetings

A number of different meetings of the working group are held:

• Plenary meetings at least every 6 months
• Sub-group leads meetings every month
• Sub-group meetings with varying frequencies between weekly and monthly.

A seminar on the topic of safety for multi/manycore will be held on 11 November 2021, which will give us an opportunity to report back on the MCWG progress. You can find more details here: https://scsc.uk/e812.