Embedded Processing

MDBM (Multidomain-based multiprocessing) is a taxonomy category that encompasses applications that span multiple software domains, such as cell phones, automobiles, and many consumer products. This type of multiprocessing has been the bread and butter of embedded-multicore designs for decades. The multiprocessing implementation in many MDBM applications is less about meeting high-end processing performance – rather it is more about: partitioning design, build, and test complexity into semi-independent and manageable chunks; providing more independence in the time domain for resources that would otherwise be in complex contention in a shared capacity such as in a single processor implementation; and providing an optimized processing platform for each type of task that needs to be performed, such as using a microcontroller, DSP, and general-purpose microprocessor in the same system.

A common example of a MDBM application is the desktop computer. Sure contemporary machines include multiple CPUs, but even single-CPU desktop computers are MDBM systems. Desktop computers include many specialized processors, such as a video processor, an audio processor, a hard-drive controller, an Ethernet controller, a keyboard controller, and a mouse controller - just to name a few. Each of these subsystems can use their own processor separate from the CPU. All of these subsystems need to be able to coordinate, synchronize, and work together; otherwise the desktop computer may be deemed broken.

CBM (channel-based multiprocessing) applies to a single domain problem; it focuses on performing, in parallel, a similar type of processing on different sets of data that are relatively independent of each other. ABM (aggregate-based multiprocessing) also applies to a single domain problem; it focuses on how to break a single task into parallel subtasks that later are reintegrated or aggregated together to meet the performance requirements of the task. FBM (feedback-based multiprocessing), like MDBM, can apply to multiple domain problems, and that will be the topic for the next post in this series.

By virtue of being a multidomain application, the different tasks have some level of independence between them; however, there can also be some level of coupling and communication between the different domain spaces, such as for synchronizing to common event criteria. Another difference in MDBM systems is that they can include implementations of the other types of multiprocessing. A fully autonomous, mobile system, might rely on an ABM task to preprocess vision information, and a CBM task for performing object recognition on the results of the vision information, and a FBM task for establishing context and prediction processing. At the same time, the autonomous system could be performing another task to transmit data to a recording station.

An important thrust of designing MDBM systems is how to decide when to share processing resources and when to use duplicate sets of those resources to manage design complexity, to mitigate contention timing conflicts, and to provide better energy efficiency by matching processing resources with each type of task requirements. The implications for developments tools to help designers, not just chip architects, is that they should enhance designers’ ability to explore and compare system level metrics of different configurations against different runtime scenarios.

As with the other proposed multiprocessing categories, MDBM does not directly map with a homogenous or heterogeneous set of processor cores; rather it focuses on the relationship between the different tasks and the options for implementing them within the system. The choice to use a set of homogeneous, general-purpose microprocessor cores may be influenced by the range of tasks that the system must be able to support or even the amount of uncertainty of the types of tasks the system will need to support. If the types of tasks are known and not subject to too much change, the designer can choose the appropriately optimized processor architecture for each type of task to save design, build, and test costs – as well as reduce power consumption.

If you missed the previous post in this series, check out my comments about aggregate-based multiprocessing in this multiprocessing series.