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