Multicore is the wave of the future, with
more cores in our designs as time goes on.
Some push the limits, while others creep
up to a half-dozen very large cores. And
then there’s the problem of programming these things.
Communication lies at the heart of the matter. Memory is
the key in a symmetrical multiprocessing (SMP) or non-uniform
memory access (NUMA) environment. In other architectures,
communication may be packet switches, FIFOs, or a
host of other link technologies employed in different chips.
Hardware programmers have placed a number of standard
protocols such as sockets, streams, Linx, and TCP/IP on top
of this connection (see “Freeing Communications” at www.electronicdesign.com, ED Online 17317). If you really want to
get complicated, check out the Open Management Group’s
(OMG’s) CORBA or data distribution service (DDS).
NEW SPEC ON THE BLOCK
Now, the Multicore Association has weighed in with its
lightweight version designed for multicore environments—the
Multicore Communications API (MCAPI) Specification (see
“Multicore Communications API,”). The V1.063 incarnation
of the standard is available online.
MCAPI tries to minimize the footprint, overhead, and
programming design requirements. Although the spec is about
120 pages, most of that material comes from the details, not
from a large or complex application programming interface
(API). It maps well to most hardware too.
Also, it can be implemented in most real-time operating
systems (RTOSs) without modifying the operating system,
though better, more efficient performance will likely come
from closer integration. The bigger question will be whether
this becomes a standard option with popular operating systems.
Will it make it into the Linux kernel? Who knows?
The basic concepts include a node, a port, and a message.
The architecture uses a zero copy, pass-by-reference option that
matches most shared memory architecture functionality, but this
is an implementation detail. This is the main advantage of this
approach, and it’s not lost on RTOS designers of message-based
operating systems like QNX and Enea’s OSE, which uses Linx.
Nodes map nicely to cores or virtual cores. Ports send or
receive messages, but the MCAPI implementation differs
from most of the higher-level standards since links between
ports are unidirectional and map one-to-one. Communication
is assumed to be reliable, which is typical when dealing with
memory or on-chip switching or buses.
Error handling hasn’t been overlooked, though. Likewise,
the standard addresses functions such as link management
and backpressure support. On the other hand, details like data
encoding and big versus little endian are left to the programmer.
This is not a big issue for embedded programmers where
the components are normally known and consistent, but it can
be a challenge in a more open environment.
IN THE REAL WORLD
Higher-level protocols can be built on MCAPI. Yet the spec
isn’t designed to be an over-reaching solution. Instead, it specifically
targets multiple cores. Still, communication between
cores is likely to span the backplane in many instances.
Skipping across a network isn’t impossible, though the
assumption of fast and reliable communications often requires
movement to higher-level protocols to handle communication
reliability. There is future work being done in the organization
and more specifications in the wings, but they will likely
remain as lean as MCAPI.
Open-source versions of MCAPI are available for Linux.
Commercial implementations are available from companies
like PolyCore Software, whose Poly-Messenger follows the
MCAPI standard. Even Freescale has a version for its QorIQbased
multicore processor line. Companies like PolyCore Software
take the task a bit further by providing configuration tools
often needed for new chips.
MCAPI will be a good move for most embedded developers
where C/C++ is king and performance and simplicity are
watchwords. So, are things are getting better or worse?
ENEA
www.enea.com
FREESCALE
www.freescale.com
THE MULTICORE ASSOCIATION
www.multicore-association.org
POLYCORE SOFTWARE
www.polycoresoftware.com
QNX
www.qnx.com