Some things to watch for when developing products for the embedded market using multicore processing and virtualization
BY MARK HERMELING
Wind River Systems
Alameda, CA
http://www.windriver.com
There are many concepts to keep in mind when developing products for the embedded market using multicore processing and virtualization. Here is what we think are the 10 most important.
1. Think about your partitioning options
There are several 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.
Virtualization provides the opportunity to abstract the operating system layer from the processor. Virtualization is typically achieved by introducing a layer (the virtual machine monitor or hypervisor) directly on top of the processor, which then creates virtual machines in which operating systems can be executed (see Fig. 1 ).
Fig. 1. Different multicore configurations.
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 asymmetric multiprocessing system (or sAMP, for supervised AMP); the supervisor provides boot, lifecycle (pause, restart), and reliability options and shortens development time compared to a traditional AMP system. Virtualization provides the capability to partition and provides security and reliability at the same time.
2. Think about your operating system choices
Multicore and virtualization provide the opportunity to combine different operating systems in partitions into a single product. For example, you can use an RTOS for time-critical tasks and use a general-purpose operating system such as Linux for situations 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 and applications in one partition combined with a new OS in another 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 design. Especially in industries such as medical and industrial, the practice was to separate different levels of security or certification on different processors. Multicore and virtualization provides the opportunity to combine these multiprocessor systems onto different cores of a single chip, where the virtualization layer maintains the separation and ensures that the system is certifiable (see Fig. 2 ).
Fig. 2. Migrating from multiprocessor to multicore.
4. Think about the future
It might be good time to look at the architecture of your system and prepare for the future. If you are using a single-core device, consider that processors will only get more cores in the coming years. Preparing your architecture now to be flexible and ready for multi-core 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 could not be parallelized. Rewriting the code may 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.
The I/O can be a bottleneck that can be overcome by either increasing the I/O resources or ensuring incoming data are 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 others 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 virtualization 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.
8. Don’t forget startup
Starting a virtualized system with multiple cores is not just a matter of pressing the On switch. 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 chaos ensues, with multiple cores testing memories and peripherals in what could be a random fashion. 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 an update in as little time as possible. Virtualization 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 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 and 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. Virtualization again helps you establish the configuration.
Example
Hypervisors for embedded systems have been introduced in recent years. One such offering is the Wind River Hypervisor, which has recently been updated to version 1.1 and works with single-core and multicore processors. New features include support for the latest Intel microarchitectures, such as Nehalem-based processors (with support for Freescale's QorIQ following later this year), integration with the latest versions of VxWorks and Wind River Linux while also supporting other OSes for greater flexibility, additional capabilities for intervirtual machine communication, and optimization for use in conjunction with On-Chip Debugging 3.2. ■
Advertisement
Learn more about Wind River
