System on Chip Interfaces for Low Power Design

Sanjeeb Mishra, Neeraj Kumar Singh, Vijayakrishnan Rousseau

• Publisher: Morgan Kaufmann
• Year: 2015
• ISBN:
  9780128017906
• Topic: Computer Science
• Subtopic: Hardware
• Index: Computer Science

System on Chip Interfaces for Low Power Design provides a top-down understanding of interfaces available to SoC developers, not only the underlying protocols and architecture of each, but also how they interact and the tradeoffs involved. The book offers a common context to help understand the variety of available interfaces and make sense of technology from different vendors aligned with multiple standards. With particular emphasis on power as a factor, the authors explain how each interface performs in various usage scenarios and discuss their advantages and disadvantages. Readers learn to make educated decisions on what interfaces to use when designing systems and gain insight for innovating new/custom interfaces for a subsystem and their potential impact.

• Provides a top-down guide to SoC interfaces for memory, multimedia, sensors, display, and communication
• Explores the underlying protocols and architecture of each interface with multiple examples
• Guides through competing standards and explains how different interfaces might interact or interfere with each other
• Explains challenges in system design, validation, debugging and their impact on development

Chapter 1

SoC Design Fundamentals and Evolution

Abstract

This chapter discusses various system design integration methodologies along with their advantages and disadvantages. The chapter also explains the motivation for current system designs to move from “system on board” designs toward “system on chip” (SoC) designs. In discussing the motivation for the move toward SoC design, the chapter also discusses the typical chip design flow tradeoffs as well as how they influence the design choices.

Keywords

SoC design

Hardware software co-design

System on board

System on chip

System in a package

ASIC

System on programmable chip

VLSI

Moore’s law

Chip design

This chapter discusses various system design integration methodologies along with their advantages and disadvantages. The chapter also explains the motivation for current system designs to move from “system on board” designs toward “system on chip” (SoC) designs. In discussing the motivation for the move toward SoC design, the chapter also discusses the typical chip design flow tradeoffs as well as how they influence the design choices.

Introduction

A system is something that achieves a meaningful purpose. Like everything else, it depends on the context. A computer system will have hardware components (the actual machinery) and software components, which actually drive the hardware to achieve the purpose. For example, talking about a personal computer (also commonly known as a PC), all the electronics are hardware, and the operating system plus additional applications that you use are software.

However, in the context of this book, by a system we mean the hardware part of the system alone. Figure 1.1 shows a rough block diagram of a system. The system in the diagram consists of a processing unit along with the input/output devices, memory, and storage components.

■ Figure 1.1 A system with memory, processor, input/output, and interconnects.

Typical system components

Roughly speaking, a typical system would have a processor to do the real processing, a memory component to store the data and code, some kind of input system to receive input, and a unit for output. In addition, we should have an interconnection network to connect the various components together so that they work in a coherent manner. It should be noted that based on the usage model and applicability of the system, the various components in the system may come in differing formats. For example, in a PC environment, keyboard, and mouse may form the input subsystem, whereas in a tablet system they may be replaced by a touch screen, and in a digital health monitoring system the input system may be formed by a group of sensors. In addition to the bare essentials, there may be other subsystems like imaging, audio, and communication. In Chapter 3 we’ll talk about various subsystems in general, involving:

1. Processor

2. Memory

3. Input and output

4. Interconnects

5. Domain-specific subsystems (camera, audio, communication, and so on)

Categorization of computer systems

Computer systems are broadly categorized as: general-purpose computer systems like personal computers, embedded systems like temperature control systems, and real-time systems like braking control systems. General-purpose computing systems are designed to be more flexible so that they can be used for different types of functions, whereas embedded systems are designed to address a specific function and are not meant to be generic. They are usually embedded as part of a larger device, and the user seldom directly interacts with such a system. Real-time systems are embedded systems with stringent response time requirements. All these computing systems are built using the same basic building blocks as shown in Figure 1.1. The flavor of the building blocks may vary from system to system because the design parameters and design requirements are different. For example, since embedded systems have a fixed known usage, the components can optimally be chosen to meet that functional requirement. The general-purpose system, on the other hand, might have to support a range of functionality and workloads, and therefore components need to be chosen keeping in mind the cost and user experience for the range of applications. Similarly the components for real-time systems need to be chosen such that they can meet the response time requirement.

