Frequently Asked Questions about MCAPI™

Q: Are there any specific hardware and/or platform requirements to use/learn the MCAPI?
A: The MCAPI specification does not have any hardware or platform restrictions. Specific MCAPI third party implementations can support one or more operating systems and may have hardware dependencies. Regardless, a tool vendor should offer services to assist in porting the software to another operating system or hardware architecture.

Q: Can MCAPI be implemented on an ASIC or FPGA in gate form?
A: MCAPI can be implemented in a system if the programmer is able to identify units in the system to serve as MCAPI nodes and there exists an underlying mechanism for transferring data to/from the nodes system-wide. A node can be a processor, task, core, instance of an OS, etc. The MCAPI topology can be hard-coded at compile-time, or the programmer can implement a topology discovery service at the application layer used by the nodes in the system to learn the topology at boot up.

Q: Can MCAPI be used for communication between a smartphone’s application processor and a modem processor; do such implementations exist?
A: Yes, MCAPI can be used for this purpose. Contact the specific vendor for details (i.e. Freescale, Qualcomm, Samsung, TI).

Q: What is the maximum number of cores supported by MCAPI?
A: The MCAPI specification does not limit the number of cores present in the system, it can be used on a single or many cores. Any implementation specific limitations should be documented by the individual vendor.

Q: Can MCAPI be used with multiple microcontrollers?
A: Yes, MCAPI is applicable to multiple cores on a chip and multiple processors on a board.

Q: How many vendors currently provide MCAPI implementations?
A: As of June 2011, MCAPI is available from ENEA, Mentor Graphics, and PolyCore Software. More are on the horizon.

Q: Is there an open implementation of MCAPI being developed for Linux?
A: OpenMCAPI, created by Mentor Graphics, is an open source implementation of the MCAPI standard. Most of this code is provided under a BSD license, except for the Linux kernel drivers, which are dual GPL/BSD licensed.

Q: Do you have a porting guide for MCAPI?
A: A porting guide for MCAPI on SRIO is under development. MCAPI vendors may provide porting guide for their implementations.

Q: What about MCAPI performance?
A: While the MCAPI specification is designed to offer a low latency solution, the actual performance metrics will depend on the individual solution; these metrics should be provided by the vendor. There are currently no official benchmarks for MCAPI, although we have done performance evaluation comparing to sockets and it is considerably faster. Performance depends on the underlying transport driver.

COMPARISONS

Q: How is MCAPI more appropriate than CORBA for SMP/AMP?
A: MCAPI should be used by an application to send and receive data across nodes in a system. A programmer could use MCAPI to implement a remote service registration database as offered by CORBA as follows - a well-known endpoint would host the registration server, and nodes would register services/issue service requests through the registration server using connectionless MCAPI messages. All service registration and retrieval requests would be handled at the application layer of the registration server. MCAPI would not be providing any sort of services except the sending/receiving of messages to/from the registration server and corresponding nodes.

Q: Wouldn't MCAPI be better as a protocol specification? Then we would know, for example, that the DSP OS and CPU/APE OS talk the same language?
A: MCAPI specification implements a universal API, much like a sockets API, not to dictate how data is moved across the nodes.

Q: What is an advantage of MCAPI over other mechanism of inter-task communication such as POSIX mechanisms, for example?
A: MCAPI spans beyond a single OS instantiation.

Q: What is the difference between MCAPI and StreamIt or Cilk++ model for doing multicore programming?
A: MCAPI is a message based communication framework defined for closely distributed computing. StreamIt is a programming language and compilation infrastructure for streaming applications. Cilk++ is an extension for C++ for multicore programming.

Q: What are main differences between MCAPI 1.0 and 2.0?
A: Addition of domains (for routing purposes), new functionality and improved consistency in the API and status codes.

Q: Isn't MCAPI just a new IPC protocol like LINX, MPI or others?
A: The MCAPI working group extensively reviewed existing APIs with the hope of finding one that met our requirements for multicore. MCAPI was defined for closely distributed computing, to be simple yet provide sufficient functionality and allow for lightweight implementations and more complex functionality to be layered on top of MCAPI.

Q: If we already implement an IPC, do we need to replace it to utilize MCAPI?
A: To what degree depends on how you plan to use MCAPI. In fact MCAPI could be a wrapper for an existing IPC, or, operate underneath an existing API.

Q: How does this compare to OpenMP or other parallel APIs.
A: MCAPI provides messaging applicable to AMP and SMP. OpenMP provides language extensions, targeting SMP environments.

Q: How does MCAPI compare to MPI?
A: Both provide message passing. MCAPI targets closely distributed computing whereas MPI targets more widely distributed computing. MCAPI is simpler allowing for lightweight implementations, whereas MPI provides a richer set of functionality. MCAPI and MPI were designed to address different communications needs and advantages could be realized by using both in a system with widely distributed topology with multicore subsystems.

Q: Is MCAPI similar to ARINC653 Supplement?
A: MCAPI provides data communication services only. It does not provide any sort of partitioning services.

FEATURES

Q: Are any reduction operations (such as those found in MPI) supported through MCAPI?
A: MCAPI is a simple communications API used to send/receive data across nodes. Build a reduce type operation on top of the message send routine to create a similar service.

Q: Does MCAPI include group communication or only point to point communication?
A: MCAPI does not have native support for multicast communications or broadcast groups, but the user could build this functionality on top of the connectionless messaging system. In other words, the user could implement multicast or broadcast functionality at the application layer using connectionless messages.

