When I read about multicore and multiprocessor design or get into a conversation with an embedded developer involved in such work, lines from Alfred Lord Tennyson’s poem about the ill-fated “Charge of the Light Brigade” often run through my mind:

“Cannon to right of them,
  Cannon to left of them,
  Cannon in front of them
  Volley'd and thunder'd;
  Flash'd all their sabres bare,
  Flash'd as they turn'd in air,
  Sabring the gunners there..” 

Similarly, embedded systems developers face multicore and multiprocessor challenges on all sides: in network routers and switches and wireless base stations, in portable media devices, in servers and desktop computers as well as mobile phones.

But, unfortunately, their hardware and software tools are as outdated and useless as the sabers, one-shot pistols and horses of the ill-fated 600 were against cannon, repeating rifles and mechanized equipment they rode against.

The reasons for the mismatch are many.

In some cases it may be reluctance by developers to shift from tools and languages for sequential program development that have served them well for decades. They are naturally reluctant to give them up, just as cavalry officers in the Light Brigade were probably reluctant to give up the sabers and horses that served them well in previous battles.

In other cases, it may be the tools are available behind the lines but there is no one to train the men and women on the front line. Or they may still be in development, or may be stuck behind the lines in a traffic jam, not available on the front line in time. Or like generals in the Pentagon arguing over a weapons system while soldiers die on the battlefield, maybe there is too much talk and not enough being done to provide developers with the tools they need.

Stuck in traffic at the debug interface port
Debug tools and on-chip hardware debug interfaces are a case in point. The existing debug interfaces were designed to allow developers to access, monitor and interrogate single-core designs. They are just barely enough to allow development on multicore designs, as long as a developer stays well within the limits of well-understood symmetric multiprocessor designs and as long as the number of cores is within reason.

There are solutions to the problem. Maybe too many. But few seem to be ready for prime time. The last time I looked there were at least seven industry groups – hopefully not working at cross-purposes - addressing aspects of the debug problem including:

1) The OCP-IP Debug Working Group, which is developing a standardized set of debug interfaces for system debug, observation and cross-triggering of IP and software solutions. (They have just released a series of recent reports on their activities.)
2) Nexus (IEEE 5001) Forum, which is focused on high performance trace related interfaces based on the IEEE 5001 (Nexus) standard;
3) MIPI Alliance Test and Debug working group which is addressing a range of debug interface efforts;
4) IJTAG (P1687), which is a working group looking at JTAG extensions;
5) Multicore Association (MCA) which is looking at integrated set of Debug and Communication APIs for Multicore architectures;
6) AJTAG (P1149.7) which is looking at 2 wire JTAG architectures; and
7) SPIRIT Consortium has a Debug working group looking at debug register description within the SPIRIT IP-XACT frameworks. 

Admittedly the problem is a complex one, but an industry consensus should have emerged in the two or three years some of these groups have been at work. But while we wait, the only available strategy open is “every man for himself,” meaning chip vendors and systems designers must come up with their own proprietary (and probably incompatible) solutions.

Despite the usefulness of proprietary solutions as a near-term tactic. strategically this solution is a loser. The history of the computer industry tells us that in the long run, coming up with a common approach allows everyone to gain and the technology to advance faster. That is just basic game theory and common sense.

Sequential or parallel, that is the question
On the programming language side of things, individual developers may be reluctant to give up sequential, procedural languages such as C, C++, and Java because they have become used to them over the last three to four decades. But something has got to change. What we’ve got isn’t working.

Much of the ground work for this transition has already been laid, if not on the current battlefront, certainly behind the lines and on other fronts. For several years - much before mainstream desktops, portable and mobile developers faced the problem – some network processor suppliers and developers made the transition to more appropriate parallel programming environments.

For example, functional languages have been used for multicore-based network processing because – in addition to being a much more comfortable parallel programming environment - they are good at implementing mathematical algorithms: extracting data from a table, performing a calculation and then executing some sort of control function based on that calculation.

What makes functional languages attractive in both the highly parallelized NPU and multicore environments is that they strictly define an operation in terms of the function to be performed, not as a set of procedures to be followed with a single object.

Network processor companies such as Agere, recently acquired by LSI Logic, and Sanburst, acquired by Broadcom, have led the way. Agere combines its proprietary high-level classification language, FPL (Functional Programming Language) with simple C-based traffic management and modification scripts for accelerating software development on its NPUs. Ditto for Sanburst, which opted for a declarative, functional programming extension to Haskell. Called parallel Haskell (pH), in this approach the parallelism is implicit and the norm. All programs are parallel constructs, with explicit sequential programming extensions added where necessary.

However, for now, a shift away from the well-understood C/C++/Java sequential programming model seems too much of a stretch for most companies. As a result, two other more incremental and evolutionary approaches have emerged.

In the first approach are APIs such as OpenMP (which is favored, for now, by Intel). Here, the idea is to write programs in sequential form in a stylized way with specific explicit annotations that make it easy for a compiler to generate parallel code.

In the second, sequential languages are extended with explicit constructs designed to initiate parallel activities and coordinate their interaction. Into this category fall a number of programming methodologies already familiar to embedded system developers, including POSIX threads (pthreads), Java, and MPI.

Given the difficulties and the confusing array of alternatives, Microsoft researchers recently seem to have concluded there is no clear road ahead and that it will be ten years before a viable approach is found.

I don’t think the embedded system design industry can wait that long. If a solution is not found soon, embedded developers will suffer the fate similar to - but hopefully not as violent as - that of the doomed, soon to be decimated 600 cavalrymen in the Charge of the Light Brigade who, after they were:

“Shatter'd and sunder'd. Then they rode back, but not the six hundred.”

What do you think? Call me at 602-28807257 or email me at bccole@acm.org with your comments.

iApplianceWeb.com editor in chief Bernard Cole is also site editor at embedded.com and a partner in the Techrite Associates LLC editorial consulting firm, which serves high technology firms.

For more information about topics, issues and technologies mentioned in this story go to the flashing icon in the upper left corner on this page or go to the iAppliance Web Views page and call up the associatively-linked Java/XML-based Web map of the iApplianceWeb site.

Enter the appropriate key word, product or company name to list instantly every news and product story, product review and product database entry relating to the topic since the beginning of the 2002.