How We See Embedded Processing

One thing I find in this constantly innovating semiconn industry is that it is always harder to describe and specify what you need than it is to build it. I guess that’s why I so often see the specification stage of development taking so long. Robert’s article is addressing one of the big-issues that I’ve also enjoyed walking around the industry– that of trying to articulate the new language of multicore processing. In some ways I’ve had it easier in that I needed to only make a distinction between the multiple processor designs that our customers were already building and the new platforms that could be created with ARM MPCore technology-based multicore processors such as the ARM11 MPCore and the new Cortex-A9 MPCore processors.

To this end, I have being running a personal crusade to distinguish the architectures that Robert introduces – and over-simplify by calling them all “multiprocessing designs” thus, using this all-encompassing term to mean a design containing more than one processor. Whereas a “multicore” processor design is one where the design includes a group of processors that together form a platform on which a single domain of software will be hosted.

In my many discussions within the industry’s design groups building multiprocessing and multicore designs, the software model has always been the key characteristic required to understand how to describe and utilize these new “MP” architectures. Robert introduced how the type of instruction set architecture has been used to distinguish a single processor design. It is true also that those of a multiple processor nature require the software view of a processor in order to name the multiple processor design.

One of the distinctions somewhat hidden within the article is what I see as the top level difference between multiprocessing vs. multicore – whether the multiple processor design will know what software it will need to run when it is designed or not. If the processor design is being built to accomplish a specific, fixed and well defined task, then it will almost certainly be a design containing multiple independent domains of software in which specific processors are selected as the best target for the specific software needs – and in my parlance this is simply know as a multiprocessing design. Robert introduces various subdivisions of this, missing possibly the somewhat popular pipeline or stream structure of processors. Such pipeline multiprocessing architectures are common in, for example, GPU and networking devices where a sequence of processing steps are required on some data that will ‘flow’ through the device.

A multicore design by distinction of the software will often be designed without the benefit of knowing exactly what software will be run on the design once it has been built. Historically in the single core era, this was the domain championed by the general purpose processor. The adoption of this has built up an ecosystem now capable of supporting the delivery of over 4 billion ARM CPU cores in just the last 12 months. The challenge of this success is that there is a lot of existing software expecting such a general purpose design, and a lot of programmers that know how to write software for such processors. So as the MHz race clearly comes to an end and multicore becomes the hardware engineers’ saviour, what is to be done for this software community?

One approach being taken is to offer larger multiprocessing designs – the big challenge being how to share the software between the processors when the designer doesn’t know what software is to be run. The result is a design with a single CPU for the general purpose functions, and a number of accelerator processors being made available to offload what may be expensive functions, such as video.

The approach taken by ARM, in common with the personal computer market, is to provide a multicore processor that can support the same programming paradigm that is utilized on the current general purpose single core processors. This software paradigm is delivered by the operating system, and for many years has provided what is technically known as pre-emptive multitasking. This allows the programmer to run multiple applications and tasks on a single processor as if it had an unlimited number of processors – as if one processor is available to run each defined task. The OS does this by dividing the CPU time allocated between each defined task. So when such an OS moves to a multicore processor, such as the Cortex-A9, all that really needs to happen is that the OS must now time-slice the available tasks, not over just a single CPU, but the number of CPU defined by the multicore processor. For the application writer, there is no change. They may want to write code that can utilize more performance than just one of the CPUs, but it’s not necessary to rewrite the legacy software to run on the new multicore capable OS. This has already been seen when the desktop moved to multicore. For embedded devices, the richness of functionality has the decided advantage that there are already multiple tasks defined that can utilize such a multicore processor – you’ll start seeing these for example in mobile phones starting next year.

So, is multiprocessing new? No, - multiple processors have been used to share the workload in embedded devices for many years. So is multicore processing new? Also no - enterprise and servers have shared their multitasking workloads across multiple processors for decades. So why is there all the hype about this? Maybe because more designs, either out of the necessity for low power, or simply because there is a lot of hype being created by those considering to use these designs – and as I said at the start, the biggest issue is not the building of the design, but learning the language to describe what is available and what is required. More discussion on this is welcomed - please!

- John Goodacre, Director, Program Management, ARM Processor Division

 
If you have not seen the next guest post yet, check out what David Stewart at CriticalBlue has to say about