Project topics and materials
Get Complete Project Material File(s) Now! »
A SoC example for LTE implementation
Industrial solutions for the embedded application reflect the application complexity.
Furthermore, heterogeneous multi-core SoC platforms are generally believed to meet the above mentioned conflicting performance, flexibility and energy efficiency requirements of demanding embedded applications. The heterogeneity of SoC implementations is driven by the heterogeneity of the embedded applications, where each part of the application has an inherent suitable implementation technology. Figure 2.3 depicts the architecture of a DSP SoC, MSC8156 [73], produced by Freescale Semiconductor [72], that targets among others the wireless broadband domain. This DSP is currently used in industrial implementations of the base stations of the LTE standard developped by companies like Alcatel. This SoC has been used to test and validate the methodology developed in this thesis. More details on its modeling and performance estimation of the implementation of the LTE physical layer are provided in Chapter 7.
The MSC8156 DSP delivers a high level of performance and integration. It combines together six DSP cores, each running at up to 1 GHz, a hardware accelerator (maple-B) that supports hardware acceleration for Turbo [55] and Viterbi [81] channel decoding, in addition to DFT/iDFT and FFT/iFFT algorithms (these algorithms require high computation performances). It includes as well a high-performance internal RISC-based (QUICC Engine) subsystem that supports multiple networking protocols to guarantee reliable data transport over packet networks.
The MSC8156 embeds an on-chip memory (M3) of 1 MByte, and two interfaces for off-chip DDR memories. In addition, each DSP core has its own internal L1 and L2 caches. It supports a variety of advanced, high-speed interface types, including two “RapidIO” interfaces, two Gigabit Ethernet interfaces for network communications, a PCI Express controller, two DDR controllers for high-speed industry standard memory interface. The set of all these integrated components are connected through a Chip- Level Arbitration and Switching Fabric (the CLASS), that ensures non-blocking, fully pipelined and low latency communication scenarios. The system is doted as well by DMA blocks to transfer the large quantity of processed data. To have an idea on the data transfer performed and the complexity of the data processing, recall that this system is used to implement a part of the LTE standard, and it guarantees throughput of more than 100 Mbps.
System on Chip Design Complexity
A System on Chip (SoC), like the one presented in the previous section, integrates software and hardware jointly and is specifically designed to provide given functionalities to the surrounding environment [40], [53]. The system must be able to continuously react to stimuli in the desired way, i.e., within bounds on timing, power consumption, and cost. As introduced in the previous sections, such systems are highly complex and heterogeneous. In fact, the complexity of system design is dramatically increasing in three dimensions:
1. Heterogeneity and complexity of the hardware architecture: New design technologies and higher integration density result in increasing the computational power of modern SoCs which enables sophisticated functions to be embedded in ever-smaller devices. A modern SoC may include general purpose processors (GPP), Application-Specific Instruction-set Processors (ASIP), different communication topologies, complex memory hierarchy, different Input/Output devices … The Freescale DSP MSC8156 presented in section 2.3 is a good example of such architecture.
2. Heterogeneity and complexity of the embedded software: As the computational power of SoCs grows, more advanced functionalities are introduced. Software is taking the lion’s share of the implementation budgets and cost. For instance, in a cell phone, more than one million lines of code are the standard today [69]. In contrast with traditional software systems where the abstraction process leaves out all the physical aspects of the systems as only the functional aspects of the code matter, the embedded software is at least loosely coupled to the hardware architecture which limits the code reuse when the system specifications evolve. Furthermore, heterogeneous applications share the same hardware architecture:
a cell phone device must be able to handle simultaneous voice and data calls, while also handling complex imaging tasks like image or video capture. This heterogeneity increases the complexity of resource sharing and design optimization.
3. Integration complexity: During the integration phase, software and hardware components are integrated to create the SoC. As these components are usually developed by different teams and sometimes in different countries (and/or by different companies), this phase is of extreme complexity [41]. Verification and re-engineering work done during this phase is time consuming and expensive.
System on Chip design flow
A System-on-Chip design is an iterative process, that aims the implementation of a product based on the client specifications. A System-on-Chip design flow is a succession of refinements and optimizations steps to accomplish the system design. Each step of the flow consists of modeling and/or implementation, verification and integration of hardware and software. The ideal design starts with a high level description of the functionality and the architecture. The designer is expecting for the following from SoC design flow:
1. Reuse of the existing code and models developed for previous products to fasten the design cycle. One should note that usually new products are an evolution of existing product and rarely a revolution. Hence, design reuse can lead for considerable cost reducing factor.
2. Identify design decisions early in the design flow. Late design changes are expensive and time consuming, thus finding the bottlenecks and estimating the system’s performances at early stages reduce the design’s cost and increase the productivity.
3. Ensure a functioning product, that satisfies the client requirements. Thus, the adopted verification and validation process should be correct and accurate in order to lead to a correct product.
The design specification at each design step must cover the specification of the functionality and the architecture of the system. Currently, there is no standard language or format for design specification. In addition to specification, each level of the SoC design flow should define verification and validation methodologies to verify the satisfaction of the design with the requirements.
Table of contents :
Contents
List of Figures
1 Introduction
1.1 Thesis Context
1.2 Thesis Contributions
1.3 Thesis Layout
2 System-on-Chip Design and Application Domains
2.1 Introduction
2.2 LTE Standard for Mobile Communication: Higher Complexity for better quality of services
2.3 A SoC example for LTE implementation
2.4 System on Chip Design Complexity
2.5 System on Chip design flow
2.5.1 SoC Design flow steps
2.5.2 System Level Design
2.5.3 Virtual prototyping
2.5.4 Prototyping
2.6 Summary
3 System Level Design: Models, Methodologies and Trends
3.1 Introduction
3.2 System Level Design: Concepts and Objectives
3.2.1 Modeling and abstraction
3.2.2 Separation of concerns
3.2.3 Design Space Exploration
3.3 System Level Specification Languages
3.3.1 C/C++ based design languages
3.3.2 Synchronous Languages
3.3.3 UML: Unified Modeling Language
3.3.4 Matlab/Simulink
3.3.5 Discussion
3.4 Survey of some Existing System Level Design Methodologies
3.5 DIPLODOCUS and Extensions: Yet Another System Level Design Methodology for Early Design Analysis
3.5.1 Modeling Approach
3.5.2 UML for SoC Modeling
3.5.3 Shared Resources Contentions Modeling
3.5.4 Communication Modeling
3.6 Summary
4 Architecture and Application Modeling
4.1 UML the Unified Modeling Language: Models, Metamodels and Profiles
4.2 Application Modeling
4.2.1 Application Structure Task Model
4.2.2 Application Structure Component Model
4.2.3 Application Behavior Model
4.3 Architecture Modeling
4.3.1 Architecture Resources Model
4.3.2 Architecture Communication Interaction Model: “Communication Patterns”
4.4 Summary
5 System Mapping Modeling
5.1 Mapping motivational example
5.2 Shared Resources Modeling
5.2.1 Resource definition
5.2.2 Shared Resources’ Control: The “Virtual Node”
5.2.3 Virtual Node vs Real Implementation
5.3 Execution Allocation
5.4 Storage Allocation
5.5 Communication Management Modeling
5.6 Mapping Validation
5.7 Mapping overall scenario
5.8 System Mapping Example
5.9 Summary
6 Models Simulation for Performance Analysis
6.1 Introduction
6.2 State of the Art on SystemC
6.2.1 System’s Design in SystemC
6.2.2 Concurrency
6.2.3 SystemC Simulation Kernel
6.3 A SystemC Simulation Environment for DIPLODOCUS models
6.3.1 DIPLODOCUS SystemC simulator concurrency
6.3.2 System’s Timing: From DIPLODOCUS commands to physical time
6.3.3 Simulation’s Timing semantics and Interruptions Support
6.3.4 The simulator in a nutshell
6.4 Performance Monitoring
6.4.1 Simulator Default monitoring
6.4.2 Personalized Performance Metrics: Observers
6.5 Summary
7 Use Case Study: SoC Modeling for LTE Base Station
7.1 LTE: The Long Term Evolution Standard
7.1.1 Overall LTE Network Architecture
7.1.2 Key Technologies of the 3GPP LTE Air Interface
7.1.3 LTE Radio Link Protocol Layers
7.2 Use Case Modeling
7.2.1 Scope of the use case
7.2.2 Application Model: LTE Physical Layer
7.2.3 Architecture Model: Freescale MSC8156 Multi-Core DSP
7.2.4 Mapping Model
7.3 Use case analysis
7.3.1 Application Execution Performance Metrics
7.3.2 Comparison of simulation results to real implementation results
7.4 Use case study conclusion
8 Conclusions and Perspectives
Bibliography
