Configurable processors: Stir it up

Ask enough people what defines a configurable system, and you will realize that each definition depends on the person's assumptions about how to abstract the system components. For embedded systems, the abstraction usually applies to the system's hardware components and any accompanying software. A common thread for defining a configurable system is that you have the flexibility to change a system's features and behavior without materially changing the system platform. What differs between each definition of configurability is the interpretation of what materially changing the system platform means (see sidebar "Configurable perspectives").

Your application's cost and flexibility requirements drive the need for and value of each type and level of configurability. Costs can manifest themselves in your project as first-to-market-opportunity costs; upfront, nonrecurring costs; recurring bill-of-materials costs; and development-support costs. Platform flexibility allows you to change your design and add capabilities to it without scrapping your work and incurred costs. Flexibility allows you to more easily reuse your work across multiple designs, accommodate changing requirements, correct design errors, and "futureproof" standards-based designs, such as for communication protocols.

Using an ASIC to implement a fixed function in your design makes the most efficient use of silicon. An ASIC lets you balance and optimize your design for higher performance with lower recurring costs and lower power requirements. Offsetting these advantages is the fact that the high, upfront, nonrecurring costs you incur to build an ASIC necessitate that you amortize those costs across large volumes. A fixed-function ASIC has poor flexibility that can eliminate your ability to amortize a single ASIC design across multiple projects and can require you to perform a redesign and again incur the nonrecurring costs to add new capabilities to your application. Finally, ASIC development has a longer cycle time than other approaches, because you must design and test your circuit, fabricate the wafers, and validate your implementation.

Using ASSPs (application-specific standard parts) in your design allows you to reduce your development time and trade upfront ASIC costs for higher recurring costs, because the device vendor has already incurred those costs. If an appropriate ASSP is available, it is unlikely that you are the first to market. You must therefore consider differentiation challenges, because your competitors have access to the same device. Like ASICs, ASSPs are not flexible platforms; they are inherently specific and optimized to a target application. According to iSuppli (www.isuppli.com), the 2002 ASIC market was down 28% from the 2000 market high, primarily because of weakening demand for wired communications and partly because of an overall shift to standard products, such as ASSPs, which showed a growth of 1.6% in 2002.

ASPPs (application-specific programmable parts) or SOCs (systems on chips) improve on an ASSP's inflexibility by sacrificing some performance, silicon (cost), and power efficiency for software programmability. These devices differentiate themselves by integrating an optimized set of peripherals, memories, interface controllers, and application-specific hardware accelerators with a DSP, a microcontroller core, or both.

Standard general-purpose, software-programmable devices, such as DSPs, microcontrollers, and microprocessors, do not integrate application-specific hardware accelerators, and they integrate a more general set of peripherals, memories, and interface controllers than do ASPPs. They sacrifice some combination of higher performance, lower power, and lower cost to support a wider variety of applications, but, because they are useful for a variety of applications, their development tools and industry-support infrastructures are more mature than those of ASICs and ASSP devices. There is also a larger pool of experienced software developers for these instruction-set-processing platforms.

All of these devices employ fixed architectures that offer a spectrum of options to maximize and minimize system performance; power; upfront, nonrecurring costs; recurring costs; development time; and flexibility. To increase your system's performance with these devices, your can redo how you implement your algorithms, change your processor choice, or increase the clock speed. The workload requirements for applications with heavy digital-signal processing can exceed the maximum workload your processor can perform at the fastest clock speed. Your processor choice and application specifics may allow you to scale your performance by operating multiple processors together, but adding processors to your design can complicate it by introducing communication requirements to coordinate between the processors. Adding processors or fixed-function accelerators to your design can push your power consumption, bill-of-materials cost, communication latencies, and board-space requirements beyond what you can afford.

Configurable hardware architectures can help you when available fixed-architecture approaches cannot meet your requirements or when device-level flexibility is important. Configurable architectures allow you to balance performance, power consumption, and the cost of silicon area, and it can provide higher performance, lower power consumption, and lower cost, because you need fewer clock cycles and less logic to compute the same result as your programmable, fixed-architecture implementation. Configurable architectures provide mechanisms for configuring the system resources, extending the instruction-set architecture, or both.

Configuration mechanisms may allow you to tune your system to application requirements by changing the processor resources, such as by adding, deleting, or resizing various memories, such as caches; changing bus widths; creating special registers and buses; duplicating execution units, such as ALUs and MACs, to improve instruction-level parallelism; integrating custom peripherals; and even creating multiprocessor systems. This flexibility allows you to tune your system and address system bottlenecks for higher performance; however, a configurable architecture can lengthen the design process when the software-development tools cannot easily use the additional resources for performance optimizations.

Extending the instruction-set architecture effectively converts software into accelerated hardware and abstracts the implementation into the software-instruction-set architecture. Application-specific instructions can improve by orders of magnitude the amount of work an application can perform per clock cycle and reduce the lines of software code it needs. These custom instructions usually simplify software development, debugging, and verification efforts at the expense of upfront profiling analysis that compares custom instructions with pure-software execution. Extending the instruction set can lengthen the development process if the software-development tools lack simple or automatic support to incorporate the custom instructions into the compiler and simulator.

