There are some key lessons to keep in mind about developing
products for the embedded market using multicore processing and
virtualisation. Here are 10 of them. By Mark Hermeling, Senior
Product Manager for Multicore and Virtualisation,
Wind River
See also:
Key virtualisation differences for embedded and enterprise
markets
1. Think about your partitioning options.
There are several different choices for partitioning a multicore
system. Symmetric multiprocessing (SMP) is one operating system
controlling multiple cores, but this has some scheduling overhead
and complexities.
Asymmetric multiprocessing (AMP) can be better suited to embedded
applications because it uses a separate operating system on each
core, which can allow the system developer to combine real-time and
open source operating systems in the same design. It also allows
different operating systems to run on different types of cores such
as those optimized for graphics or networking.
virtualisation provides the opportunity to abstract the
operating system layer from the processor. virtualisation is
typically achieved by introducing a layer (the virtual machine
monitor or hypervisor) directly on top of the processor. This layer
then creates virtual machines in which operating systems can be
executed.
The hypervisor can be used to time share a single core between
multiple operating systems (running in virtual machines). It can
also partition a four-core chip into two two-way SMP partitions.
Lastly, it can be used to supervise an AMP system (or sAMP, for
supervised AMP); the supervisor provides boot, life cycle (pause,
restart) and reliability options and shortens development time
compared to a traditional AMP system.
virtualisation provides the capability to partition and provides
security and reliability at the same time.
2. Think about your operating system
choices.
Multicore and virtualisation provide the opportunity to combine
different operating systems in partitions into a single
product.
For example, you can use a real-time operating system (RTOS) for
those time-critical tasks that need (sub-) microsecond latencies
and use a general purpose operating system such as Linux for situations where open
source solutions are available and where time is less important. Or
use an RTOS together with a graphical user interface (GUI),
strongly separated so you can update the GUI functionality
frequently without impacting the operating (and certification) of
the RTOS.
Choosing an operating system also enables a legacy OS with
legacy applications in one partition combined with a new OS in
another partition to add more new functionality to an existing
product, for example.
3. Consider consolidation.
Multicore provides the opportunity to consolidate existing
multiprocessor designs in a single-processor multicore design.
Especially in industries such as medical and industrial markets,
the practice was to separate different levels of security or
certification on different processors. Multicore and virtualisation
provides the opportunity to combine these multiprocessor systems
onto different cores of a single chip, where the virtualisation
layer maintains the separation and ensures that the system is
certifiable.
Reducing the number of processors in a system, of course, lowers
the cost of the bill of materials, and it lowers the power
consumption at the same time, often delivering more performance as
well.
4. Think about the future.
This is a great opportunity to look at the architecture of your
system and prepare for the future. You may be looking at a single
core with virtualisation to add new functionality to an existing
product; or maybe you are looking towards a dual core. Fact is,
processors will only get more cores in the coming years. Preparing
your architecture now to be flexible and ready for the future may
give you a leg up on your competition.
5. Consider parallelism.
Multiple cores provide true parallelism; different operations
will be executing at the exact same time, modifying variables and
buffers in your memory. An existing application that works
perfectly on a single core may show race conditions when running on
a multicore.
Depending on your application, there are multiple approaches to
take advantage of multiple cores. It is possible to execute
multiple instances of your application either in SMP, AMP or sAMP
configurations. The question here is whether your application can
benefit from multiple instances.
There can be significant performance advantages in rewriting the
code to take advantage of the multiple cores. This is especially
valuable with applications that have multiple separate streams of
activity where each stream can be allocated to a separate
processor, all running independently. In a single processor
environment, the code would not be parallelized like this, but
rewriting the code can give a significant increase in speed or a
reduction in power consumption for the same performance.
6. Keep resources in mind.
There are still bottlenecks in a virtualized system, and these
are usually the memory, caches and I/O. In developing a virtualized
system, it is necessary to pay attention to the way system memory
is accessed by the different cores. This can be automatically
handled by the hypervisor, but for more resource-constricted
applications and for debugging, clear resource mapping helps the
development process. Similarly the I/O can be a bottleneck that can
slow down performance.
This can be overcome by either increasing the I/O resources in
the system or ensuring incoming data is mapped efficiently onto the
multiple cores. For some systems this can be as simple as
allocating a particular core to a set of I/Os; but for other
systems it may be more complicated. This can also impact the choice
of multicore software architecture with different ways of
allocating operating systems to the cores.
7. Don't forget security.
One of the key advantages of virtualisation is the ability to
make a system more secure. By running key applications such as
access control or resource management in one virtual machine with
tight security, other applications can be added to the system
without compromising the security. This is increasingly important
with industrial and embedded systems having more and more network
links that could otherwise leave the system open to attack.
8. Don't forget startup.
Starting a virtualized system with multiple cores is not just a
matter of pressing the On switch on a board. The software has to be
aware that it is a multicore system and bring up one core in a
single-core mode to run the initial tests on memory and I/O;
otherwise there is chaos with multiple cores testing memories and
peripherals in what could be a random fashion. Once the initial
hardware tests have been performed, it is simple to bring up the
additional cores and ensure that the system operates consistently
and effectively. This is especially important on a system reset or
a power failure because a board may power up differently in a debug
session.
Again, a hypervisor provides this functionality out of the box.
A concept related to startup is field upgrade. Many systems receive
updates in the field and need to restart with a new update in as
little time as possible. virtualisation provides nice capabilities
because it is straightforward to run an additional OS for a hot
spare that can take the load while the original OS reboots. This
hot spare can share the same core as the OS that bears the load, or
it can run on a separate core.
9. Don't forget tools.
With embedded systems growing in size, the challenge is often
not just debugging, it is finding what to debug. Analysis tools
provide the system overview (event traces, memory usage, code
coverage and much more) to locate areas where the execution is
faulty, such that a debugger can be used to investigate the actual
code.
Debugging a multicore system is a bit more involved than
debugging a single-core system. Think about stopping an application
on one core. The other cores in the system are still making
progress; therefore, any communication buffers between the
applications on different cores will quickly fill up and overflow.
Also, trying to determine global system state over all cores is
difficult without being able to stop all cores at once. On-chip
debugging through JTAG interfaces allows for the
capability to stop all cores on a chip (nearly) at once and can at
the same time be very helpful during system startup (see No.
8).
10. Explore and measure.
Multicore systems are a whole new approach for the embedded
designer and can provide significant performance benefits and cost
savings. But these are highly application dependent; talking to
some experts will help to focus in on the exact needs of the
project.
Finding the best multicore configuration (SMP, AMP, sAMP or
virtualized) is not straightforward; it requires careful
investigation. Even then it is not possible to accurately predict
the performance of a given application on a given configuration
with a high degree of confidence.
Establishing the configuration and executing benchmarks is
really the only way to ensure proper performance. Benchmarks,
however, are very generic; your application may stress the hardware
in different fashion than the benchmark. The most accurate
benchmark is one that is derived from your application, a
test-suite that measures the performance of the application on the
configuration and reports the numbers that are relevant to you.
virtualisation again helps you establish the configuration.
By Mark Hermeling, Senior Product Manager for Multicore and
Virtualisation, Wind River