2.4. A Systematic MPSOC Design Flow
Just as an ad-hoc architectural approach to skyscrapers and other large civil structures produces jumbled, inefficient buildings, the ad-hoc approach to system architectures produces inefficient electronic systems for complex applications. Figure 2.10 presents a detailed, systematic flow for efficient MPSOC design. This diagram dovetails with the ASIC design flow shown in Figure 2.2. Instead of corralling the system-design process into one small process box, the MPSOC design flow encapsulates the ASIC implementation flow in one box and details the tasks required to create an overall design that meets system-design goals. Because SOC prototyping is next to impossible, this systematic approach to MPSOC design focuses on extensive system and subsystem simulation, performed early and often. Simulation should start during architectural design, long before any RTL is written.
Figure 2.10. A systematic approach to MPSOC design will produce chips that more closely match the target application. In addition, this approach to system design will significantly reduce the number of problems encountered during design verification and hardware/software integration.
The systematic design approach illustrated in Figure 2.10 starts with the definition of the two essential system attributes: the computational requirements and the I/O interface requirements. These two requirement sets are then combined and used to write a set of abstract task models that define a system. The most likely candidate language for these models is SystemC, now codified as IEEE Standard 1666. Nearly all major EDA tool vendors now offer SystemC simulators.
System-level simulation at such a high abstraction level allows the SOC design team to quickly explore candidate system architectures because these high-level simulations run quickly. High-level simulation results of the abstracted system allow the design team to see, analyze, and understand the critical data flows in each candidate architecture, refine the overall system architecture to balance computational and data-transfer loads, and relieve the inevitable and unforeseen bottlenecks that every complex system seems to have. At this early phase of the MPSOC design, the design team should have selected the best of the candidate architectural designs and should have developed a good “gut feel” for how the system behaves under a variety of typical and worst-case operating conditions.
At this point, the design process splits into two subprocesses:
Optimization of computational tasks by mapping tasks to processors and other hardware blocks.
Optimization of inter-task communications by selecting appropriate interconnection structures (buses, shared memories, FIFO queues, or simple wires).
Because the abstract computation models are already written in SystemC, the systems represented by these abstract models can be readily simulated. Those tasks with low to moderate computational requirements can probably run on fixed-ISA (instruction-set architecture) and pre-configured processor cores without the need for excessive clock rates. Computational tasks with high-performance requirements such as media processing (audio and video) may not comfortably fit on one fixed-ISA processor without requiring that processor to run at wholly unrealistic or unreachable clock rates. SOC processor cores cannot achieve the multi-GHz clock rates of packaged PC processors, nor do most SOC designers wish to deal with the 50–100 W power dissipation that accompanies such clock rates.