Multicores, software tools, languages and the Charge of the Light Brigade -

Multicores, software tools, languages and the Charge of the Light Brigade


When I read about multicore and multiprocessor design or get into aconversation with an embedded developer involved in such work, linesfrom Alfred Lord Tennyson's poem about the ill-fated “Charge of theLight 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 andmultiprocessor challenges on all sides: in network routers and switchesand wireless base stations, in portable media devices, in servers anddesktop computers as well as mobile phones.

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

The reasons for the mismatch are many.

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

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

Stuck in traffic at the debuginterface port
Debug tools and on-chip hardware debug interfaces are a case in point.The existing debug interfaces were designed to allow developers toaccess, monitor and interrogate single-core designs. They are justbarely enough to allow development on multicore designs, as long as adeveloper stays well within the limits of well-understood symmetricmultiprocessor designs and as long as the number of cores is withinreason.

There are solutions to the problem. Maybe too many. But few seem tobe ready for prime time. The last time I looked there were at leastseven 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 systemdebug, observation and cross-triggering of IP and software solutions. (They have just released a seriesof recent reports on their activities.)
2) Nexus (IEEE 5001) Forum, which is focused on high performance trace related interfaces based onthe IEEE 5001 (Nexus) standard;
3) MIPIAlliance Test and Debug working group which is addressing arange of debug interface efforts;
4) IJTAG (P1687), which is aworking group looking at JTAG extensions;
5) Multicore Association(MCA) which is looking at integrated set of Debug andCommunication APIs for Multicore architectures;
6)AJTAG (P1149.7) which is looking at 2 wire JTAGarchitectures; and
7) SPIRIT Consortium has a Debug working group looking at debug register description withinthe SPIRIT IP-XACT frameworks.

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

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

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

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

For example, functionallanguages have been used for multicore-based networkprocessing because ” in addition to being a much more comfortableparallel programming environment – they are good at implementingmathematical algorithms: extracting data from a table, performing acalculation and then executing some sort of control function based onthat calculation.

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

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

However, for now, a shift away from the well-understood C/C++/Javasequential programming model seems too much of a stretch for mostcompanies. As a result, two other more incremental and evolutionaryapproaches have emerged.

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

In the second, sequential languages are extended with explicitconstructs designed to initiate parallel activities and coordinatetheir interaction. Into this category fall a number of programmingmethodologies already familiar to embedded system developers, includingPOSIX threads (pthreads), Java, and MPI.

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

I don't think the embedded system design industry can wait thatlong. If a solution is not found soon, embedded developers will sufferthe fate similar to – but hopefully not as violent as – that of thedoomed, soon to be decimated 600 cavalrymen in the Charge of the LightBrigade 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 with your comments. site editor BernardCole, who writes a regular column, The Netcentric View, is also a partner in the Techrite Associates LLC editorial consulting firm, which serveshigh technology firms.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.