The hardest thing that multicore has had going for it is the perception that it’s hard. OK, that plus the fact that it is, in fact, hard. Or it can be. Although familiarity and tools are improving that. Nevertheless, it’s been a slow slog as multicore has gradually made its way into the embedded consciousness.

Part of the problem is that there is no one right answer for multicore anything. No one right architecture, no one right core, no one right set of tools, no one right way to write software. It all depends on what you’re trying to do. So it’s impossible simply to say, “Here’s how you do it, now off you go.”

The alternative, as envisioned by the Multicore Association, has been to compile a set of best practices, assembled by early adopters, for the benefit of relative newbies. And, frankly, the not-so-newbies – there’s always something more to learn. (And perhaps even debate.) That compilation has just been announced: a snapshot of multicore dos and don’ts summarized in a mere 100-odd pages.

After some basic overviews, it deals with high-level design, then low-level design, followed by debug and performance tuning. As you might suspect, covering so many topics in such a succinct fashion would make this less of a multicore primer and more of a hand-up once you’ve got your arms around multicore basics. In fact, it’s probably one of those things that’s best to take on after you’ve screwed up a project or two (hopefully as learning exercises, not as business disasters). OK, “screwed up” is possibly too strong; let’s say that some months of struggle with various non-obvious multicore issues will make this a rather more accessible document. And probably one that bears re-reading from time to time, since you’ll probably pick up more each time.

You can find your way to more information and the document itself via their announcement.