RTC Magazine

In the popular Shakespeare comedy, The Taming of the Shrew, Lucentio travels to Padua to attend school at the local university. Upon his arrival he meets the beautiful Bianca and, smitten with love, his priorities change instantly from attending to his studies to winning her hand. Unfortunately for Lucentio there are a few roadblocks: Bianca already has many suitors, and her father, the wealthy old Baptista, has made it known that no one may court Bianca until her older sister, the ill-tempered Katharina (aka the Shrew), is married first.

The comedy continues with Lucentio and two other suitors disguising themselves with the intent to trick Baptista and win Bianca’s heart. The “Katharina problem” is solved when Petruchio arrives in Padua from Verona to find himself a rich wife. In the end, three couples are married, but only one with “predictable results” that you can “bank on.”

So what does Shakespeare have in common with multicore and real-time? I know it’s a stretch–had Lucentio not been able to “change his priorities instantly” he might have lost the race for Bianca’s hand; he had to make decisions in “real-time” and respond to actions by the other suitors in a “timely fashion.” The appearance of Petruchio and others on the scene allowed for additional plots to be played out “in parallel” with the plot to win Bianca’s heart. Without this “parallel processing” the comedy would have lost its pace and become nothing but a forgotten story.

The same is true for embedded systems. Without the ability to respond to inputs, control priorities and perform tasks in parallel, our protagonist, the embedded system designer, could not meet his goals of a system with “predictable results.” Each suitor in the comedy played different roles but all of them contributed to the final outcome. Modern embedded systems also have many roles to play: a GUI and enterprise network interacts with the outside world, a real-time control loop works with machine-level I/O in a time deterministic manner, and analysis modules requiring numeric-intensive operations are needed to implement complex system functions. Taking on all of these roles in an inexpensive small form factor platform is the challenge faced by today’s embedded system developer.

Asymmetric Multiprocessing Meets the Challenge

Just like the multiple plots that operate in parallel in Shakespeare’s comedy, embedded developers can use the multiple cores available in today’s low-cost processors to implement parallel tasks. But rather than relying on a single operating system (OS) to arbitrarily assign those tasks to the processor cores based on a symmetric multiprocessing (SMP) scheduling algorithm internal to the OS, you can assign the cores to specific tasks using multiple operating systems and an asymmetric multiprocessing (AMP) solution.

Partitioning resources in a biased manner is a common design practice. For example, a DSP board or embedded processor card might be used for real-time data collection, processing and control; while a separate user-interface computer interacts with the outside world. In this case, expensive communication links are needed to coordinate the disparate real-time hardware with the high-level supervisory control computer.

Rather than allocating time-critical software to an expensive stand-alone processor or DSP board, you can run an RTOS on a dedicated processor core and use it to provide the same functions as an entire CPU board. The remaining core(s) can host your general-purpose operating system (GPOS), such as Windows. This lets you optimize the cost of your hardware and your software engineering resources. Using shared memory to communicate between the RTOS and the GPOS (each OS resides on distinct cores of the same machine) provides for very low-cost and efficient transactions without the expense and complexity of extra hardware (Figure1).

Such a system is an asymmetric multiprocessing system because the processor cores are not being load-shared across a single OS but are dedicated to specific tasks, in this case simultaneously running multiple operating systems. You have ultimate control over the priorities and applications that run on each RTOS core, unlike the situation with a GPOS.