By Jim Trudeau

It’s widely accepted that multicore system on chip (SoC) will be the industry solution to meet performance requirements within an acceptable power budget. Unfortunately, you have in hand millions of lines of field-proven code, all written for a single core. How are you going to safely migrate that to an entirely new paradigm, without spending a fortune?

Let’s put that aside for a minute, but just a minute. You are not alone. You shouldn’t find it strange, but we have the same problem. We know that a truly effective solution in the modern market needs significant software. We, Freescale, develop a lot of software. Take cellular network infrastructure for example. We are a key player with both our multicore QorIQ family, and our multicore StarCore digital signal processors (DSPs). We provide our customers with reference software as well as hardware. We are a key player in Long Term Evolution (LTE), and have LTE Layer 2 software. We needed to move that software to our own multicore platforms.

Common multicore and multithreading programming issues

Anyone migrating software to multicore architectures is justifiably concerned with a particular class of bugs related to parallel processing. These are in principle the same kinds of errors you can easily encounter in multi-threaded software: data dependencies (slow behavior because one portion of a program is waiting for another to finish); race conditions (a function uses a resource before the resource is ready); or even deadlock (where two different portions of a program wind up waiting on each other, resulting in the lock up of the CPU).

As a general rule, all of these problems arise because of resource conflicts: two parts of a program try to use the same resource (memory, data, peripheral) and collide in some way. Software that contains these problems is “resource incorrect.” Finding these problems is extremely difficult because the program must be running. Even then the unique circumstances that cause the conflict can be difficult to recreate or predict. When you put resource incorrect software on a multicore platform, the chances of problems occurring are even higher than with multi-threaded applications. This is because the cores execute independently so that genuine parallel processing occurs and not just rapid thread switching.

Multicore programming software helps solve the problem
So, bottom line, we at Freescale face the same problems you do. To address this challenge, we engaged with CriticalBlue Ltd – a multicore software analysis tool vendor based in Edinburgh, UK. Using our LTE Layer 2 software as a test case, we applied CriticalBlue’s Prism, a multicore software analysis tool, to quickly locate sub-optimal code running on the MPC8572 processor.

The analysis allowed us to improve the code performance by almost 40 percent. In real terms, this meant we were able to cram in more signal channels and make our embedded solution more competitive. In addition to verification and performance optimizations, Prism provides a ‘What If’ analysis feature that allowed us to analyze how sequential code can be parallelized to run on multiple cores. Find out more by watching our video “Making Multicore Easy”.

So, enough about us, let’s get back to you. We were sufficiently impressed with Prism that we established an alliance between CriticalBlue and Freescale. This was so cool we had to make sure you had access to it as well. We plan to enhance Prism for Freescale’s QorIQ PowerArchitecture platform, StarCore DSP platform, as well as the Cobra ColdFire and Mamba architectures. Freescale expects to add new features through 2011. The collaborative development program will deliver highly productive embedded tools engineered to help you identify and quickly quantify the benefits of parallelization better than ever before. If you are developing software for, or migrating software to, a multicore System-on-Chip, you need to know about CriticalBlue’s Prism tool.

How does Prism accomplish this? The basic approach is that it displays a timeline that shows how an embedded software program and embedded resource is used over time. If different parts of a program rely on the same resource, you can see when and where the threads interact and find the source of the software error. If there are deadlocks, race conditions, or data dependencies, you know where to look in your code to resolve them. Here’s a simple example.

The first figure below is the “before” timeline, a screenshot from the Prism software, with some annotations. The timeline shows you sequential performance, perhaps based on a legacy single thread of execution. There is a series of concurrent processes that access a single resource. Each waits for the previous thread to complete. This is highly inefficient. In fact, these threads refer to a common resource, but only one modifies it. I added a note to indicate the one place where the shared resource changes. In fact these threads can work in parallel once the resource is initialized properly. Each can get what it needs and work simultaneously on multiple cores.

Understanding the nature of the data flow, the developer modifies the access method, resulting in a more efficient use of the processes.

You can try out Prism, free for 30 days
This brief blog article isn’t going to do the tool justice; this is just the tip of what Prism can do. You can get a free 30 day evaluation copy. Give it a shot.

To pull back up out of the weeds a little bit, this tool is all about visibility into how your code really works. Rob Oshana talked about the importance of visibility in his blog article on the Top 3 Keys to Multicore Software Development. These themes have a way of reappearing because they are fundamental. The simple truth is, without a good tool like this you are blind to what is happening in the multicore environment and you will never find the pot of gold at the end of the rainbow.