DOCSLIB.ORG

Securing Vehicle Electronic Control Unit (ECU) Communications and Stored Data

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Securing Vehicle Electronic Control Unit (ECU) Communications and Stored Data Securing Vehicle Electronic Control Unit (ECU) Communications and Stored Data by Md Swawibe Ul Alam A thesis submitted to the School of Computing in conformity with the requirements for the degree of Master of Science Queen's University Kingston, Ontario, Canada September 2018 Copyright c Md Swawibe Ul Alam, 2018 Abstract Nowadays, the automobile industry is integrating many new features into vehicles. To provide these features, various electronic systems are being added. These sys- tems are coordinated by different ECUs (Electronic Control Unit). Vehicle ECUs are internally connected through multiple communication buses. Any ECU connected to the bus can read or send data to other ECUs. As a result, if an adversary can compromise one of the ECUs, then the adversary will be able to access and exploit data of other important ECUs. The absence of confidentiality is the main reason for that. Furthermore, the absence of data integrity and authenticity make the commu- nications more vulnerable. In the past, it has been shown that an adversary can take control of the vehicle exploiting the inadequacy of CIA (Confidentiality, Integrity, and Authenticity). Moreover, an adversary can modify the stored data of an important ECU, if it is compromised. To solve these problems, we propose the use of symmetric key cryptography and elliptic curve-based Public Key Encryption (PKE) for ensuring confidentiality and the use of digital signature for ensuring integrity and authenticity. In addition, we propose the adoption of an identity-based access control in Mother ECUs (MECU, also known as a domain controller) to control the communication permissions. We also introduce Blockchain in vehicles to protect the stored data of ECUs. Finally, we integrate a watcher to monitor the stored data and report if it is i modified. We implement the proposed technique in two platforms, namely Docker and the ARM architecture-based Raspberry Pi Board. Our experiments show that the pro- posed technique can improve security in ECU communications. The watcher reports when an ECU data is modified which helps limit the damage when an ECU is com- promised. ii Acknowledgements I am grateful to my supervisor Professor Mohammad Zulkernine for his continu- ous support, guidance, patience, and motivation over the last two years at Queen's University. Without his help, this thesis would not have been possible. I would also like to dedicate this thesis to my parents and sister for their encour- agement, unconditional love, inspiration, motivation, and wisdom through my entire life. Finally, I would like to thank Dr. Clifford Liem for his guidance to my research during my internship and Dr. Shahrear Iqbal for his motivation during my experi- ments. I would also like to thank my colleagues at Queen's Reliable Software Technol- ogy Group (QRST) especially to Karim Lounis who have been more than supportive during this effort. iii Contents Abstracti Acknowledgements iii Contents iv List of Figures vii List of Tables ix Chapter 1: Introduction1 1.1 Motivation................................. 1 1.2 Problem Overview ............................ 3 1.3 Overview of the Proposed Approach................... 5 1.4 Contributions............................... 7 1.5 Organization of the Thesis........................ 8 Chapter 2: Background and Related Work9 2.1 Electronic Control Unit (ECU) ..................... 9 2.1.1 Mother ECU (MECU)...................... 10 2.2 In-Vehicle E/E-Architecture....................... 10 2.2.1 Current In-Vehicle E/E-Architecture .............. 10 2.2.2 Domain-Based In-Vehicle E/E-Architecture .......... 12 2.3 Cryptography............................... 13 2.3.1 Symmetric Key Cryptography.................. 13 2.3.2 Public Key Encryption (PKE).................. 14 2.3.3 Digital Signature......................... 15 2.4 Identity-Based Access Control...................... 15 2.5 Blockchain................................. 16 2.5.1 The Use of Blockchain in Bitcoin ................ 16 2.6 Related Work............................... 18 2.6.1 In-Vehicle Communication Security............... 18 iv 2.6.2 Use of Blockchain in Vehicles .................. 20 2.7 Summary ................................. 23 Chapter 3: ECU Communications and Data Security 25 3.1 Proposed Approach Overview...................... 25 3.2 Securing Vehicle ECU Communications................. 27 3.2.1 Structure of Lists......................... 27 3.2.2 Secure Communications between ECUs............. 29 3.2.2.1 Data Transaction Structure between ECUs . 31 3.2.3 Secure Communications from an ECU to an MECU . 32 3.3 Securing the Stored Data......................... 35 3.3.1 Storing Data in the Blockchain ................. 35 3.3.1.1 Data Transaction Structure from an MECU to the Leader.......................... 38 3.3.1.2 The Structure of Blocks................ 39 3.3.2 Data Monitoring by the Watcher ................ 40 3.3.3 Data Protection Without the Resource Consuming Algorithm 41 3.4 Major Challenges............................. 42 3.4.1 Transferring Data......................... 43 3.4.2 Choosing the Symmetric Key Cryptography.......... 44 3.4.3 The Use of Public Key Encryption ............... 45 3.4.4 Choosing the Digital Signature ................. 45 3.4.5 Using Blockchain in Vehicles................... 46 3.4.5.1 Resource Consuming Consensus Algorithm . 46 3.4.5.2 Latency of Transactions................ 47 3.4.5.3 Transaction Throughput of the Blockchain . 48 3.4.5.4 Resource Scarcity.................... 48 3.5 Summary ................................. 49 Chapter 4: Implementation and Evaluation 50 4.1 Initialization of ECUs and MECUs ................... 50 4.1.1 ECU Credential Initialization .................. 51 4.1.2 MECU Credential Initialization................. 51 4.1.3 Watcher Credential Initialization ................ 52 4.2 Implementation on the Docker...................... 52 4.2.1 Why Docker?........................... 53 4.2.2 Experimental Setup........................ 53 4.3 Implementation on the Raspberry Pi Board .............. 55 4.3.1 Why Raspberry Pi Board?.................... 55 4.3.2 Experimental Setup........................ 55 v 4.4 Security Experiments........................... 57 4.4.1 Data Confidentiality ....................... 57 4.4.2 Data Integrity and Authenticity................. 58 4.4.3 Identity-Based Access Control.................. 59 4.4.4 Security of the Stored Data ................... 61 4.5 Attack Protection Analysis........................ 62 4.5.1 Protection from Data Stealing.................. 63 4.5.2 Protection from Data Falsification................ 63 4.5.3 Protection from Control Override................ 63 4.5.4 Protection from Vehicle Degradation .............. 64 4.5.5 Protection from Remote Access Threats ............ 64 4.6 Performance Evaluation ......................... 65 4.6.1 End to End Delay on Docker .................. 66 4.6.2 End to End Delay on RPBs................... 66 4.6.3 Discussion of the End to End Delay............... 68 4.7 Summary ................................. 69 Chapter 5: Conclusion and Future Work 70 5.1 Conclusion................................. 70 5.2 Limitations ................................ 71 5.3 Future Work................................ 72 Bibliography 73 vi List of Figures 1.1 Overview of the proposed approach.................... 7 2.1 In-vehicle E/E-architecture of BMW 7 series............... 11 2.2 Domain-based in-vehicle E/E-architecture................ 13 2.3 Basic structure of a Bitcoin block..................... 17 3.1 The domain-based in-vehicle architecture after integrating the pro- posed approach............................... 26 3.2 The process of securing communications between ECUs. 29 3.3 The process of securing communications from an ECU to an MECU. 33 3.4 Data transaction structure from an ECU to an MECU. 35 3.5 The process of storing data in the Blockchain.............. 36 3.6 Data transaction structure from an MECU to the leader. 38 3.7 The Structure of Blocks.......................... 40 4.1 Docker container setup........................... 54 4.2 The experimental setup of RPBs..................... 56 4.3 Unencrypted data transmit from ECU2 to ECU1............ 57 4.4 Encrypted data transmit from ECU2 to ECU1. ............ 58 4.5 ECU1 rejects ECU2's data as the signature is not verified. 59 vii 4.6 MECU1 rejects ECU3's `Communication Request'. .......... 60 4.7 Watcher alert when a single block is compromised............ 61 4.8 Watcher alert when multiple blocks are compromised. 62 4.9 Average end to end delay of data transfer on Docker.......... 67 4.10 Average end to end delay of data transfer on RPBs........... 68 viii List of Tables 3.1 Request List. ............................... 27 3.2 Permission List............................... 28 3.3 State List.................................. 28 3.4 Data Transaction Structure between ECUs. .............. 31 4.1 Host Machine Specification........................ 54 ix 1 Chapter 1 Introduction 1.1 Motivation Modern vehicles are not just a combination of engine, chassis, body, and wheels. They are equipped with many sensors and electronic devices to assist drivers. By 2020, around 35 percent of total manufacturing costs for vehicles will be for electronics [63]. The vehicle industry is expanding exponentially and more features are being added to vehicles for safe driving. Most of these features are integrated as an electronic system or subsystem. To coordinate these electronic systems, vehicle manufacturers introduced Electronic Control Units
Load more

