editor's blog
Subscribe Now

Lightweight Embedded Multicore Task Management

The Multicore Association has released the latest of its multicore management APIs. The first such API they released was MCAPI, which allows data to be communicated throughout a potentially complex heterogeneous embedded multicore environment. The next was MRAPI, which deals with the management of resources, allowing virtual extension of scope beyond what an OS would provide in a single process.

This time it’s MTAPI, for managing tasks. Now… you may ask, “Why do we need yet another task-management capability when we have pthreads and OpenMP and MPI?” There are a couple of reasons:

  • Pthreads and OpenMP only work within a given process and/or assume a level of homogeneity. Heterogeneous AMP systems can’t use them. In other words, you can’t invoke a task on some different-ISA core that’s managed by a completely different instance of an OS (or no OS at all).
  • MPI is far too heavyweight for embedded applications having thousands or more tasks to manage.

While you might think extending something like pthreads to cross process boundaries courtesy of a quiet little runtime might be straightforward to the programmer, MTAPI has, in fact, introduced some abstract notions with which I had to struggle a bit for understanding. There’s no overall high-level description of the relationships with examples, so I sort of pieced it together by reading the various bits of the standard and deciding I think I knew what was going on. (Danger!)

So here’s my take on it. We’re used to simply invoking a task (typically a thread). But on complex systems, there may be any number of different “candidates” for implementing that task.

  • You may have multiple cores, each of which has a function that can implement the task.
  • These cores may or may not be the same – one may be a CPU, the other may be a DSP.
  • You may have dedicated hardware for implementing the function.
  • You may have a mix of cores and dedicated hardware accelerators, any of which could be chosen for a given execution.

So they’ve included an extra layer of abstraction, yielding three different notions:

  • An action is the “potential” for executing a task. Let’s say CRC generation is something you need to have done, and you have one CRC accelerator and four different cores, each of which has a “GenerateCRC” function. The accelerator and GenerateCRC functions are all actions. The software versions are registered with their local MTAPI runtimes; the hardware versions are built into the system. Each of these is a candidate with the potential for executing a specific run with a specific set of data.
  • A job is an abstraction of all of the different available actions for a given thing that needs to be done. So you might have one “CRC_job” representing the five different ways of generating a CRC. This supports the use of queues or load balancing. When you actually need to get a CRC, you don’t call one of the specific action functions/hardware; you call the job, and the system decides which action gets chosen to run the specific instance.
  • A task is a specific instance or execution of… something that needs to be done. (It’s really hard to describe this stuff casually without using words like “task” and “job,” which have specific meanings in this context… it’s why your head can end up spinning.) The task is the specific call you make when actually running; it makes reference to a job and, via the job, gets assigned to one of the actions tied to the job for execution (say, a software implementation on one of the cores).  It can be cancelled while running; it can also be run as blocking (non-blocking is assumed as the typical usage). It can also be “detached,” meaning that it “floats free” and is no longer accessible by the calling code, in which case it can’t be cancelled or configured as blocking – it strikes me as similar to a terminal thread. Tasks can also be grouped, with an entire group acting as a blocking mechanism.

The other aspects of MTAPI struck me as more accessible. It covers how the details of this are handled, as well as such aspects as whether or not memory is shared, parameter- and result-passing, status checking, and the like.

You can get more info from their release, and the full API (as well as a “nutshell” document) is now downloadable from the Multicore Association website.

Leave a Reply

featured blogs
Sep 25, 2020
Normally, in May, I'd have been off to Unterschleißheim, a suburb of Munich where historically we've held what used to be called CDNLive EMEA. We renamed this CadenceLIVE Europe and... [[ Click on the title to access the full blog on the Cadence Community site...
Sep 24, 2020
I just saw a video from 2012 in which Jeri Ellsworth is strolling around a Makerfaire flaunting her Commodore 64-based bass guitar....
Sep 24, 2020
Samtec works with system architects in the early stages of their design to create solutions for cable management which provide even distribution of thermal load. Using ultra-low skew twinax cable to route signals over the board is a key performance enabler as signal integrity...
Sep 18, 2020
[From the last episode: We put the various pieces of a memory together to show the whole thing.] Before we finally turn our memory discussion into an AI discussion, let'€™s take on one annoying little detail that I'€™ve referred to a few times, but have kept putting off. ...

Featured Video

AI SoC Chats: Memory Interface IP - DDR, LPDDR, HBM, GDDR

Sponsored by Synopsys

When building AI SoCs, how do you choose the optimal memory interface? Learn about the market trends and challenges for DDR, LPDDR, HBM, and GDDR, and how Synopsys DesignWare IP can help.

Click here for more information about DesignWare IP for Amazing AI

Featured Paper

Helping physicians achieve faster, more accurate patient diagnoses with molecular test technology

Sponsored by Texas Instruments

Point-of-care molecular diagnostics (PoC) help physicians achieve faster, more accurate patient diagnoses and treatment decisions. This article breaks down how molecular test technology works and the building blocks for a PoC molecular diagnostics analyzer sensor front end system.

Read the Article

Featured Chalk Talk

Use of Advanced Sensors in Smart Industry Applications

Sponsored by Mouser Electronics and ST Microelectronics

In industrial systems, sensors can give us real-time information about the condition and operation critical machinery. By monitoring vibration, temperature, and other factors, we can get early warning of failures and do predictive maintenance - avoiding costly downtime. In this episode of Chalk Talk, Amelia Dalton chats with Manuel Cantone of ST Microelectronics about the SensorTile Wireless Industrial Node - an integrated solution that makes industrial monitoring a snap.

More information about STMicroelectronics STWIN SensorTile Wireless Industrial Node