1.14. A Closer Look at 21st-Century Processor Cores for SOC Design
Microprocessor cores used for SOC design are the direct descendents of Intel’s original 4004 microprocessor. They are all software-driven, stored-program machines with bus interconnections. Just as packaged microprocessor ICs vary widely in their attributes, so do microprocessors packaged as IP cores. Microprocessor cores vary in architecture, word width, performance characteristics, number and width of buses, cache interfaces, local memory interfaces, and so on. Early on, when transistors were somewhat scarce, many SOC designers used 8-bit microprocessor cores to save silicon real estate. In the 21st century however, some high-performance 32-bit RISC microprocessor cores consume less than 0.5 mm2 of silicon, so there’s no longer much reason to stay with lower performance processors. Indeed, the vast majority of SOC designers now use 32-bit processor cores.
In addition, microprocessor cores available as IP have become specialized just like their packaged IC brethren. Thus you’ll find 32-bit, general-purpose processor cores and DSP cores. Some vendors offer other sorts of very specialized microprocessor IP such as security and encryption processors, media processors, and network processors. This architectural diversity is accompanied by substantial variation in software-development tools, which greatly complicates the lives of developers on SOC firmware-development teams.
The reason for this complication is largely historic. As microprocessors evolved, a parallel evolution in software-development tools also occurred. A split between the processor developers and tool developers opened and grew. Processor developers preferred to focus on hardware architectural advances and tool developers focused on compiler advancements. Processor developers would labor to produce the next great processor architecture and, after the processor was introduced, software-tool developers would find ways to exploit the new architectural hardware to produce more efficient compilers.
In one way, this split was very good for the industry. It put a larger number of people to work on the parallel problems of processor architecture and compiler efficiency. As a result, it’s likely that microprocessors and software tools evolved more quickly than if the developments had remained more closely linked.
However, this split has also produced a particular style of system design that is now limiting the industry’s ability to design advanced systems. SOC designers compare and select processor cores the way they previously compared and selected packaged microprocessor ICs. They look at classic, time-proven figures of merit such as clock rate, main-bus bandwidth, cache-memory performance attributes, and the number of available third-party software-development tools to compare and select processors. Once a processor has been selected, the SOC development team then chooses the best compiler for that processor, based on other figures of merit. Often, the most familiar compiler is the winner because learning a new software-development tool suite consumes precious time more economically spent on actual development work.
If the SOC requires more than one processor, it’s often because there’s specialized processing to be done. In the vast majority of such cases, there is some sort of signal or image processing to be performed and a general-purpose processor isn’t an efficient choice for such work. Usually, this situation leads to another processor selection, this time for a DSP and an associated software-development tool suite.
The big problem with this selection method is that it assumes that the laws of the microprocessor universe have remained unchanged for decades. This assumption is most definitely flawed in the 21st century. Processor cores for SOC designs can be far more plastic than packaged microprocessor ICs for board-level system designs. Shaping these processor cores for specific applications produces much better processor efficiency and much lower system clock rates. In short, using the full abilities of microprocessor core IP to more closely fit the application problems produces better system designs.
Certainly, many microprocessor cores are not at all plastic. They lack configurability. However, a relatively new class of microprocessor core, the configurable microprocessor, exploits the plastic nature of the SOC’s underlying silicon to permit the creation of processors that perform much better in SOC designs than older microprocessor cores, which are based on processor architectures that were originally developed to fit into DIPs and thus inherit some of the limitations placed on packaged microprocessor ICs.
Tensilica’s Xtensa processor family is an example of such a configurable core. The Xtensa architecture was specifically designed for SOC use. It was designed to fully exploit the plastic nature of nanometer silicon. The original Xtensa processors were available as fully configurable processor cores. These processor cores have now been joined by a family of preconfigured microprocessor cores called the Diamond Standard Series, which is based on and compatible with Xtensa processors. Members of the Diamond Standard Series of processor cores have already been tailored for specific SOC applications and are not further configurable.
Together, the Xtensa and Diamond processor cores constitute a family of software-compatible microprocessors covering an extremely wide performance range from simple control processors, to DSPs, to 3-way superscalar processors. The configurability of Xtensa processors allows the performance range to grow even further, to the limits supported by the underlying silicon. Yet all of these processors use the same software-development tools so that programmers familiar with one processor in the family can easily switch to another.
As a consequence of this microprocessor core family’s wide performance range, it’s entirely possible to develop entire SOCs using only Xtensa and Diamond microprocessor cores, barring issues of legacy software. In fact many SOCs have already been designed in just this manner. The benefit of this system-design approach is that it boosts both hardware- and firmware-development productivity in a way that cannot be approached when using old system-design methods that employ different processor architectures for different tasks on the SOC—and therefore different processor-interface schemes and different software-development tools.
This book emphasizes a processor-centric MPSOC design style shaped by the realities of the 21st-century and nanometer silicon. It advocates the assignment of tasks to firmware-controlled processors whenever possible to maximize SOC flexibility, cut power dissipation, reduce the size and number of hand-built logic blocks, shrink the associated hardware-verification effort, and minimize the overall design risk. The design examples in this book employ members of the Xtensa and Diamond Standard processor families because of the extremely broad performance range and extended I/O abilities that these processor cores offer as a group. The advanced SOC design styles discussed in this book can be used with other microprocessor cores to create MPSOCs, but it will be more difficult to achieve the same results.