5.12. Existing Design Tools for Complex SOC Designs
With all of the available interconnect schemes for multiple-processor architectures, good system-design tools are essential. A variety of existing SOC construction, simulation and analysis design-tool environments support graphical SOC architecture and platform design using a library of standard components including embedded processors, memories, special hardware blocks, and peripherals all linked with familiar, conventional bus topologies. These existing design tools allow system simulation of processor-based SOC designs using instruction-set simulator (ISS) models for processors and SystemC models (or possibly RTL models if high-level models are not available) for other component types.
Existing design tools can also perform some system-level analysis of design characteristics such as bus loading, bus and resource contention, memory-access activity, and processor loading. These tools are most effective when the system architecture is already known, when the major IP blocks have already been chosen, and when only some micro-architectural tuning and detailed verification are required. However, these tools have limited usefulness when the design team wants to explore tradeoffs in task-processor mappings or make informed choices among inter-processor communications alternatives such as buses, ports, and queues.
Virtual system prototyping (VSP) tools can provide some helpful quantitative information about systems designed with more conventional topologies by constructing simulation models of single or multi-processor SOC platforms that execute at speeds at tens of MHz and higher, as opposed to the slower speeds of normal ISSs. VSP tools and models are useful for software developers who want to execute their embedded firmware on models that closely resemble the actual hardware implementation but still provide reasonable simulation performance.
Systems architects who need to test, modify, and characterize the performance of complex applications on a target hardware platform—and who need to run many test scenarios—can also use VSP tools for this purpose as long as the major characteristics of the target hardware platform are fixed. However, none of these existing system-design tools give designers the ability to develop and refine basic SOC architectures, to determine the number and kind of processors needed to achieve system-level performance goals, to design and optimize the on-chip communications architecture (beyond the classical and woefully archaic use of hierarchical buses), to partition their software into multiple tasks mapped onto multiple processors, or to otherwise explore the vast design space that’s available.
In 1997, a group of researchers at Delft University of Technology, Philips Research Laboratories, and another group of researchers affiliated with the POLIS Project—a cooperative project conducted by U.C. Berkeley, Cadence Design Systems, Magneti Marelli, Politecnico di Torino, and several other organizations—independently proposed a conceptual scheme for developing and evaluating architectures called the Y-chart, shown in Figure 5.19. This scheme—also called “function-architecture” co-design—was a method of quantitatively evaluating candidate system architectures through system-level simulation of mapped algorithms (functions or application tasks) on candidate architectures.
Figure 5.19. The Y-chart scheme (function-architecture co-design) for system development employs simulation to quantitatively evaluate algorithms mapped to architectures.
Function-architecture co-design simulations produce performance results (such as number of computation cycles, amount of inter-block communication traffic, maximum required I/O bandwidth, and memory usage) for each candidate architecture. The quantitative data produced by such simulations would help system architects develop and refine optimal architectures for their systems.
An early function-architecture co-design tool, Cadence’s VCC (virtual component co-design) environment, appeared in the late 1990s. This design tool allowed designers to make and verify crucial system-level architectural decisions such as hardware/software system partitioning very early in the system-design cycle. After refining system architectures within VCC, designers could export the hardware/software system design and testbench infrastructure into Mentor Graphics’ Seamless Co-Verification Environment (CVE), which allowed them to perform detailed analyses and reconfirm their system-level design decisions. Even though SOC co-design and co-verification provides a development flow that assures architectural-design correctness before IC implementation, Cadence’s VCC failed to win a critical mass of designers. Today’s commercial electronic system level (ESL) tools do not offer such capabilities.
Cadence’s early attempt at function-architecture co-design failed for many reasons. First, the target hardware architectures developed in the mid- to late-1990s often were based on single, fixed-ISA processors plus custom acceleration blocks. The processor had already been chosen for these systems before serious system design began and no amount of simulation would alter that critical selection. Second, poor availability of adequate processor and IP models at the time was a severely limiting problem. Finally, the lack of any standards for system-level modeling posed a real barrier to the creation of such processor and IP models. As a result of these issues, most system architects weren’t interested in learning a new, proprietary, non-portable system-modeling language that only offered limited capability.
Consequently, there really has been no way to systematically explore a rich space of system-design alternatives. Without advanced tools for quantitatively exploring system architectures, SOC designers have been artificially constrained to a very limited region of the overall design space even though 21st-century silicon can support vastly superior architectural designs. Existing system-design approaches that employed hand-crafted models, processor ISSs, and HDL simulators usually prove adequate to the relatively simple task of developing the simple single-processor architectures that most SOC-design teams produce.
As a result of this self-supporting circle and a lack of powerful system-simulation tools, most SOC designers continue to rely on tried-and-true architectures that employ relatively simple bus hierarchies. These decades-old system architectures fall far short of exploiting the full capabilities of nanometer silicon and leave untouched a substantial amount of performance that could supply SOC developers with a real competitive advantage in the marketplace.
However, we now find a very different milieu for ESL and IP-based design. The IEEE ratified the SystemC (IEEE 1666) standard on December 12, 2005. SystemC has clearly become the industry’s chosen interoperable ESL modeling language for developing complex IP blocks and SoC platforms. System-development tools based on SystemC will inevitably follow ratification of the IEEE 1666 standard.
Methodologies and automated tools for configuring and extending ASIPs (application-specific instruction-set processors) have also begun to emerge. Some of these tools, such as Tensilica’s XPRES compiler for Xtensa processors, can be thought of as a non-classical form of behavioral synthesis. Driven by C/C++ code, automated configuration tools like XPRES can produce a processor description in synthesizable Verilog, which effectively results in a kind of “C-to-gates” transformation that produces firmware-programmable hardware. The behavior of firmware-driven, processor-based blocks can be changed far more easily than hard-wired logic and processors are far more capable of executing an expanded task set if necessary.
If SOC designs continue to be limited to single processors with a few custom-designed hardware acceleration blocks, then existing design tools and methodologies will suffice. However, most SOCs already incorporate at least two processors (a RISC processor for control and a DSP) and state-of-the-art SOCs now harness the concurrent processing power of six, ten, or more processor cores. Some use many more. Existing SOC architectural-design methods and tools are distinctly lacking in support for the emerging MPSOC-design style.