SoC drawer: The resource view Page 1 of 9 SoC drawer: The resource view Resource allocation can determine system architecture Sam Siewert ( [email protected] ), Adjunct Professor, University of Colorado Summary: A system-on-a-chip (SoC) can provide a single-chip solution, lower power usage, better performance, more frugal use of board real estate, simpler integration, and lower part counts. Compared to multichip solutions, the SoC has huge advantages, but mistakes in sizing on-chip resources require spinning the ASIC and result in high cost. This article introduces approaches for SoC design from a resource perspective. The SoC design concept has appeal in a broad range of computing applications, from supercomputing to embedded systems. Date: 04 Oct 2005 Level: Intermediate Activity: 895 views Comments: 0 ( Add comments ) Average rating (based on 15 votes) This article is the first in the SoC drawer series. The series aims to provide the system architect with a starting point and some tips to make system-on-a-chip (SoC) design easier. The goal for an SoC is typically a single-chip solution; therefore, properly sizing memory, I/O, and central processing unit (CPU) resources from the outset is critical. By comparison, multichip solutions often include approaches for resource sizing risk mitigation. For example, memory controllers for external memory devices can support a range of parts and sizes. You can also add coprocessors to multichip solutions as well. Resource enhancement always has associated cost, but for SoCs, the cost is higher. This first article provides an overview of design from a resource perspective; subsequent articles will drill down and focus on specific methods to support this resource approach. The SoC drawer series is intended to arm the architect with tools and methods to get resource sizing right. The emergence of SoC design and SoC-based architectures What is an SoC? For the purposes of this series, I consider an ASIC to be in this category if it includes CPU, memory, I/O, and an interconnection between the three. As Wikipedia notes, "System-on-a-chip ... is an idea of integrating all components of a computer system into a single chip." The SoC has been talked about, marketed, and accepted in the new millennium, especially for embedded applications. More recently, with announcements of high-performance SoC designs such as the Cell chip, and use of these chips in consumer products including the Sony PlayStation 3 (PS3) and Microsoft® XBox, it has become clear that SoC designs will have broad impact. (For more information, see the press on the Cell architecture this year in the Resources section below.) The initial use of SoC design has been focused on reducing part count for embedded applications and tightening the integration of processing, memory, and I/O resources with lower overall power consumption and a smaller footprint. Along with IBM, Sony, and Toshiba's unveiling of the Cell chip for the PS3, described in detail at ISSCC this past February, other major announcements have shown that SoC design has become a pervasive underpinning of many architecture roadmaps for the future. For example, IBM has also prototyped a blade server using Cell chips, though Cell experts like Arnd Bergmann say that Cell -like architectures will remain in the embedded and supercomputing application http://www.ibm.com/developerworks/power/library/pa -soc1/index.html 4/25/2009 SoC drawer: The resource view Page 2 of 9 domains and won't likely show up on home or office desktops. (See Resources for an interview with Bergmann.) What is really exciting about SoC architecture is that supercomputing and embedded computing may become the cutting edge of computer architecture. For supercomputing this is nothing new, but embedded systems have often followed rather than led architecture. SoC architecture brings embedded and supercomputing closer together The IBM Blue Gene®/W and Blue Gene/L recently put the U.S. back in the lead in supercomputing, ahead of the the Japanese Earth Simulator, built by NEC and heralded as the fastest in 2002. Each Blue Gene node is best described as an SoC, given the integration of processing, cache, and interconnection networks with routing in a single ASIC. Similarly, by the definition of an SoC, the recently unveiled Cell chip embedded in the PS3 could even be considered a multiSoC ASIC. Each Cell Synergistic Processing Element (SPE) in fact integrates 256KB of load/store memory, processing, direct memory access (DMA), memory management unit (MMU), and bus interface, with 8 SPEs in all integrated with the Power Architecture™ technology-based Peripheral Processing Element (PPE) in a single ASIC. Any architect involved in embedded or supercomputing is most likely already working with SoC designs or will be soon. While SoC design might not presently be well suited to general-purpose computing (GPC), the roadmap for the future of GPC also holds multiprocessor designs on a single chip, and therefore includes aspects of SoC design. Given the reconfigurability, broad range of I/O devices, and whims of the GPC market, it's unlikely that general-purpose computers themselves will be designed as SoCs, but clearly they will contain chips and chipsets that are SoCs. It's not too risky to predict that most ASICs will be SoCs at some point, and that the SoC is a natural stage in the evolution of higher and higher integration. The degree of SoC-ness in a design is based upon the ability to stand alone and to provide services without requiring support from external chipsets like external memory devices. Figure 1. System software and firmware view: The resource cube Figure 1 depicts the challenge facing firmware and software engineers implementing software services on an SoC (or any system, for that matter). The origin and volume inside the green subspace defines a resource-rich situation where problems are easily solved with cycles, bandwidth, and megabytes. The red subspace within the resource cube defines a resource-constrained situation where significant effort will be required to tune the system in order to meet timing and throughput requirements for services. The resource cube does not include additional dimensions (resources) such as power, pin count, layout space, or cost. It only portrays the firmware/software view, given that trade-offs have already been made in the hardware resource space to define these three basic software resources. http://www.ibm.com/developerworks/power/library/pa -soc1/index.html 4/25/2009 SoC drawer: The resource view Page 3 of 9 Research on SoC architectures has led to interesting emergent software and hardware management concepts like dynamic voltage scaling, where software can modulate CPU clock rate and power consumption based upon current computational needs. Likewise, hardware might modulate the CPU to control heating and notify the software layer that the clock rate has been reduced to handle the overheating. SoC design might be expanding the hardware and software interface, but the hardware design decisions defining this space are still not a bad place to begin high-level architectural definition. This introductory article looks at some basic hardware and software decisions that affect processing, memory, and I/O. Future articles drill into individual aspects of the decision-making process and consider hardware and software trade-offs for a given SoC architectural design decision. In general, all computers provide services, which can range from embedded services like digital control, to supercomputing services like sequencing DNA. Processing is perhaps the most carefully analyzed resource in most systems. Processing resources and scheduling How compute nodes or CPUs are scheduled depends upon the hardware architecture and service requirements. Figure 2 provides a taxonomy of scheduling methods for processing resources. It's not fully exhaustive, but is fairly complete. Figure 2. CPU scheduling taxonomy SoC processors can host resource-management services Since the 1970s, real-time systems have included the concept of an admission policy for services (threads), where a new thread's service requirements are analyzed relative to existing services to determine if the new service will cause the existing service to miss deadlines. Traditionally, this has been done offline, but a dedicated processing resource could execute a rate monotonic feasibility test online in an SoC design. Dynamic service admission is a difficult problem to solve on a single CPU or non-SMT (symmetric multithreading) processor, since the test itself interferes with running services. http://www.ibm.com/developerworks/power/library/pa -soc1/index.html 4/25/2009 SoC drawer: The resource view Page 4 of 9 Some of these CPU scheduling taxonomy methods are mostly of historic interest, such as mainframe batch policies like Shortest Job Next (SJN). Methods such as asymmetric off-loading and dynamic Least Laxity First (LLF) or Earliest Deadline First (EDF) are, however, of great interest to modern SoC services for media applications, including video, audio, and game engines. Describing them all is far beyond the scope of this article, but this taxonomy provides a context for future articles discussing methods currently applied to SoC design. As already noted, SoC design tends to blur traditional hardware and software interface lines, so an SoC architect might want to consider hardware-supported scheduling for a policy such as EDF. In EDF, the thread with the earliest deadline is executed until a thread enters the system with an even earlier deadline. This policy is often used for soft real-time services like real-time rendering. Recently, symmetric multithreading (SMT) has emerged to provide hardware support for multiple threads of execution. Understanding scheduling policies and mechanisms is critical for the SoC architect. The simple CPU resource utilization equations below are a starting point for analysis of processing resources. For systems that have requirements to provide services without real-time deadlines, called best effort, Equation 1 provides an estimate of processing demands for a set of periodic service requests.