Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Multicore SoCs invade embedded arena

Posted: 20 Apr 2010 ?? ?Print Version ?Bookmark and Share

Keywords:multicore SoC? processor? OS? embedded market?

2. Relying on the priority to make sure the system is served appropriately. While priority based scheduling works for single core, it can break down on a multicore platform if it's used as a way to guarantee only the highest priority thread is executed.

Once a thread of a lower priority is scheduled on a separate core, this method of blocking two threads from accessing the block of data at the same time turns into another race condition.

One solution is to eliminate global data structure modifications by the highest priority threads in each subsystem. An accepted practice on single core is potentially a deadly race condition on multicore.

Finally, even if your SMP-capable OS can be scheduled across several cores, ensure that it is partitioned into enough threads to take advantage of all the cores. If not, a potential bottleneck will occur in the system. Can the architecture of the application be modified in such a way as to promote load balancing across multiple cores?

Employing such basic techniques can make your SMP system not only safer, but better optimized for the amount of cores you have available.

What about AMP?
AMP designs can be used on SMP hardware. In fact, this is an ideal relationship between several OS instances. Executing code simultaneously while dividing code between operating system domains is an effective way to enhance security and increase throughput.

This provides each OS with a deterministic environment with a dedicated cache from which to execute. Ideally, you would dedicate one or more cores to AMP and use an Inter-Processor Communication (IPC) mechanism to communicate between the other OSs.

If you have some non-multicore safe code in your system, you could dedicate a core to a set of threads that must remain in single-core mode and use IPC to communicate between cores. While this may not allow complete load balancing between cores, it does allow for the code to be utilizedeven if it's not ready for multicore.

The ability for the system to bind certain threads of execution to a particular core from within an SMP scheduling environment is available in a technology called Bounded Computational Domains (BCDs), which is a new part of the Nucleus RTOS product from Mentor Graphics.

BCD enables the entire system to interact as a single OS while making sure only those threads that are bound to the core are scheduled on that core. BCD technology is ideal for legacy applications that may not be ready for SMP but want tight integration with the other tasks in the system.

Most operating systems employ an IPC mechanism to communicate between OS domains. The problem with many of these IPC mechanisms is that they are proprietary, and mixing two different operating systems (like an RTOS and Linux where they have different methods of IPC) can prove quite challenging.

To address the issue of proprietary IPC mechanisms, the Multicore Association created an API-based standard called Multicore Communication API (MCAPI). When both RTOS and GPOS vendors adopt MCAPI, any code written for this API can be ported to another system with all of the IPC code untouched. The good news is MCAPI gives you the ability to migrate code as necessary in order to make the system timing requirements.

Multicore SoCs are quickly becoming the norm in 2010. OS are adapting quickly to hardware capable SMP and AMP designs. Finally, we are seeing the OS as a true enabler of multicore designs.

- Stephen Olsen
Software Architect, Embedded System Division
Mentor Graphics Corp.

?First Page?Previous Page 1???2???3

Article Comments - Multicore SoCs invade embedded arena
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top