Embedded Processing

Last year at the Multicore Expo, I was asked why there were not more embedded developers at the conference. After some thought, I pointed out that the discussion at the conference was dominated by how to parallelize software running on GHz class machines, even though the majority of embedded processor offerings are MHz class machines. The point being, maybe there were other motivations for using multicore in embedded designs rather than clock rates are not continuing their dizzying climb into ever faster rates. Issues such as reducing overall system-level design, build, and test complexity through resource partitioning. This question got me thinking over the last year, so much so that I have proposed an update to my earlier proposed processor taxonomy from several years ago to more explicitly address multicore architectures.

I thought that laying out such a taxonomy would be a straightforward task. All I would need to do is talk to people in the multicore industry and a taxonomy structure would be obvious. I envisioned that the taxonomy would specify separate categories based on different structures such as SMP vs AMP, or shared memory versus message passing.

I uncovered a few parallel processing taxonomies, including a Parallel Computer Taxonomy description that lays out four existing taxonomies and proposes a fifth one. Flynn's taxonomy is popular nomenclature that was proposed in 1966. It specifies four categories: SISD, SIMD, MISD, and MIMD architectures. Flynn’s taxonomy has been extended to include implementations for shared memory and various levels of coupling. Like the Flynn taxonomy, the other four taxonomies focus on silicon implementation details, and while this may be useful for silicon architectural designers to talk to each other, it does not acknowledge the concerns of software developers and software development tool vendors.

As a result, I have proposed a starting point for classifying multiprocessing architectures by exploring how and why our industry classifies single-core processors the way it does. An important take away is that each type of single-core processor (think microcontrollers, DSPs, and DSCs) not only focuses on certain types of silicon optimization trade-offs, they are supported by different types of development tools, and they require a different skill set to develop the software for each.

I relied on my personal experience designing multi-core systems to identify four categories of multiprocessing. I loosely identified them as channel-based, aggregate-based, multi-domain, and feedback architectures. I have personal experience with three of these – I lack direct real world experience with channel-based designs. Each of these types of multicore designs require a different thought process, and they each would benefit from different types of development and test tools. I will expand on each of these over the next few days with follow-up posts here.

My primary goal is to raise the question, are we talking about the correct things for embedded multiprocessing. Multiprocessing is such as large topic that I have invited a handful of people to contribute via the guest blog “How we see embedded processing”. John Goodacre of ARM has been kind enough to provide the first contributed post. Check it out and join the conversation. If you would like to provide a contributed piece rather than just a response to this or a guest’s post, please send me an email.