Casual Adopter

As processors continue to provide more processing capabilities, the opportunity for developers to incorporate more complex functions into their designs that go beyond their level of intimate understanding grows. As this complexity grows, it becomes even more important to abstract and encapsulate it so that developers can focus their attention on those details that generate new value-add capabilities. As discussed in my article about the evolving DSP market, semiconductor vendors are increasingly bundling more software with their processor offerings to ease a developer’s learning curve and assist with a faster time-to-market.

This bundled software often consists of firmware-type code for drivers, communication stacks, and codec implementations. The software provides an efficient implementation that takes advantage of the processor’s application specific architectural features without requiring the adopting developer to even know about those features. This expands the available number of developers that can take advantage of each processor offering, but it also increases the complexity of supporting a wide range of skill levels that span from understanding down to the metal implementation expertise to casual adoption of these high level encapsulations without any awareness of the specialized resources used.

The ability to remain ignorant about a specialized processing resource has a positive effect on the development process. However, the companies offering these software bundles are uncovering how casual adopters can make assumptions that break the value of the encapsulation. I offer two anecdotes that illustrate that solving these leaks in the abstraction layer is more than just robust software interface design.

At a presentation I attended, the presenter’s algorithm discussion demonstrated innovative insights and approach to solving the problem; however, the presenter shared that they were having significant issues trying to approach the processing performance levels the algorithm required to be useful. During questions, it was uncovered that the presenter’s algorithm implementation was in floating point on a fixed point processor. The development tools allowed the presenter to work in a natural data type, even to the point of emulating the floating point operations on a processor that would provide superior performance after transforming the data type to another form. The presenter was completely unaware of this option until that question and observation was made during the presentation.

In another scenario, a story relayed to me involved a design team that was using a company’s flagship processor. Despite the significant processing capability of the processor, the design team needed even more processing capacity and was ready to abandon their processor choice to search for another. The company providing the processor offered to examine the design team’s implementation and see if they could help so as to not lose the customer. During the design review, the review team asked where was the DMA code; the design team replied “the DM what?” The review team showed the design team how to use the on-chip DMA controller and at the end of the day, the system had magically acquired an additional 40% headroom.

In both of these scenarios, the design team’s lack of awareness about special resources and how to use them prevented these developers from meeting their otherwise attainable processing requirements. This type of awareness is especially relevant to software development because the processing resources are shared and can negatively impact the performance of other parts of the system if not accounted for. This is huge reason why the ideal of software as components in the embedded market has failed.

However, there is a possible alternative to software as components - software development tools can evolve into software implementation exploration tools. Processor architectures continue to incorporate more complex architectures and specialized resources – including multiple processor cores in the same system. Software implementation is less an issue of knowing the best way to build a function and more a best guess on how to implement that function on a given target. The complexity of these systems is approaching (or already passed) the level of many developers to know the best implementation choice. The software tools could provide assistance by presenting developers with multiple ways to generate and configure the code on the target to enable the developer to empirically trade-off the approaches that optimize the most important characteristics without having to be an expert on every resource in the system.