The designers of consumer electronic products today spend more and more effort at the electronic system-level (ESL) on developing the application software for these consumer products. Only with an ESL design flow — which enables users to make architectural tradeoffs early in the design cycle — can these users innovate quickly and create exciting new applications. New and innovative tools and languages are now available, rounding out an entire ecosystem for ESL design. And custom implementations — like application specific instruction processors (ASIPs) — are enabled by this ecosystem and let users create clearly differentiated products. At the ES level, like RTL, designers spend a significant amount of time with simulation. The difference in an ESL flow is that simulation is approximately 100 times faster than with RTL. With ESL, designers initially investigate the algorithm needed for the best performance of the new application. Key to this investigation are simulation performance and available simulation models. As an example, UWB — as promoted by the MBOA Alliance and featured by Intel during their Developers Forum — is currently at the stage of algorithm design and standards evolution. Players in the UWB space maintain their competitive advantage today through system-level simulation of the standards proposals together with the companies that own proprietary algorithms. Once the algorithms are defined, they must be broken down into custom hardware and functions, which run on standard processors such as DSPs and RISCs. This task requires tools to help with partitioning, and again requires simulation of performance with respect to memory and bus architectures. Today this is typically done by modeling those components in SystemC. In addition, power analysis for the software helps to derive the best memory architecture or software architecture with a given processor core. An additional and extremely important consideration is how to meet the power budgets. The dilemma is basically that a software implementation on a standard processor might be too power hungry. A custom hardware solution is a huge risk because it fixes the specification too early, hence risking one million dollars or more for a ninety-nanometer mask set. Application specific instruction processors (ASIPs) address this problem and offer the flexibility of a programmable solution, while remaining energy efficient through a targeted instruction set. In the history of EDA, there have been several technologies that have tried to address custom processors, but the lack of good quality, flexible, and easy-to-use tools for the creation of the models and software development tools was a barrier to adoption. The answer was the creation of a very concise language (LISA 2.0) and the associated processor design tools. Starting from a LISA 2.0 description, new tools provide automatic generation of simulation models, the C compiler, and RTL implementation code for the ASIP. Designers can now design many variants of a processor within hours. By being able to profile the instruction set with the application code, the outcome is a processor that is optimized for a certain application task, with the flexibility to be programmed with a range of programs achieving similar performance. An ASIP is therefore able to cover the typical range of residual risk for the product specification. ASIPs are the evolutionary enhancement to existing platforms that already carry standard DSP and RISC processors. ASIPs enable those platforms to support more functionality across a wider range of applications. Karl Van Rompaey is CTO of CoWare, Inc. |