4.1. Processor Generation
To start the process of developing an enhanced processor core, the developer profiles target code by compiling it and identifying critical loops with a profiler. Then, instead of recoding these critical loops in assembly language, the developer describes new data types, new registers and register files, and new machine instructions that better fit the needs of the target application’s algorithms. Figure 4.1 shows the tool flow for developing an enhanced Xtensa processor core.
Figure 4.1. A simple tool flow allows SOC designers to quickly tailor an Xtensa microprocessor core for a specific application.
The processor-development process starts with the compilation of the available application code using a compiler built for a base Xtensa processor ISA. Code profiling then reveals the expected performance from the base processor architecture and identifies hot spots in the code that should be scrutinized for acceleration. So far, this process is no different than code profiling for the purpose of improving code through selective recoding of critical routines in assembly language.
However, the process of processor optimization replaces assembly-language programming with processor configuration and extension. In this phase, the developer reconfigures the processor and develops register and instruction extensions that accelerate code performance. This optimization step produces a set of configuration selections and specifications for application-specific extensions to the Xtensa ISA.
Configuration options include selections such as the presence or absence of instruction and data caches, the size of the caches, the width of the processor’s external buses, the size of the processor’s general-purpose register file, inclusion of a multiplier or multiplier/accumulator, the number of interrupts, the number of load/store units, etc. Figure 4.2 shows the processor block diagram for the Xtensa family. Nearly every part of the processor is configurable. This configurability allows the processor to be sized appropriately for every application on the SOC.
Figure 4.2. The Xtensa configurable processor core includes a large number of optional and configurable blocks so that the core can be precisely tailored and performance-tuned for a wide range of on-chip tasks.
Application-specific extensions for the Xtensa processor are described in the TIE (Tensilica Instruction Extension) language. The TIE language can describe new instructions, new registers and register files of any size, and new ports of any width (limited to 1024 bits per port) into and out of the processor. TIE’s syntax closely resembles Verilog with one major difference. Because the processor’s structure is completely under the control of the Xtensa Processor Generator (XPG), TIE specifications describe only function, not structure.
The XPG uses the functional descriptions written in TIE to add hardware components to the base Xtensa ISA. These hardware components reside in the Xtensa processor database that is part of the XPG. Because the XPG automatically generates and verifies the HDL (hardware description language) description of the new processor core (base processor ISA + configuration options + extensions), the resulting HDL processor description is guaranteed to be correct by construction. This guarantee is only possible because TIE creates a large, safe sandbox in which to develop and tune application-specific instruction-set processors (ASIPs).
The XPG simultaneously produces two sets of files. First, it generates the RTL description of the extended processor along with a SystemC model of the extended processor (for system-level simulation) and synthesis scripts to ease the flow of the processor description through logic synthesis. Second, the XPG generates a software-development tool suite including the compiler, assembler, debugger, profiler, instruction-set simulator (ISS), etc. All of the tools in the generated tool suite have been augmented so that they understand the extensions made to the base Xtensa ISA.
Processor generation by the XPG runs very quickly. It takes about an hour. After the XPG completes its work, the generated compiler, profiler, and ISS can be used to compile and run the target code to determine how much performance improvement the new processor extensions deliver.
If the performance goals have been met, no further processor enhancement is needed. If more performance is needed, it takes only an hour or so to build another processor. As a result of the XPG’s rapid turnaround time, several candidate processor architectures can be built and profiled in a normal working day. This radically different approach to architectural and design-space exploration greatly accelerates SOC design.