System Approach to Design

Due to the tighter budget on cost, power, and performance discussed in the previous section, the whole system is being thought about and designed as complete and not as an assembly of discrete pieces. The philosophy of system design thereby brings the opportunity to optimize the system for a particular usage. There is no real change in the system functionality; it’s just that it is a different way of thinking about the system design. We already talked about the typical system components; next we will discuss the hardware software co-design, followed by various system design methodologies.

Hardware software co-design

As discussed earlier, a system in general has some hardware accompanied by some software to achieve the purpose. Generally, the system’s functionality as a whole is specified by the bare definition of the system. However, what part of the system should be dedicated hardware and what should be software is a decision made by the system architect and designer. The process of looking at the system as a whole and making decisions as to what becomes hardware and what becomes a software component is called hardware software co-design. Typically there are three factors that influence the decision:

■ Input, output, memory, and interconnects need to have hardware (electronics) to do the fundamental part expected from them. However, each of these blocks typically requires some processing; for example, touch data received from the input block needs to be processed to detect gestures, or the output data needs to be formatted specifically to suit the display. These processing parts, generally speaking, are part of the debate as to whether a dedicated hardware piece should do the processing or whether the general-purpose processor should be able to take care of the processing in part or full.

■ The second factor that contributes to the decision is the experience that we want to deliver to the user. What this means is that, depending on the amount of data that needs to be processed, the quality of the output that is expected, the response time to the input, and so on, we have to decide the quality of the dedicated hardware that should be used, and also this helps make the decision as to which processing should be done by dedicated hardware and which by software running on the CPU. The assumption here is that hardware dedicated to doing specific processing will be faster and more efficient, so wherever we need faster processing, we dedicate hardware to do the processing, such as, for example, graphics processing being processed by a graphics processing unit.

■ The third factor is the optimality. There are certain types of processing that take a lot more time and energy when done by general-purpose processing units as opposed to a specialized custom processor, such as digital signal processing and floating point computations, which have dedicated hardware (DSP unit and floating point unit, respectively) because they are optimally done in hardware.

System design methodologies

Early on, the scale of integration was low, and therefore to create a system it was necessary to put multiple chips, or integrated circuits (ICs), together. Today, with very-large-scale integration (VLSI), designing a system on a single chip is possible. So, just like any other stream, system design has evolved based on the technological possibilities of the generation. Despite the fact that system on a single chip is possible, however, there is no one design that fits all. In certain cases the design is so complex that it may not fit on a single chip. Why? Based on the transistor size (which is limited by the process technology) and size of the die (again limited by the process technology) there is a limited number of transistors that can be placed on a chip. If the functionality is complex and cannot be implemented in that limited number of transistors, the design has to be broken out into multiple chips. Also, there are other scalability and modularity reasons for not designing the whole system in one single chip. In the following section we’ll discuss the three major system design approach...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Copyright Permissions
• Dedication
• Acknowledgments
• Chapter 1: SoC Design Fundamentals and Evolution
• Chapter 2: Understanding Power Consumption Fundamentals
• Chapter 3: Generic SoC Architecture Components
• Chapter 4: Display Interfaces
• Chapter 5: Multimedia Interfaces
• Chapter 6: Communication Interfaces
• Chapter 7: Memory Interfaces
• Chapter 8: Security Interfaces
• Chapter 9: Power Interfaces
• Chapter 10: Sensor Interfaces
• Chapter 11: Input Device Interfaces
• Chapter 12: Debug Interfaces
• Appendix A: Overview of Intel SoC: Baytrail
• Appendix B: Industry Consortiums
• Appendix C: USB 3.0
• Appendix D: USB OTG (On The Go)
• References
• Index