By Jeff Bier, 5/11/2004
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.
|