2.3. The ad-hoc SOC Design Flow
The absence of a well-accepted, industry-standard SOC design flow has produced numerous ad-hoc approaches. The first step in one very popular approach is to design a simple microprocessor system like the one shown in Figure 2.3. This system closely resembles every simple microprocessor-based system designed since the Intel 4004 microprocessor became available in 1971.
Figure 2.3. This generic, microprocessor-based system is representative of many system designs. It is so successful because of the microprocessor’s inherent flexibility, not because this system-design matches the actual needs of a system.
The design of the microprocessor-based system shown in Figure 2.3 is quite generic. It merely connects the processor to memory and peripherals. If this simple system design happens to also meet the needs of the target system, it’s purely serendipitous. However, if this simple design is sufficient, then the system design is finished. Most likely, if this simple design meets the needs of the overall system, then a standard, off-the-shelf microcontroller would likely serve the system design just as well, for a lot less money.
In fact, the ad-hoc system-design style that produces generic systems such as the one shown in Figure 2.3 routinely produces ASSPs (application-specific standard products) such as the OMAP (Open Media Applications Platform) chips from Texas Instruments. The block diagram of the OMAP chip in Figure 2.4 shows a 2-processor system with a shared DMA controller, a shared-memory controller, and a collection of peripheral blocks. Study the block diagram alone and you will not discern the OMAP chip’s intended function.
Figure 2.4. This OMAP chip from Texas Instruments epitomizes the ad-hoc approach to system design, which produces a generic platform chip. Firmware gives the chip a specific function.
The OMAP chip’s system design doesn’t at all resemble the actual application problem’s block diagram. Firmware must perform the transformation from generic to specific. As a system’s performance goals expand, it becomes increasingly difficult for firmware to transform generic hardware into a high-performance system.
The OMAP chip demonstrates two additional “rules” of the ad-hoc approach to system design:
If one processor lacks sufficient processing power, add another.
If another processor won’t do, add an application accelerator hardware block.
The OMAP chip uses both of these approaches. The general-purpose control processor is not adequately efficient for signal processing, so the OMAP chip adds a DSP (digital signal processor) core to the mix. The chip also has a DMA control block that performs data movement to offload this task from either of the two on-chip processor cores because neither processor can move data as efficiently as a DMA controller.
The two processors and the DMA controller all communicate with most of the other system blocks on the chip, which makes the design generic and therefore less than optimal for any specific application because the likelihood of resource conflict is very high, especially on buses shared by the two processors and the DMA controller.
There is nothing wrong with using multiple processors and hardware accelerators to improve an SOC’s performance, but an ad-hoc approach to combining these system components is not likely to provide an optimal design because of unnecessary shared-resource conflicts. In fact, the ad-hoc design approach often produces a design that fails to meet system-performance goals because of these shortcomings.
For examples of system architectures directly derived from the problem being solved, see Figures 2.5–2.8. These figures show, respectively, a HiperLAN/2 decoder, a UMTS decoder, a Mondiale digital radio decoder, and an H.264 digital video decoder. Each of these four block diagrams shows a variety of different tasks to be performed and the expected bit rates required of the communications paths linking these tasks. This detailed level of understanding helps the system designer create successful, efficient SOCs.
None of the decoder systems shown in these four block diagrams looks remotely like a microprocessor-based system. All four of the systems shown in Figures 2.5–2.8 consist of a series of blocks communicating with each other over point-to-point connections defined by the overall application and the various tasks to be performed, not by the underlying implementation technology.
Systems that perform digital decoding and encoding, encryption and decryption, and other data-transformation algorithms are optimally organized or configured when the system block diagram matches the problem at hand. It is our familiarity with 30 years of microprocessor-based system design that starts us thinking along the lines of force-fitting task-specific architectural structures to traditional, bus-based microprocessor systems.
For example, look at Figure 2.9, which shows the mapping of a set-top box system design into a traditional bus-based microprocessor system as it appeared in Chapter 4 of the book Surviving the SOC Revolution: A Guide to Platform-Based Design. After 30 years of microprocessor-based system-design experience, SOC designers simply take such re-mappings for granted. They’re usually not even consciously aware that remapping has occurred. However, such mappings are not the only way to design SOCs. In many cases, these mappings no longer represent the best way to develop 21st-century system architectures. In the system shown in Figure 2.9, for example, all communications in the system must traverse the main system bus to reach any of the system’s computational blocks. This requirement immediately forces the bus to become a critical shared resource that can easily be overwhelmed in high-performance operating modes.
Figure 2.9. This system remapping of a set-top box appeared in Chapter 4 the book Surviving the SOC Revolution: A Guide to Platform-Based Design, which was published in 1999. This system-design style no longer represents an optimal approach to SOC design in the 21st-century.
After many decades of microprocessor design experience, we have become so acclimated to treating processors as scarce system resources that we automatically try to minimize the number of processors without sufficient engineering analysis of processor and bus loading. If it’s discovered well into the design project that the processor has too much work to perform in the allotted time, a higher clock rate is often the most expedient remedy sought although the cure may require use of a more expensive IC process technology and it will likely incur higher—perhaps even unacceptable—power-dissipation levels.
Too often, we blindly accept the inefficiencies that result from using outdated system-design styles to force-fit task-oriented systems into hierarchical, bus-oriented hardware architectures that bear no structural resemblance to the problems being tackled. The inefficiencies of generic microprocessor-based architectures have become camouflaged through their extreme familiarity; they simply blend into today’s system-design landscape.
The ceaseless advance of Moore’s Law, the advent of nanometer silicon, and the appearance of mega-gate SOCs make on-chip processors far more available so that the “processor-as-scarce-resource” mentality is now thoroughly outdated. Today’s silicon supports and encompasses a broader and richer universe of practical system designs that meet performance goals while running at lower clock rates and with lower power requirements. Companies designing SOCs must change their system-design styles to accommodate this shift and to stay competitive.