Configurable architectures are available across a similar range of implementations to those of fixed-architecture approaches to maximize and minimize system performance; power; up-front, nonrecurring costs; recurring costs; and development time (Table 1). Configurable and extendable IP (intellectual-property) processor cores support configurability to the point of silicon fabrication and have similar advantages and disadvantages to those of ASICs. Development tools for these architectures may include performance tools that can provide you with immediate estimates on the performance, die size, and power requirements of a design.

Configurable processors can support field hardware updates and operational-mode reconfigurability, such as switching from processing one codec or protocol algorithm to another, by integrating a programmable logic block with a hard processor core and a minimum set of peripheral blocks. A number of available standard processor products include this level of integration. They allow you to customize a peripheral set and implement custom instructions, but they do not support reconfiguring the base resources of the processor core. You gain the extra flexibility of these systems at increased cost, because the reconfigurable portion of the device requires more silicon than it would if you had implemented it using fixed components.

FPGAs are other standard device options for implementing reconfigurable and extendable architectures, and developers successfully use them as algorithmic coprocessors to standard processor cores. Standard FPGA devices can also include soft-or hard-processor cores to support software programmability and to expand their use by software developers. FPGAs' high-flexibility and foundry-independent logic makes them strong candidates for prototyping configurable designs and for delivering low-volume, high-margin applications. These devices avoid the upfront costs of ASICs, but they consume more silicon space, have poor power efficiency, and have a high recurring cost that can be a concern for high-volume applications.

Dynamically reconfigurable architectures can drive configuration flexibility to the extreme by supporting single-clock-cycle reconfiguration and replace the concept of instruction sequencing with configuration sequencing for data flow and task-level parallelism. Dynamically reconfigurable architectures can implement functions needed at a given moment and then reuse the same block of gates or computational units for a different function at the next moment. This flexibility entails extra cost and complexity for handling more power-consuming, fast-loading circuits and higher complexity for switching methods and circuits. Currently, a small set of applications can benefit from this level of reconfigurability, because it enables a level of gate-reuse efficiency that can allow you to implement the application in a smaller silicon area with lower system-power consumption than other approaches.

Software development influences most current design efforts. A configurable architecture's flexibility and productivity are limited without software programmability, especially for applications that support multiple evolving and emerging standards or protocols. According to many vendors of configurable, programmable architectures, developers often first approach them to explore using the configurable architecture as a stopgap hardware accelerator with legacy design and software assets that cannot scale up performance to meet new processing workloads.

To effectively use a configurable architecture, you need to expend extra effort during system analysis to explore how to best partition your hardware and software. The system-analysis, software-development, and system-verification tools that support your architecture choice heavily impact the effectiveness of exploring partitioning options. The system-analysis tools should help you identify underused hardware resources that are candidates for elimination; resources you could add or reorganize to improve application-specific performance; and code that is a good candidate for custom instructions, because it consumes high percentages of processing cycles. The software-development tools should simplify or, better yet, automatically incorporate your configuration and instruction extensions. The speed, quality, and integration of your co-simulation, emulation, analysis, and profiling tools directly affect the number of partitioning configurations you can explore and compare.

Designing with configurable architectures changes how you explore system partitioning from fixed architectures, because you retain the flexibility to change your configuration until the last moment. A flurry of effort to explore partitioning configurations typically characterizes the first few weeks of a development project with a configurable architecture. Then, partitioning-exploration activity drops off, and system integration becomes the focus. The last few weeks of a design using a configurable architecture might see a resurgence of partitioning exploration for final tuning and optimization opportunities.

Configurable and instruction-extendable architectures effectively enable you to convert your software into accelerated hardware and allow a lot of freedom in how you can implement your system (see sidebar "Supporting your legacy"). Software developers, in general, are not experienced in implementing hardware-instruction acceleration, but software developers represent a large target market for configurable architectures. An apparent goal for configurable-architecture-development tools is to present a development environment that tries to make implementing hardware-instruction acceleration as intuitive as possible to software developers. Inherent in meeting this goal is the ability to easily or automatically incorporate custom instructions into the software-development tool chain.

Flexibility is not free; so, is configurability cost-effective? A standard, fixed-architecture processor device is usually a more cost-effective implementation if it exactly meets your design requirements. The catch is that the device needs to exist and be available when you need it. Will the device road map meet your needs at the next iteration of your application? Will you be able to continue leveraging your legacy assets? High-performance, application-specific signal processing does not constitute an entire design, so a completely configurable implementation is impractical for most applications. A better approach for many applications is to mix fixed and configurable components as tightly coupled coprocessors to leverage the advantages of both approaches.

As persistent network connectivity becomes more pervasive, these same reconfigurable architectures provide the basis for field reconfiguration for remote monitoring, testing, and upgrades. Fixed-architecture processors with flash memories already support field repro-grammability. It is not too much of a stretch to expect that analogous hardware reconfigurability will become as important and pervasive for applications with variable and growing signal-processing requirements.

Besides being able to cost-effectively meet application-specific, high-performance, digital-signal-processing requirements, system-load-time configurable architectures are a strategy for implementing multiple product derivatives from a single design approach. For developers, many of whom lack a hardware background, important challenges and opportunities exist for tools to simplify how to directly implement algorithms as hardware. Not that many years ago, programming for signal processing was an esoteric topic, but recent evolutions in tools have opened and continue to open the world of signal-processing programming to a wider audience.

Author Information

You can reach Technical Editor Robert Cravotta at 1-661-296-5096, fax 1-661-296-1087, e-mail rcravotta@edn.com.