Embedded Processing

I delayed posting about feedback-based multiprocessing until the remaining guest posts related to multiprocessing were posted. Check out what Grant Martin from Tensilica had to say about dataplane processing and what Kent Fisher from Freescale had to say about the current issues regarding industry consensus.

When I was putting together the multiprocessing taxonomy, I went back and forth between including or leaving out FBM (feedback-based multiprocessing). As Kent pointed out, public discussions in industry multicore conferences still lack an agreement of what exactly defines a multicore system. My concern with including FBM in the taxonomy is that it could feel like a subset of MDBM (Multidomain-based multiprocessing); however, I think the difference are sufficient to warrant its own category – namely that multidimensional outputs of the system affect how the multidimensional inputs of the system vary over time.

FBM is not a new technology. My experience with FBM designs extends back almost twenty years while designing and building fully autonomous systems. With the growing interest in robotics and smarter, more autonomous automobiles, I expect that the skill set and the development tools needed to design, build, and test such systems will be going through an exciting maturation over the next few decades.

I previously pointed out a public demonstration of a FBM-like system – although I identified the BigDog demonstration as an example of a learning machine. The types of projects I have experience with rely on a tight coupling between the different types of sensors and the system’s inertial measurement device. This tight coupling to a common framework allows the system to correlate slight differences in data magnitude and phasing information between different sensors to nuance out subtle yet important information. It allows the system to refine vision and audio sensing by correlating with the systems orientation and motion, and it permits semi-autonomous portions of a system, such as the limbs in the referenced BigDog demonstration, to be able to work together as a whole.

The reason I propose FBM as a distinct category in this taxonomy is because it requires a different skill set and development tools than the other categories. For one, sensors and actuators can have multiple purposes beyond their primary function because they share a common reference point – the inertial measurement system. They can be used to augment the measurement and control of other portions of the system by injecting known perturbations in their behavior to help other parts of the systems identify and filter out noise. For example, I have worked on systems that used deliberately induced motion to help adjust for systemic weaknesses in various vision systems.

A characteristic of these types of systems is that it is very difficult to determine whether they are performing properly or coincidentally acting in a fashion that looks like they are behaving properly. Because these systems may include a learning or predicting capability, when we would complete a real full-system test, it could take several weeks of post-test analysis of the system’s data to determine if the actions it took were for the reasons we thought they were taken. The fact that the system might have behaved the way we wanted it to did not mean it did it for the correct reasons – nor that it would behave properly again with subtle environmental differences.

The analysis and development tools for these types of systems go far beyond a compiler, debugger, profiler, and code simulator. You need system level simulators that include the environment. If your project does not have an infinite development budget, you might have to switch between open- and closed-loop simulations. You may need to build a hardware-in-the-loop capability because you may need to be able to mix and match real and virtual components in the system because there is no other way to test the various parts together without risking destroying what you are building. In the past, these systems were all hand-built by the analysis and development team; these efforts represent a substantial part of the team’s intellectual property. As a result, I suspect this type of multiprocessing will be the slowest to mature, but once it reaches a certain level of capability, it will explode into many designs.

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