System-on-Chip Design - ARM Architecture
System-on-ChipDesignwith Arm Cortex -M ProcessorsReference BookJOSEPH YIU
System-on-ChipDesignwith Arm Cortex -M Processors
System-on-ChipDesignwith Arm Cortex -M ProcessorsReference BookJOSEPH YIU
Arm Education Media is an imprint of Arm Limited, 110 Fulbourn Road, Cambridge, CBI 9NJ, UKCopyright 2019 Arm Limited (or its affiliates). All rights reserved.No part of this publication may be reproduced or transmitted in any form or by any means, electronicor mechanical, including photocopying, recording or any other information storage and retrievalsystem, without permission in writing from the publisher, except under the following conditions:Permissions You may download this book in PDF format from the Arm.com website for personal, non-commercial use only. You may reprint or republish portions of the text for non-commercial, educational or researchpurposes but only if there is an attribution to Arm Education.This book and the individual contributions contained in it are protected under copyright by thePublisher (other than as may be noted herein).NoticesKnowledge and best practice in this field are constantly changing. As new research and experience broadenour understanding, changes in research methods and professional practices may become necessary.Readers must always rely on their own experience and knowledge in evaluating and using anyinformation, methods, project work, or experiments described herein. In using such information ormethods, they should be mindful of their safety and the safety of others, including parties for whomthey have a professional responsibility.To the fullest extent permitted by law, the publisher and the authors, contributors, and editors shallnot have any responsibility or liability for any losses, liabilities, claims, damages, costs or expenses resultingfrom or suffered in connection with the use of the information and materials set out in this textbook.Such information and materials are protected by intellectual property rights around the world and arecopyright Arm Limited (or its affiliates). All rights are reserved. Any source code, models or other materialsset out in this textbook should only be used for non-commercial, educational purposes (and/or subject tothe terms of any license that is specified or otherwise provided by Arm). In no event shall purchasing thistextbook be construed as granting a license to use any other Arm technology or know-how.ISBN: 978-1-911531-19-7Version: 1.0.3 – pdfFor information on all Arm Education Media publications, visit our website athttps://www.arm.com/resources/education/booksTo report errors or send feedback please email edumedia@arm.com
To our families
ContentsForewordPrefacexivxviiiExample Codes and Projects / Disclaimer / A note about the scope of this bookxixAbout the AuthorxxAcknowledgmentsxxi1. Introduction to Arm Cortex-M1.1 Why learn Cortex-M system design?21.1.1 Starting Cortex-M system design is easy21.1.2 Cortex-M processor systems on FPGA31.1.3 Security by design is made easier with Arm architecture41.2 Understanding different types of Arm processors41.3 Cortex-M deliverables71.3.1 Licensing through Arm Flexible Access and Arm DesignStart71.3.2 Obfuscated Verilog – DesignStart Eval81.3.3 Verilog RTL sources – DesignStart Pro91.3.4 FPGA Packages – DesignStart FPGA91.3.5 Documentation92. Introduction to system design with Cortex-M processors2.1 Overview of Cortex-M Processors122.2 What memories are needed?132.2.1 Overview of memories132.2.2 Memory declarations in FPGA design tools142.2.3 Memory handling in ASIC designs162.2.4 Memory endianness172.3 Defining the peripherals172.4 Memory map definition182.5 Bus and memory system design202.6 TCM integration212.7 Cache integration212.8 Defining the processor’s configuration options222.9 Interrupt signals and related areas22vii
Contents2.10 Event interface242.11 Clock generation252.12 Reset generation272.13 SysTick292.14 Debug integration302.15 Power management features312.16 Top-level pin assignment and pin multiplexing312.17 Miscellaneous signals322.18 Sign off requirements323. AMBA, AHB, and APB3.1 What is AMBA?3.1.1 Introduction to Advanced Microcontroller Bus Architecture363.1.2 History of AMBA363.1.3 Various versions of AMBA specification373.2 Overview of AHB383.2.1 Various versions of AHB383.2.2 AHB signals383.2.3 Basic operations403.2.4 Minimal AHB systems423.2.5 Handling of multiple bus masters433.3 More details on the AHB protocol453.3.1 Address phase signals453.3.2 Data phase signals513.3.3 Legacy arbiter handshake signals553.4 Exclusive access operationsviii36573.4.1 Introduction to exclusive accesses573.4.2 AHB5 exclusive access support603.4.3 Mapping of Cortex-M3/M4/M7 exclusive access signals to AHB5613.5 AHB5 TrustZone support623.6 Overview of APB633.6.1 Introduction to the APB bus system633.6.2 APB signals and connection64
Contents3.6.3 Additional signals in APB protocol v2.0683.6.4 Data values on APB693.6.5 Mixing different versions of APB components694. Building simple bus systems for Cortex-M processors4.1 Introduction to the basics of bus design724.2 Building a simple Cortex-M0 system734.3 Building a simple Cortex-M0 system744.4 Building a simple Cortex-M1 system764.5 Building a simple Cortex-M3/Cortex-M4 system784.6 Handling multiple bus masters844.7 Exclusive access support864.8 Address remap884.9 AHB- based memory connection versus TCM894.10 Handling of embedded flash memories914.10.1 IP requirements914.10.2 Flash programming914.10.3 Bringing up a new device without a valid program image925. Debug integration with Cortex-M processor systems5.1 Overview of debug and trace features965.2 CoreSight Debug Architecture985.2.1 Introduction to Arm CoreSight985.2.2 Debug connection protocols995.2.3 Debug connection concept - Debug Access Port (DAP)1005.2.4 Various arrangements of debug interface structure1015.2.5 Trace connection concept1025.2.6 Timestamp1045.2.7 Debug components discovery (ROM table and component IDs)1045.2.8 Debug authentication1065.2.9 Debug power request1075.2.10 Debug reset request1085.2.11 Cross Trigger Interface108ix
Contents5.3 Debug integration1095.3.1 JTAG / Serial Wire Debug connections1095.3.2 Trace port connections1105.3.3 Clocks for the debug and trace system1115.3.4 Multi-drop serial wire support1135.3.5 Debug authentication1145.4 Other related topics1165.3.1 Other signal connections1165.3.2 Daisy chain of JTAG connection1166. Low-power support6.1 Overview of low-power Cortex-M features1206.2 Low-power design basics1216.3 Cortex-M low-power interfaces1236.3.1 Sleep status and GATEHCLK output1236.3.2 Q-channel low-power interface (Cortex-M23, Cortex-M33, Cortex-M35P)1246.3.3 Sleep hold interface1266.3.4 Wakeup Interrupt Controller (WIC)1286.3.5 SRPG’s impact on software1326.3.6 Software power-saving approach1326.4 Cortex-M processor characteristics that enable low-power designs6.4.1 High code density1336.4.2 Short pipeline1336.4.3 Instruction fetch optimizations1346.5 System-level design considerationsx1331356.5.1 Low-power designs overview1356.5.2 Clock sources1356.5.3 Low-power memories1356.5.4 Caches1356.5.5 Low-power analog components1366.5.6 Maximizing clock gating opportunities1366.5.7 Sleep mode that completely powers down the processor137
Contents7. Design of bus infrastructure components7.1 Overview of a simple AMBA system design1427.2 Typical AHB slave design rules1447.3 Typical AHB infrastructure components1467.3.1 AHB decoders1467.3.2 Default slave1477.3.3 AHB Slave multiplexer1497.3.4 ROM and RAM with AHB interface1517.3.5 AHB to APB Bridge1597.4 Bridging from Cortex-M3/Cortex-M4 AHB Lite to AHB51688. Design of simple peripherals8.1 Common practices for peripheral designs1728.2 Designing Simple APB Peripherals1738.2.1 General Purpose Input Output (GPIO) interface1808.2.2 Simple APB Timer1868.2.3 Simple UART1908.3 ID registers1998.4 Other peripheral design considerations2008.4.1 Security of system control functions2008.4.2 Processor’s halting2008.4.3 Handling of 64-bit data2009. Putting the system together9.1 Creating a simple microcontroller-like system2049.2 Design partitioning2059.3 What is inside a simulation environment?2069.4 Prepare the minimal software support for simulation2079.4.1 Overview of example code based on CMSIS-CORE2079.4.2 Device header file for example MCU (cm3 mcu.h)2089.4.3 Device start-up file for example MCU (startup cm3 mcu.s)2119.4.4 UART utilities2129.4.5 System initialization function213xi
Contents9.4.6 Retargeting2149.4.7 Other software support package considerations2159.5 System-level simulation2169.5.1 Compiling hello world2169.5.2 Using Modelsim/QuestaSim to compile and simulate the design2179.6 Advanced processor systems and Corstone Foundation IP2209.7 Verification2219.8 ASIC implementation flow2239.9 Design for Testing/Testability (DFT)22410. Beyond the processor system10.1 Clock system design23010.1.1 Clock system design overview23010.1.2 Clock switching23110.1.3 Low-power considerations23210.1.4 DFT considerations23210.2 Multiple power domains and power gating23210.3 Arm processors in a mixed-signal world23510.3.1 Convergence of microcontrollers and mixed-signal designs23510.3.2 Analog to digital conversions23610.3.3 Digital to analog conversions24110.3.4 Other analog interface approaches24210.3.5 Connecting ADC and DAC IPs into a Cortex-M system24210.4 Bring an SoC to life – Beetle test chip case study24310.4.1 Beetle test chip overview24310.4.2 Beetle test chip challenges24510.4.3 Beetle test chip system design24610.4.4 Implementation of the Beetle test chip24610.4.5 Other related tasks24711. Software Developmentxii11.1 Introduction to CMSIS (Cortex Microcontroller Software Interface Standard)25211.2 Creating software support for multiple toolchains254
Contents11.2.1 What is needed for creating multiple toolchain support?25411.2.2 Compilation with Arm Compiler 625411.2.3 Compilation with gcc25611.3 Introduction of the Arm Development Studio featuring Arm Keil MicrocontrollerDevelopment Kit (MDK)26111.3.1 Overview of Keil MDK26111.3.2 Keil MDK Installation26211.3.3 Create an application26311.3.4 Using the project wizard to create a project26411.3.5 Create and add source files26611.3.6 Edit the source files26811.3.7 Defining project options26911.3.8 Compile the project27211.3.9 Download and debug the application27211.3.10 Using ITM for text message output (printf)27411.3.11 Software development in collaborative environments27911.4 Using an RTOS27911.4.1 RTOS software concepts27911.4.2 Using Keil RTX28011.4.3 Optimizing memory usage28211.4.3.1 The need for RAM usage analysis28211.4.3.2 Configure RTX for stack watermarking28211.4.3.2 RTX RTOS viewer in Watch windows28311.5 Other toolchains286Glossary of terms288References301Index302xiii
ForewordWhy Read this Book?Right now, you are probably surrounded by Arm processors without even knowing they are there.More than 145 billion chips containing an Arm processor have been produced up to now – this is19 for every human on the planet.The most surprising thing is that Arm does not produce chips. It just designs the technology andenables its partners to manufacture differentiated devices that integrate them.Many more of those chips, also called SoCs (system-on-chip), are expected to be produced in thecoming years. We even start talking about trillions of devices for the Internet of Things (IoT). Of thetotal number of SoCs currently out in the market, the great majority use the smallest processors in theArm product range: the Cortex-M series. Small, very energy efficient and powerful enough for manyapplications, they are at the heart of many of today’s electronic devices.This book is here to explain how SoCs based on the Arm Cortex-M processor portfolio cores aredesigned, detail the different elements that compose such a system, explain the different designissues, describe the integration into systems, and discuss how these SoCs are programmed.A Brief History of ArmThe crazy years marking the history of personal computing began in the 1980s. Acorn, a Britishcompany, became very successful with the BBC Micro-computer, which was used in manyschools throughout the country. For its future generation computers, the company wanted anupdated processor and started a quest for such a component. Unfortunately, none of the availablemicroprocessors were suitable for its needs. Most of them were either too complex or not availableand required a large number of external components. The Acorn team then learned about the ReducedInstruction Set Computer (RISC) concept and found it could lead to powerful, yet low-cost, solutions.At the time, RISC processors were confined to high-end computers, where cost was less of an issue,since no existing RISC processors were exactly suitable. That led the team to embark on the journeyto develop their own piece of silicon.This secret project was named “Acorn RISC Machine” (ARM, in short). The first processor, ARM1, waslaunched in 1985. It was produced by VLSI Technology in a 3µm technology (almost 500 times largerthan the most advanced designs now) and could run at 6 MHz. One of the side-benefits of this simpleprocessor architecture was its lower power consumption (compared to contemporaneous CPUs),which allowed the component to use a lower-cost plastic package without melting it.At the heart of the processor design was the Arm instruction set, which progressively evolved tooptimize the performance and efficiency of new generations of processors. This is a key element ofwhat is called the ‘architecture.’xiv
ForewordThe Arm processors powered several models of Acorn computers, but a major change happened whenVLSI Technology, which was manufacturing the components in its factories, signed an agreement withAcorn to re-sell the chips to other companies. This was the first ‘Arm license.’In 1990, after discussions with Apple Computer, who needed a new processor for the Newtonproject, Acorn decided to spin-off its processor division and form a joint venture with Apple and VLSITechnology. The team then changed the meaning of Arm to ‘Advanced RISC Machines’, which becameArm Ltd later on.This evolution came at the same time as a great change in the new company’s business model. Onthe one hand, Arm had unique assets: great expertise in processor design and an original architecture.However, producing chips required caring about fabrication, yield, quality, logistics, sales channels,complex application-specific marketing, or any other tasks that a silicon manufacturer should do to besuccessful. This was not optimal.On the other hand, silicon manufacturers had a hard time staying competitive, because they had toexcel at these activities while simultaneously investing in design and innovation around processors,at an increasingly fast pace. This was not great either.The revolutionary idea for the newly-formed company was to become a specialist in R&D and focuson the processor design only. Instead of selling components, Arm would license ‘Intellectual Property’(IP in short) to semiconductor manufacturers, who would then use this IP to design their chips, incombination with other elements that would be more application-specific.Arm EcosystemThe IP model selected from the start by Arm required a very tight relationship with the othercompanies using the IP. As the company did not manufacture products, its success was entirelydependent on the success of chip manufacturers embedding the Arm IP into their chips. Conversely,to make sure that they always get the best performance and efficiency for their products, siliconmanufacturers had to make sure that the success of their products also benefited Arm, so that part ofthe increasing revenues would be invested in improved and competitive IP. Together, Arm and partnerssolidified the symbiosis using a royalty-based model: Arm revenues were largely dependent on thesuccess of the chips containing its IP. This resulted in a strong partnership between the company andits customers, and a great sign of this very special relationship is that customers were called ‘partners’(This is still the case more than 25 years after the foundation of the company).Another great benefit from these partnerships was that each semiconductor ‘partner’ could focuson a different set of applications, on different market segments, and integrate its own expertise and‘secret sauce’ into the design of their products. This business model allowed the creation of a richvariety of products that no single company (even the largest ones) would have been able to put intotheir product catalog. It also made it increasingly difficult for processor manufacturers using otherarchitectures to compete with Arm because they had to compete with a whole ‘ecosystem.’ Manyof them progressively decided to stop wasting money on processor architecture development andrealized that it was much less expensive just to license state-of-the-art IP from Arm.xv
ForewordAnother consequence of having several companies using the same processor IP cores was that tools,software, and expertise could be reused from one chip to another. Indeed, a processor requires manytools like code compilers or debuggers: having a larger market for these tools encouraged severalcompanies to start supporting the Arm architecture. Similarly, having a family of processors that couldexecute the same instructions enabled the software developers to propose many operating systems,libraries, frameworks or various elements that could easily run or be adapted to several components.Finally, this allowed engineers to avoid having to learn about a new processor every time they changedtheir chip, which allowed them to build strong expertise and become more efficient.All of these factors meant that Arm could add several additional partners in the ecosystem, bringingeven greater value to every participant and making Arm-based solutions even more attractive. Thisvirtuous circle has significantly contributed to the success of the Arm ecosystem.Softbank AcquisitionEven if the IP model has been duplicated many times, no other company has managed to be assuccessful. This propelled Arm into a very special position in the industry. Its long-term successrequired fairness with each member of the industry, and careful management to keep the balancebetween all partners of the ecosystem.2016 marked a significant milestone in Arm’s history: Softbank group agreed with Arm managementto acquire the company with the promise to continue promoting the same values of fairness andpartnership while accelerating its development.Market and ApplicationsArm-based processors are used in virtually all applications requiring processing capability: as thecompany says, “wherever computing happens.” Over the years, the company has developed a rangeof products that address very different needs, from the tiniest processors for embedded applications(the Arm Cortex-M processor portfolio) to the largest application processors that are used in highperformance servers or that power 95% of the mobile phones in the world (the Cortex-A processorportfolio). There is more than a factor of 100 in complexity and size between the smallest and thehighest performing cores.However, central processing units are not the only IP offered by Arm: a diverse range of IP has beendeveloped or acquired by the company to address the needs of many applications. This is the case ofwhat is called ‘System IP’: all the elements that enable processors to connect to the rest of the system,transfer or store data between those elements, manage security, enable the debug of the software,and manage power. Another very important line of products relates to media processing, and the ArmMali series is now the world’s ‘most shipped’ commercial GPU IP.Enabling Future Technology TodayEven if the core business of Arm remains semiconductor IP, more and more software is being developedto complement hardware designs
10.3.5 Connecting ADC and DAC IPs into a Cortex-M system 242 10.4 243Bring an SoC to life – Beetle test chip case study 10.4.1 Beetle test chip overview 243 10.4.2 Beetle test chip challenges 245 10.4.3 Beetle test chip system design 246 10.4.4 Implementation of the Beetle test chip 24
Modern System-on-Chip Design on Arm David J. Greaves TEXTBOOK SoC Design. Modern System-on-Chip Design on Arm DAVID J. GREAVES. . 3.4 Network-on-Chip 113 3.4.1 NoCRoutingandSwitching 115 3.4.2 VirtualChannels 118 3.4.3 NoCDeadlocks 118 3.4.4 Credit-basedFlowControl 122 3.4.5 AMBA5CHI 124 vii.
Reference Material §ARM ARM(“Architecture Reference Manual ”) §ARM DDI 0100E covers v5TE DSP extensions §Can be purchased from booksellers - ISBN 0-201-737191 (Addison-Wesley) §Available for download from ARM’swebsite §ARM v7-M ARM available for download from ARM’swebsite §Conta
(Dual-Monitor Arm, Single Monitor Arm, Monitor Arm Laptop Stand) If your monitor is too heavy (arm won't stay up) or too light (arm won't stay down), you need to . adjust the spring arm tension to hold them at the right height. Insert the long M6 Allen Wrench that came with your Monitor Arm into the . opening to adjust the tension bolt.
Trx arm workouts pdf. Trx band arm workout. Trx full arm workout. Trx chest and arm workout. Trx shoulder and arm workout. Trx arm workout video. Trx arm workout youtube. Whether you're looking for TRX exercises for beginners or a more advanced TRX workout plan, these moves have something for everyone. "The pike is a personal favorite of mine!"
Figure 2. Design of Space craft with robotic arm space in the launching vehicle compared to the traditional rigid, fixed geometry robotic arm. Figure 3. Morphing robotic arm section 3. DYNAMIC MODEL OF ROBOTIC ARM In this section, dynamic model of the morphing arm based on telescopic type morphing beam is derived. The robotic arm is assumed to .
LabVIEW uses the parallel communication to send the joint angles of the robot arm to the ARM. ARM microcontroller uses five PWM (Pulse Width Modulation) signals in order to control the robot arm, which was geared up with servo motors. Robot arm was controlled manually through the LabVIEW GUI (Graphical User Interface) controls.
8.) Once the Loading Arm is mounted to inlet-supply piping, reconnect torsion-spring link arm via pivot pin. 9.) Secure pivot pin with E-clips. 10.) Raise outboard section of Loading Arm until Link Arm holes align with pin lugs on outboard piping. 11.) For a supported boom-style arm, Loading Arm must be supported until the pillow block or the
Andreas Wagner, CEO Berlin Office Schiffbauerdamm 19, D-10117 Berlin Phone: 49-30-27595-141 Fax: 49-30-27595142 berlin@offshore-stiftung.de Varel Office Oldenburger Str. 65, D-26316 Varel Phone: 49-4451-9515-161 Fax: 49-4451-9515-249 varel@offshore-stiftung.de www.offshore-stiftung.de More news & information (German/English) 16 Backup Slides German Offshore Windfarms under Construction 2 .
