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 “
“Cannon to right of them,
Cannon to left of them,
Cannon in front of them
Volley'd and thunder'd;
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:
3) MIPIAlliance Test and Debug working group which is addressing arange of debug interface efforts;
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.
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,
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
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, including
Given the difficulties and the confusing array of alternatives,
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 firstname.lastname@example.org with your comments.
Embedded.com site editor BernardCole, who writes a regular column,