Custom processors fall short for several reasons. First, ASICs are designed using logic synthesis and automated place-and-route tools. Interfacing a custom-designed processor into this flow as a black box is problematic. Second, custom-designed processors are delicately tuned to a particular process and foundry. Porting the processor to a new foundry or process requires several months at the very least. Furthermore, the ported design rarely takes full advantage of the new process. It is not practical to completely reoptimize the processor for this new manufacturing process since this would take nearly as much time as the original design. This is true whether the processor is being ported from one 0.25-micron process to another 0.25-micron process from a different foundry or porting the processor from a 0.25-micron process to a 0.18-micron process by the same foundry. Thus, it usually takes six to 12 months before a custom-designed processor can take advantage of a new manufacturing process. Third and most critical, it is not feasible, from a time-to-market standpoint, to modify a custom-designed processor to better match the application.

More immediate results

But configurable processors naturally match the ASIC design flow. The processor becomes simply one more block that is integrated into the ASIC, and configurable processors are not tied to a particular foundry. In addition, they benefit from manufacturing process improvements immediately because there is no lead time to port the design. In other words, a configurable processor can be manufactured by a different foundry or in a more advanced process immediately.

Moreover, because the circuit implementation is automatically generated it is possible to map the same register transfer level (RTL) description multiple times, resulting in different implementations. For example, the same RTL description can produce separate high-performance, low-power and low-cost implementations simply by changing the synthesis constraints and the target library. The biggest benefit of configurability-as illustrated by Tensilica's Xtensa architecture-is that it allows for extension by the system designer through the exploitation of a rich instruction set architecture (ISA) and a companion instruction extension capability.

Xtensa is a new ISA designed to enable configurability, minimize code size, reduce power dissipation and maximize performance. The ISA is defined as a base set of instructions guaranteed to be in all Xtensa implementations, plus a set of configurable options. For example, a system designer can choose to include a 16-bit multiply accumulate option if it is beneficial to the application. The base ISA defines approximately 80 instructions, including a set of load, store and flow control operations.

The architecture achieves smaller code size through the use of denser encoding and register windows. The ISA defines 24- and 16-bit instruction formats, as opposed to 32-bit formats found in traditional RISC instruction sets. The architecture provides a rich set of operations despite the smaller instruction size.

These sophisticated instructions, such as single-cycle compare and branch, enable higher code density and improve performance. The instruction encodings are designed to allow the compiler to use the smaller instructions for the most common operations, further reducing code size. Immediate sizes were also chosen to reduce code size. If, for example, the immediate value used to encode the offset in a conditional branch is too small, indirect branches must be used. This degrades code size (additional instructions are required to compute the target address and place it in a register) and degrades performance (the additional instructions occupy issue slots). Register windows reduce code size by eliminating the register saves and restores required at the entry and exit of every subroutine.

When we compiled the benchmarks for the Xtensa and a standard architecture, such as MIPS32 we found that code size for Xtensa is roughly half that for the MIPS32 because of the instruction set formats and the use of such things as register windows.

To take full advantage of the potential of a configurable ISA delivering high performance with a relatively small gate count, the designer must have an easy, predictable method for extending the functionality of the processor.

One of most powerful features of a configurable processor is that it allows extension of the processor capabilities by the system designer. It is impossible for the processor architect to foresee all possible applications of the core and include suitable instructions for each of these applications. The processor architect's job is, in fact, to decide which applications are common enough to warrant some level of support via dedicated instructions.

For example, in recent years processor architectures have added single-instruction, multiple-data instructions to better support multimedia applications. Many other applications can benefit from dedicated hardware. Some applications require, say, bit manipulations that are awkward with traditional architectures. Other applications require specialized shift or rotate operations. A third class of applications may require a different form of arithmetic. The number of opportunities to add specialized instructions is almost limitless.

With the Xtensa configurable processor, the architect must support only the basic types of operations common to all applications. The system designer can then add specialized instructions that boost application performance.

Extension of the processor is done via the Tensilica instruction extension language (TIE). It specifies the opcode, the encoding and the semantics of the instruction. Essentially, the TIE language allows the designer to specify the encoding of new instructions. It also allows the designer to declare new state registers. The state registers can hold intermediate values or control information. The user can optionally declare the state registers to be part of a user-defined register file.

This does two things. It allows the TIE compiler to automatically generate a library that can be used by a binary distribution of a real-time operating system to save and restore processor state. And, it allows the user state to be accessible via predefined instructions as if they were part of a conventional register file. Instructions can be grouped into classes that have similar operands. The behavior or semantics of the instruction are described using a subset of the Verilog HDL. To produce a result the semantic block must simply assign a value to the output-as specified by the instruction's class.

Basically, TIE is easy to write because the description is independent of the pipeline. The semantics of the instruction can be described as if the instruction consisted only of combinational logic. The TIE description can be used with multiple Xtensa implementations since it is pipeline independent. TIE is a very powerful language, a few lines of this code can add significant functionality to the base processor.