Recommended publications
  • Bluecat™ 300 Brochure
    Your LSI engine emission control just got easier! The BlueCAT™ 300 is a Retrofit Emissions Control System which has been verified by the California Air Resources Board (CARB) for installation on uncontrolled gaseous-fueled Large Spark-Ignition (LSI) engines. BlueCAT™ 300 systems control exhaust emissions and noise from industrial forklift trucks, floor care machinery, aerial lifts, ground support equipment, and other spark-ignition rich-burn (stoichiometric) engines. Nett Technologies’ BlueCAT™ 300 practically eliminates all of the major exhaust pollutants: Carbon Monoxide (CO) and Oxides of Nitrogen (NOx) emissions are reduced by over 90% and Hydrocarbons (HC) by over 80%. BlueCAT™ 300 three-way catalytic converters consist of a high-performance emissions control catalyst and an advanced electronic Air/Fuel Ratio Controller. The devices work together to optimize engine operation, fuel economy and control emissions. The controller also reduces fuel consumption and increases engine life. Nett's BlueCAT™ 300 catalytic muffler replaces the OEM muffler simplifying installation and saving time. The emission control catalyst is built into the muffler and its size is selected based on the displacement of the engine. Thousands of direct-fit designs are available for all makes/models of forklifts and other equipment. The BlueCAT™ 300 catalytic muffler matches or surpasses the noise attenuation performance of the original muffler with the addition of superior emissions reduction performance. NIA ARB OR IF L ™ A C BlueCAT VERIFIED 300 LSI-2 Rule 3-Way Catalyst scan and learn Sold and supported globally, Nett Technologies Inc., develops and manufactures proprietary catalytic solutions that use the latest in diesel oxidation catalyst (DOC), diesel particulate filter (DPF), selective catalytic reduction (SCR), engine electronics, stationary engine silencer, exhaust system and exhaust gas dilution technologies.
    [Show full text]
  • The Von Neumann Computer Model 5/30/17, 10:03 PM
    The von Neumann Computer Model 5/30/17, 10:03 PM CIS-77 Home http://www.c-jump.com/CIS77/CIS77syllabus.htm The von Neumann Computer Model 1. The von Neumann Computer Model 2. Components of the Von Neumann Model 3. Communication Between Memory and Processing Unit 4. CPU data-path 5. Memory Operations 6. Understanding the MAR and the MDR 7. Understanding the MAR and the MDR, Cont. 8. ALU, the Processing Unit 9. ALU and the Word Length 10. Control Unit 11. Control Unit, Cont. 12. Input/Output 13. Input/Output Ports 14. Input/Output Address Space 15. Console Input/Output in Protected Memory Mode 16. Instruction Processing 17. Instruction Components 18. Why Learn Intel x86 ISA ? 19. Design of the x86 CPU Instruction Set 20. CPU Instruction Set 21. History of IBM PC 22. Early x86 Processor Family 23. 8086 and 8088 CPU 24. 80186 CPU 25. 80286 CPU 26. 80386 CPU 27. 80386 CPU, Cont. 28. 80486 CPU 29. Pentium (Intel 80586) 30. Pentium Pro 31. Pentium II 32. Itanium processor 1. The von Neumann Computer Model Von Neumann computer systems contain three main building blocks: The following block diagram shows major relationship between CPU components: the central processing unit (CPU), memory, and input/output devices (I/O). These three components are connected together using the system bus. The most prominent items within the CPU are the registers: they can be manipulated directly by a computer program. http://www.c-jump.com/CIS77/CPU/VonNeumann/lecture.html Page 1 of 15 IPR2017-01532 FanDuel, et al.
    [Show full text]
  • Outboard Protection
    Get Premium Outboard Protection. For True Peace of Mind. Passport Premier offers comprehensive, long-term engine package protection for your new or pre-owned vessel. Even entire engine assemblies are replaced if necessary. So you can enjoy your time on the water, knowing you are covered against costly repairs for years to come. Passport Premier lets you head out with confidence: • Long-term coverage on over 120 major engine parts • Covers overheating, even detonation, lots more • Repair reimbursement includes parts and labor • Locking in now offers assurance against inflation • Protection cost can be rolled into your boat financing • All benefits are transferable for higher resale value With expert service at any manufacturer authorized facility and plan management by Brunswick, a top U.S. boat and engine seller, it’s coverage you can truly count on. Comprehensive Extended Protection Benefits Non-Defective Engine Breakdown Claim Payment Benefits Service Assist Engine Sensor Failures Carbonized Rings Lubricants Hoses On-water towing Pick Up/delivery Thermostat Failures Heat Collapsed Rings Coolants Engine Tuning Hoist/lift-out Lake Test Overheating* Scored Pistons Belts Taxes Haul Out Sea Trial Preignition Scored Cylinders Spark Plugs Shop Supplies Dockside repair call Detonation Heat Cracked Heads Clamps Haul Out Burnt Valves Warped Heads Filters Transfer Provision Bent Valves Heat Cracked Block Tuliped Valves All service contract plan benefits transferable on new boats – *Any overheating conditions created by raw water pump and/or impeller
    [Show full text]
  • Demystifying Internet of Things Security Successful Iot Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M
    Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security: Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Chandler, AZ, USA Chandler, AZ, USA Ned Smith David M. Wheeler Beaverton, OR, USA Gilbert, AZ, USA ISBN-13 (pbk): 978-1-4842-2895-1 ISBN-13 (electronic): 978-1-4842-2896-8 https://doi.org/10.1007/978-1-4842-2896-8 Copyright © 2020 by The Editor(s) (if applicable) and The Author(s) This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons license, unless indicated otherwise in a credit line to the material.
    [Show full text]
  • Research Article Development of an Integrated Cooling System Controller for Hybrid Electric Vehicles
    Hindawi Journal of Electrical and Computer Engineering Volume 2017, Article ID 2605460, 9 pages https://doi.org/10.1155/2017/2605460 Research Article Development of an Integrated Cooling System Controller for Hybrid Electric Vehicles Chong Wang,1 Qun Sun,1 and Limin Xu2 1 School of Mechanical and Automotive Engineering, Liaocheng University, Liaocheng, China 2School of International Education, Liaocheng University, Liaocheng, China Correspondence should be addressed to Chong Wang; [email protected] Received 14 January 2017; Accepted 15 March 2017; Published 10 April 2017 Academic Editor: Ephraim Suhir Copyright © 2017 Chong Wang et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. A hybrid electrical bus employs both a turbo diesel engine and an electric motor to drive the vehicle in different speed-torque scenarios. The cooling system for such a vehicle is particularly power costing because it needs to dissipate heat from not only the engine, but also the intercooler and the motor. An electronic control unit (ECU) has been designed with a single chip computer, temperature sensors, DC motor drive circuit, and optimized control algorithm to manage the speeds of several fans for efficient cooling using a nonlinear fan speed adjustment strategy. Experiments suggested that the continuous operating performance of the ECU is robust and capable of saving 15% of the total electricity comparing with ordinary fan speed control method. 1. Introduction according to water temperature. Some recent studies paid more attention to the nonlinear engine and radiator ther- A hybrid electrical vehicle (HEV) employs both a turbo diesel mocharacteristics and the corresponding nonlinear PWM engine and an electric motor to drive the vehicle in different control techniques [6–9], which so far has not yielded mass speed-torquescenarios.Aneffectivethermomanagement produced equipment.
    [Show full text]
  • Review Paper on Vehicle Diagnosis with Electronic Control Unit
    Volume 3, Issue 2, February – 2018 International Journal of Innovative Science and Research Technology ISSN No:-2456 –2165 Review Paper on Vehicle Diagnosis with Electronic Control Unit Rucha Pupala Jalaj Shukla Mechanical, Sinhgad Institute of Technology and Science Mechanical, Sinhgad Institute of Technology and Science Pune, India Pune, India Abstract—An Automobile vehicle is prone to various faults stringency of exhaust gas legislation, the electronically due to more complex integration of electro-mechanical controlled system has been widely used in engines for components. Due to the increasing stringency of emission performance optimization of the engine as well as vehicle norms improved and advanced electronic systems have propelled by the engine[1].The faults in the automotive engine been widely used. When different faults occur it is very may lead to increased emissions and more fuel consumption difficult for a technician who does not have sufficient with engine damage. These affects can be prevented if faults knowledge to detect and repair the electronic control are detected and treated in timely manner. A number of fault system. However such services in the after sales network monitoring and diagnostic methods have been developed for are crucial to the brand value of automotive manufacturer automotive applications. The existing systems typically and client satisfaction. Development of a fast, reliable and implement fault detection to indicate that something is wrong accurate intelligent system for fault diagnosis of in the monitored system, fault separation to determine the automotive engine is greatly urged. In this paper a new exact location of the fault i.e., the component which is faulty, approach to Off- Board diagnostic system for automotive and fault identification to determine the magnitude of the fault.
    [Show full text]
  • Virtual Sensor for Automotive Engine to Compensate for the Map, Engine Speed Sensors Faults
    Virtual Sensor For Automotive Engine To Compensate For The Map, Engine Speed Sensors Faults By Sohaub S.Shalalfeh Ihab Sh.Jaber Ahmad M.Hroub Supervisor: Dr. Iyad Hashlamon Submitted to the College of Engineering In partial fulfillment of the requirements for the degree of Bachelor degree in Mechatronics Engineering Palestine Polytechnic University March- 2016 Palestine Polytechnic University Hebron –Palestine College of Engineering and Technology Mechanical Engineering Department Project Name Virtual sensor for automotive engine to compensate for the map, engine speed sensors faults Project Team Sohaub S.shalalfeh Ihab Sh.Jaber Ahmad M.Hroub According to the project supervisor and according to the agreement of the testing committee members, this project is submitted to the Department of Mechanical Engineering at College of Engineering in partial fulfillments of the requirements of the Bachelor’s degree. Supervisor Signature ………………………….. Committee Member Signature ……………………… ……………………….. …………………… Department Head Signature ………………………………… I Dedication To our parents. To all our teachers. To all our friends. To all our brothers and sisters. To Palestine Polytechnic University. Acknowledgments We could not forget our families, who stood by us, with their support, love and care for our whole lives; they were with us with their bodies and souls, believed in us and helped us to accomplish this project. We would like to thank our amazing teachers at Palestine Polytechnic University, to whom we would carry our gratitude our whole life. Special thanks
    [Show full text]
  • Reverse Engineering X86 Processor Microcode
    Reverse Engineering x86 Processor Microcode Philipp Koppe, Benjamin Kollenda, Marc Fyrbiak, Christian Kison, Robert Gawlik, Christof Paar, and Thorsten Holz, Ruhr-University Bochum https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/koppe This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX Reverse Engineering x86 Processor Microcode Philipp Koppe, Benjamin Kollenda, Marc Fyrbiak, Christian Kison, Robert Gawlik, Christof Paar, and Thorsten Holz Ruhr-Universitat¨ Bochum Abstract hardware modifications [48]. Dedicated hardware units to counter bugs are imperfect [36, 49] and involve non- Microcode is an abstraction layer on top of the phys- negligible hardware costs [8]. The infamous Pentium fdiv ical components of a CPU and present in most general- bug [62] illustrated a clear economic need for field up- purpose CPUs today. In addition to facilitate complex and dates after deployment in order to turn off defective parts vast instruction sets, it also provides an update mechanism and patch erroneous behavior. Note that the implementa- that allows CPUs to be patched in-place without requiring tion of a modern processor involves millions of lines of any special hardware. While it is well-known that CPUs HDL code [55] and verification of functional correctness are regularly updated with this mechanism, very little is for such processors is still an unsolved problem [4, 29]. known about its inner workings given that microcode and the update mechanism are proprietary and have not been Since the 1970s, x86 processor manufacturers have throughly analyzed yet.
    [Show full text]
  • Control Unit Operation
    PART SIX: THE CONTROL UNIT CHAPTER 19 CONTROL UNIT OPERATION 19.1 MICRO-OPERATIONS ............................................................... 3 The Fetch Cycle ...................................................................... 5 The Indirect Cycle................................................................... 8 The Interrupt Cycle ................................................................. 9 The Execute Cycle................................................................... 9 The Instruction Cycle............................................................. 12 19.2 CONTROL OF THE PROCESSOR ............................................... 13 Functional Requirements........................................................ 13 Control Signals ..................................................................... 16 A Control Signals Example ..................................................... 19 Internal Processor Organization .............................................. 23 The Intel 8085...................................................................... 24 19.3 HARDWIRED IMPLEMENTATION .............................................. 30 Control Unit Inputs ............................................................... 30 Control Unit Logic ................................................................. 33 19.4 RECOMMENDED READING ...................................................... 35 19.5 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS ................... 35 Key Terms ..........................................................................
    [Show full text]
  • IBM Z Connectivity Handbook
    Front cover IBM Z Connectivity Handbook Octavian Lascu John Troy Anna Shugol Frank Packheiser Kazuhiro Nakajima Paul Schouten Hervey Kamga Jannie Houlbjerg Bo XU Redbooks IBM Redbooks IBM Z Connectivity Handbook August 2020 SG24-5444-20 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. Twentyfirst Edition (August 2020) This edition applies to connectivity options available on the IBM z15 (M/T 8561), IBM z15 (M/T 8562), IBM z14 (M/T 3906), IBM z14 Model ZR1 (M/T 3907), IBM z13, and IBM z13s. © Copyright International Business Machines Corporation 2020. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix Authors. ix Now you can become a published author, too! . xi Comments welcome. xi Stay connected to IBM Redbooks . xi Chapter 1. Introduction. 1 1.1 I/O channel overview. 2 1.1.1 I/O hardware infrastructure . 2 1.1.2 I/O connectivity features . 3 1.2 FICON Express . 4 1.3 zHyperLink Express . 5 1.4 Open Systems Adapter-Express. 6 1.5 HiperSockets. 7 1.6 Parallel Sysplex and coupling links . 8 1.7 Shared Memory Communications. 9 1.8 I/O feature support . 10 1.9 Special-purpose feature support . 12 1.9.1 Crypto Express features . 12 1.9.2 Flash Express feature . 12 1.9.3 zEDC Express feature . 13 Chapter 2. Channel subsystem overview . 15 2.1 CSS description . 16 2.1.1 CSS elements .
    [Show full text]
  • The Microprogrammed Control Unit
    The Microprogrammed Control Unit Up to this point, we have studied: 1. The microoperation sequence associated with each assembly language instruction 2. The control signals associated with those microoperations. 3. The use of combinational logic in the form of a signal generation tree to generate these control signals. We now consider another option for generating the control signals. This is the microprogramming option, in which representations of the control signals are stored in a micro–memory and read into a MBR (micro–memory buffer register) from whence they are issued. Consider the control signal PC B1. When this is asserted, the contents of the Program Counter are copied onto bus B1. The method of generating this signal has no effect on the action it takes. We have two options for generating each control signal: Hardwired: The signal is output from an AND gate Microprogrammed: The signal is output from a D flip–flop. Survey of Bus Usage and Other Control Signals In order to structure the micro–memory properly, we must tabulate the control signals used and arrange them by use: bus transfer, ALU operation, memory operation, etc. Option Bus 1 Bus 2 Bus 3 ALU Other 0 1 PC B1 1 B2 B3 PC tra1 L / R’ 2 MAR B1 – 1 B2 B3 MAR tra2 A 3 R B1 R B2 B3 R shift C 4 IR B1 MBR B2 B3 IR not READ 5 SP B1 IOD B2 B3 SP add WRITE 6 B3 MBR sub extend 7 B3 IOD and 0 RUN 8 B3 IOA or 9 xor Note the important option 0.
    [Show full text]
  • Microprogramming: Basic Idea
    5-45 Chapter 5—Processor Design—Advanced Topics Microprogramming: Basic Idea • Recall control sequence for 1-bus SRC Step Concrete RTN Control Sequence T0 MA ← PC: C ← PC + 4; PCout, MAin, INC4, Cin, Read ← ← T1 MD M[MA]: PC C; Cout, PCin, Wait T2 IR ← MD; MDout, IRin ← T3 A R[rb]; Grb, Rout, Ain ← T4 C A + R[rc]; Grc, Rout, ADD, Cin ← T5 R[ra] C; Cout, Gra, Rin, End • Control unit job is to generate the sequence of control signals • How about building a computer to do this? Computer Systems Design and Architecture by V. Heuring and H. Jordan © 1997 V. Heuring and H. Jordan 5-46 Chapter 5—Processor Design—Advanced Topics The Microcode Engine • A computer to generate control signals is much simpler than an ordinary computer • At the simplest, it just reads the control signals in order from a read-only memory • The memory is called the control store • A control store word, or microinstruction, contains a bit pattern telling which control signals are true in a specific step • The major issue is determining the order in which microinstructions are read Computer Systems Design and Architecture by V. Heuring and H. Jordan © 1997 V. Heuring and H. Jordan 5-47 Chapter 5—Processor Design—Advanced Topics Fig 5.16 Block Diagram of Microcoded Control Unit Ck CCs Other IR Opcode PLA • Microinstruction has Sequencer (computes branch control, 2 start addr) External source n branch address, and control signal fields Increment 4–1 Mux n • Microprogram µPC counter can be set n from several sources to do the required Control sequencing store k n m µBranch µIR control Branch Control signals address PCout, etc.
    [Show full text]