Companies are regularly offering new and innovative processing platforms and functions in their software development tools. One of the biggest challenges I see for bringing new and innovative capabilities to market is supporting incremental adoption and migration. Sometimes the innovative approach for solving a set of problems requires a completely different way of attacking the problem and, as a result, it requires developers to rebuild their entire system from scratch. Requiring developers to discard their legacy development and tools in order to leverage the innovative offering is a red flag that the offering may have trouble gaining acceptance by the engineering community.

I have shared this concern with several companies that brought out multicore or many-core systems over the past few years because their value proposition did not support incremental migration. They required the developer to completely reorganize their system software from scratch in order to fully take advantage of their innovative architecture. In many cases, this level of reorganizing a design represents an extremely high level of risk compared to the potential benefit of the new approach. If a development team could choose to migrate a smaller portion of their legacy design to the new approach and successfully release it in the next version of the product, they could build their experience with the new approach and gradually adopt the “better” approach without taking a risk that was larger than their comfort level.

Based on stories from several software development companies, software development tools are another area of opportunity for new capabilities to benefit from being able to support incremental adoption. In this case though, the new capabilities do not require a redesign, but they require the developer to accept an unknown learning curve to even evaluate the new feature. As the common storyline goes, the software tool vendor has found that describing the new capability, describing how to use it, and getting the developer to understand how that new capability benefits them is not as straight forward as they would like. As a result, some of the newest features they have added to their products go largely unnoticed and unused by their user base. Their frustration is obvious when they share these stories – especially when they talk about the circumstances where developers do adopt the new features. In many cases, a developer calls them with a problem and the software tool vendor explains how they have a capability already in the tool that will help the developer solve that problem. Only then does the developer try out the feature and then adopt using it in future projects, but they had to experience the type of problem that the feature was designed to assist with before they even recognized that the feature was already added to the tool suite.

Rather than harp on the failures of accommodating incremental migration or easing the adoption learning curve, I would like to uncover examples and ideas of how new innovations can support incremental adoption. For example, innovative multicore structures would probably be able to better support incremental migration if they accommodated inter processor communication mechanisms with cores that exist outside the multi-core fabric rather than leave it to the developer to build such a mechanism from scratch.

Texas Instruments’ recent 0.9V MSP430L092 microcontroller announcement provides two examples. The microcontroller itself is capable of operating the entire digital and analog logic chain from a 0.9V power supply without the need for an on-board boost converter. To support legacy tools sets, the available flash emulation tools provide a mechanism to transparently translate the power and signals to support debugging the 0.9V device with legacy tools.

The other example of the L092 device is that it includes a new type of analog peripheral block that TI calls the A-POOL (Analog Functions Pool). This analog block combines five analog functions into a common block that shares transistors between the different functions. The supported functions are an ADC (analog-to-digital converter), a DAC (digital-to-analog converter), a comparator, a temperature sensor, and an SVS (system voltage supervisor). The analog block includes a microcode engine that supports up to a 16-statement program to autonomously activate and switch between the various peripheral functions without involving the main processor core. The company tells me that in addition to directly programming the microcode stack, the IAR and Code Composer development tools understand the A-POOL and can compile C code into the appropriate microcode for the A-POOL.

If we can develop an industry awareness of ways to supporting incremental adoption and migration, we might help some really good ideas to get off the ground faster than otherwise. Do you have any ideas for how to enable new features to support an incremental adoption?

Tags: Incremental Migration, MSP430, Software Development, Texas Instruments

This entry was posted on Wednesday, September 15th, 2010 at 2:39 pm and is filed under Question of the Week. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.