Q: Does MCAPI only provide for a standard set of calls or is there other overhead in the API that reduces throughput between endpoints? Is throughput dependent on layers under MCAPI only?
A: MCAPI is itself only a set of API services. There are two other components in a complete MCAPI implementation; the MCAPI stack and the underlying transport driver. These two components are implementation specific. The MCAPI stack interfaces with the API routines to create endpoints, get endpoints, pass data, etc. The underlying transport driver interfaces with the MCAPI stack to send and receive data. The transport medium is not part of the MCAPI specification and could be anything from a shared memory driver to a TCP/IP socket used to send and receive data across Ethernet.

Q: What about shared memory required for MCAPI?
A: An implementation can use a shared memory driver for sending and receiving data across nodes in a system, but shared memory is not required for using MCAPI. The MCAPI specification does not dictate the type of transport mechanism to be used to send and receive data.

Q: Are there any arbitration issues?
A: Handling arbitration is up to the underlying implementation.

Q: Are any error detection/recovery mechanisms available?
A: Error detection and recovery is not part of the MCAPI specification, but nothing prevents a programmer from building this into the implementation. MCAPI is designed for data communications only.

Q: Using MCAPI, is it possible to recover from a node failure in SMP/AMP real-time cluster?
A: MCAPI provides routines to initialize and shut down the MCAPI module on a node. If the node fails gracefully, it can shut down MCAPI, which could close all open endpoints and perform other implementation specific functionality. The shut down functionality is implementation specific. The programmer could configure the node to save the current state to memory and restore that state upon re-initialization, or could close all endpoints and start fresh on re-initialization.

Q: What about hooks for logging?
A: The MCAPI specification provides a list of error codes to be used for logging purposes, but no specific logging functionality is provided. Furthermore, an API routine is provided to convert a numerical error code to an ASCII string for easier readability. An individual implementation may provide additional logging services to the user.

Q: What hooks are there for debugging purposes?
A: The MCAPI specification doesn't detail any hooks for debugging purposes.

Q: In a system in which IP packets are sent from one core to another, can the message passing interface work?
A: MCAPI is suitable for this case and could use the TCP/IP stack as the underlying transport layer for transmitting/receiving IP packets across cores.

Q: Are both sampling and queuing message behavior supported?
A: This is up to the underlying implementation; both polling and queuing can be supported.

Q: Applications written to use MCAPI but written on cores with different endianess would not necessarily be endian-compatible. How are endian and integer size differences addressed?
A: The MCAPI specification does not provide a mechanism for endian conversion. Each implementation should document how endian conversion is handled for that solution.

Q: How can MCAPI be used in SMP environment?
A: MCAPI has little relevance in SMP, as the operating system should seamlessly handle communication across threads on the distributed cores; however, if the system is divided to use SMP on some cores and AMP on other cores, the SMP cores could communicate with the AMP cores using MCAPI. In an SMP environment Poly-Messenger/MCAPI nodes are the equivalent of a process and can be scheduled by the SMP OS like any other process. When an application is MCAPI enabled, the application or part of the application could also be run in AMP mode.

Q: Can multiple channels on multiple cores communication be handled and how?
A: MCAPI was designed to allow simultaneous channel connections across nodes. Any constraints in this ability would be at the underlying transport layer. MCAPI can handle multiple channels, but the underlying transport layer may not. This should be clearly documented by the individual implementation.

Q: Since hierarchy is used, how are lead domain and lead node managed?
A: The programmer must manage the notion of lead domain and/or node at design time.

Q: Why does MCAPI support master/slave and not client server?
A: MCAPI is a client / server model. A channel endpoint is used to either send or receive data. A message endpoint can be used to send and receive data.

Q: For message sending, does the MCAPI specification deal with message conflicts? It includes a priority variable, but what about multiple messages being sent to a node with the same priority?
A: Priority can be specified on a per-message basis when using MCAPI connectionless messages or for a connection when using packet or scalar channels. The individual implementation determines how the transport layer handles the prioritization of incoming packets. Priority conflicts are handled by the underlying transport driver and should be documented by the vendor.

Q: Is out-of-order memory writes handled by MCAPI?
A: This issue is specific to the individual transport layer driver.

Q: How is MCAPI different when going over Ethernet compared to socket communication between two processes on two cores in AMP configuration?
A: It would be beneficial to use the MCAPI services to limit changes required to the application if the underlying transport layer changes in a future revision of the software or if the same application layer software is used on different devices with varying transport layers.

Q: Can domains be hierarchical, other domains under domains?
A: MCAPI domains do not offer that level of granularity, as each domain exists at the same level in the topology. However, each domain does not have to be reachable from all other domains.

Q: Can MCAPI be used to implement locking mechanisms across AMP shared memory areas?
A: MCAPI can be used to send / receive any data across nodes in a system. This messaging architecture could be used to coordinate locking across nodes, but MCAPI does not inherently provide such services.

Q: Is it possible to send messages in non-blocking mode or blocking with timeout?
A: The MCAPI specification provides symmetric blocking and non-blocking routines for connectionless message and packet channel send / receive routines. The user can also configure a timeout for blocking calls.

Q: Does MCAPI have support for security, having to deal with multiple OSes?
A: MCAPI does not handle any sort of operating system partitioning.