MCAPI – lessons learned
Some weeks ago, I wrote a blog entry on MCAPI, which seemed to provoke some interest. Last week we ran a Web seminar on this topic, in conjunction with the Multicore Association. This was well attended and seemed well received. You can access the archive recording here. We will be running another session soon, with timing oriented towards European attendees.
I have done quite a few Web seminars now and I observe certain patterns. A key one is that, although the session is run to convey information to the audience, I always tend to learn things too. This might be because I have some of the Mentor Embedded technical folks online with me to help with questions. On this occasion, I had Tammy Leino, one of our senior engineers, and Markus Levy of the Multicore Association on hand. How could I not learn stuff? But I also learn from the attendees …
Although I often get follow-up emails, the primary interaction with the audience is the question and answer session. We normally play a recording of the presentation, which means we can take some questions while that is going on. When it is finished, we field questions verbally [though they are submitted via a chat box].
It is these questions that I learn from. Sometimes it is the sheer number of queries in a particular area which highlights a strong interest among developers. A while back, I did a Web seminar on C++ and there was a lot of interest in dynamic memory allocation issues. I took this as a hint and we ran a session on this specific topic a few months later. I am always interested in new topics for presentations, so do feel free to comment or email.
On this occasion, what I learned was that the scope of MCAPI is unclear – or, at least, my presentation of that was not fully understood. There were lots of questions about performance and overheads. Whilst this is broadly encouraging, as embedded developers should always be questioning resource utilization, it is not directly relevant to MCAPI. An API is simply an interface to applications code – nothing more. MCAPI is just an API. A particular implementation may introduce massive overheads, but that is not intrinsic to MCAPI itself. What really matters is the transport and physical layers that handle the data underneath MCAPI. There are numerous possibilities. At one extreme, the communication data handling could all be done by hardware with MCAPI just providing the interface to the drivers. At the other extreme, the underlying communication might be using TCP/IP over a slow connection [the legendary “wet piece of string”]. Most likely, a shared memory interface is used [this is how the initial Mentor Embedded implementation was configured], but even this could be implemented in a number of ways.
A number of other questions that we received were along the lines of “Does MCAPI work on xyz hardware?” This really misses the point that MCAPI is hardware [and OS] agnostic. As long as there is some kind of message transport available on the target system, MCAPI implementation is likely to be straightforward.
Obviously, some clearer communication is needed to set out not only what MCAPI is, but also emphasize what it is not and how the specific implementation affects performance, overheads, memory footprint etc.
It is said that there is no such thing as a stupid question – just the one you did not ask. I normally go along with this, as I have often asked questions in meetings, only to be told by other s later that they were wondering the same thing and were afraid of appearing ignorant. I do not let that fear worry me. Clearly, neither did the attendee of our Web seminar who asked “What is multicore? I hope that he got his answer.
