Over the last few months I’ve noticed an increase in the number of tools that transform high-level signal-processing application descriptions into real-time implementations. The appeal of this idea is obvious. Many signal processing applications are initially designed using high-level tools and then migrated into low-level descriptions. Often this migration process involves multiple labor-intensive, error-prone steps. For example, an application might be developed using MATLAB, then re-built using floating-point C code, then again using fixed-point C code, and then finally optimized using assembly language. Cutting out the middle steps can make the development process faster and can help ensure that the final product matches the initial high-level design.
In addition, these tools potentially reduce the number of distinct engineering teams needed for product development. For example, engineers specializing in MATLAB-based algorithm development are rarely skilled in assembly-language software optimization. As a result, product development typically requires multiple teams of specialists. By using a tool that transforms high-level descriptions into implementations, the high-level developers can create the implementation themselves.
Unfortunately, so far the idea of automatically turning high-level descriptions into production-ready implementations has been like the ancient alchemists’ dream of turning lead into gold: it’s a compelling idea, but nobody can seem to make it work. One problem is that the path from a high-level description to an optimized, production-ready implementation is often not a straight line. For example, it is sometimes possible to optimize an application by removing a resource-hungry algorithm block and replacing it with a very different block that produces similar results. It is very difficult to create an automated tool that can exploit this type of optimization opportunity.
Even when the mappings between high-level descriptions and optimized implementations are more direct, automated tools often perform poorly unless the user gives the tool plenty of “hints.” For example, tools that transform C code may require the user to structure the C code in certain ways or to use a limited, specialized set of C statements. And providing effective hints may require an intimate understanding of the underlying hardware—partly negating the value of a high-level tool.
Tools that create real-time implementations directly from high-level application descriptions hold great potential. But today such tools do not offer sufficient generality and efficiency to make them practical for cost- or energy-sensitive applications. There is much work to do before we get to that point. In the meantime, vendors and prospective users must be realistic about what such tools can achieve.
Add new comment