DOCSLIB.ORG

System-On-Chip Design with Arm® Cortex®-M Processors

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
System-On-Chip Design with Arm® Cortex®-M Processors System-on-Chip Design with Arm® Cortex®-M Processors Reference Book JOSEPH YIU System-on-Chip Design with Arm® Cortex®-M Processors System-on-Chip Design with Arm® Cortex®-M Processors Reference Book JOSEPH YIU Arm Education Media is an imprint of Arm Limited, 110 Fulbourn Road, Cambridge, CBI 9NJ, UK Copyright © 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, electronic or mechanical, including photocopying, recording or any other information storage and retrieval system, 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 research purposes but only if there is an attribution to Arm Education. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our 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 any information, methods, project work, or experiments described herein. In using such information or methods, they should be mindful of their safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent permitted by law, the publisher and the authors, contributors, and editors shall not have any responsibility or liability for any losses, liabilities, claims, damages, costs or expenses resulting from 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 are copyright © Arm Limited (or its affiliates). All rights are reserved. Any source code, models or other materials set out in this textbook should only be used for non-commercial, educational purposes (and/or subject to the terms of any license that is specified or otherwise provided by Arm). In no event shall purchasing this textbook be construed as granting a license to use any other Arm technology or know-how. ISBN: 978-1-911531-19-7 Version: 1.0.3 – pdf For information on all Arm Education Media publications, visit our website at https://www.arm.com/resources/education/books To report errors or send feedback please email [email protected] To our families Contents Foreword xiv Preface xviii Example Codes and Projects / Disclaimer / A note about the scope of this book xix About the Author xx Acknowledgments xxi 1. Introduction to Arm Cortex-M 1.1 Why learn Cortex-M system design? 2 1.1.1 Starting Cortex-M system design is easy 2 1.1.2 Cortex-M processor systems on FPGA 3 1.1.3 Security by design is made easier with Arm architecture 4 1.2 Understanding different types of Arm processors 4 1.3 Cortex-M deliverables 7 1.3.1 Licensing through Arm Flexible Access and Arm DesignStart 7 1.3.2 Obfuscated Verilog – DesignStart Eval 8 1.3.3 Verilog RTL sources – DesignStart Pro 9 1.3.4 FPGA Packages – DesignStart FPGA 9 1.3.5 Documentation 9 2. Introduction to system design with Cortex-M processors 2.1 Overview of Cortex-M Processors 12 2.2 What memories are needed? 13 2.2.1 Overview of memories 13 2.2.2 Memory declarations in FPGA design tools 14 2.2.3 Memory handling in ASIC designs 16 2.2.4 Memory endianness 17 2.3 Defining the peripherals 17 2.4 Memory map definition 18 2.5 Bus and memory system design 20 2.6 TCM integration 21 2.7 Cache integration 21 2.8 Defining the processor’s configuration options 22 2.9 Interrupt signals and related areas 22 vii Contents 2.10 Event interface 24 2.11 Clock generation 25 2.12 Reset generation 27 2.13 SysTick 29 2.14 Debug integration 30 2.15 Power management features 31 2.16 Top-level pin assignment and pin multiplexing 31 2.17 Miscellaneous signals 32 2.18 Sign off requirements 32 3. AMBA, AHB, and APB 3.1 What is AMBA? 36 3.1.1 Introduction to Advanced Microcontroller Bus Architecture 36 3.1.2 History of AMBA 36 3.1.3 Various versions of AMBA specification 37 3.2 Overview of AHB 38 3.2.1 Various versions of AHB 38 3.2.2 AHB signals 38 3.2.3 Basic operations 40 3.2.4 Minimal AHB systems 42 3.2.5 Handling of multiple bus masters 43 3.3 More details on the AHB protocol 45 3.3.1 Address phase signals 45 3.3.2 Data phase signals 51 3.3.3 Legacy arbiter handshake signals 55 3.4 Exclusive access operations 57 3.4.1 Introduction to exclusive accesses 57 3.4.2 AHB5 exclusive access support 60 3.4.3 Mapping of Cortex-M3/M4/M7 exclusive access signals to AHB5 61 3.5 AHB5 TrustZone support 62 3.6 Overview of APB 63 3.6.1 Introduction to the APB bus system 63 3.6.2 APB signals and connection 64 viii Contents 3.6.3 Additional signals in APB protocol v2.0 68 3.6.4 Data values on APB 69 3.6.5 Mixing different versions of APB components 69 4. Building simple bus systems for Cortex-M processors 4.1 Introduction to the basics of bus design 72 4.2 Building a simple Cortex-M0 system 73 4.3 Building a simple Cortex-M0+ system 74 4.4 Building a simple Cortex-M1 system 76 4.5 Building a simple Cortex-M3/Cortex-M4 system 78 4.6 Handling multiple bus masters 84 4.7 Exclusive access support 86 4.8 Address remap 88 4.9 AHB- based memory connection versus TCM 89 4.10 Handling of embedded flash memories 91 4.10.1 IP requirements 91 4.10.2 Flash programming 91 4.10.3 Bringing up a new device without a valid program image 92 5. Debug integration with Cortex-M processor systems 5.1 Overview of debug and trace features 96 5.2 CoreSight Debug Architecture 98 5.2.1 Introduction to Arm CoreSight 98 5.2.2 Debug connection protocols 99 5.2.3 Debug connection concept - Debug Access Port (DAP) 100 5.2.4 Various arrangements of debug interface structure 101 5.2.5 Trace connection concept 102 5.2.6 Timestamp 104 5.2.7 Debug components discovery (ROM table and component IDs) 104 5.2.8 Debug authentication 106 5.2.9 Debug power request 107 5.2.10 Debug reset request 108 5.2.11 Cross Trigger Interface 108 ix Contents 5.3 Debug integration 109 5.3.1 JTAG / Serial Wire Debug connections 109 5.3.2 Trace port connections 110 5.3.3 Clocks for the debug and trace system 111 5.3.4 Multi-drop serial wire support 113 5.3.5 Debug authentication 114 5.4 Other related topics 116 5.3.1 Other signal connections 116 5.3.2 Daisy chain of JTAG connection 116 6. Low-power support 6.1 Overview of low-power Cortex-M features 120 6.2 Low-power design basics 121 6.3 Cortex-M low-power interfaces 123 6.3.1 Sleep status and GATEHCLK output 123 6.3.2 Q-channel low-power interface (Cortex-M23, Cortex-M33, Cortex-M35P) 124 6.3.3 Sleep hold interface 126 6.3.4 Wakeup Interrupt Controller (WIC) 128 6.3.5 SRPG’s impact on software 132 6.3.6 Software power-saving approach 132 6.4 Cortex-M processor characteristics that enable low-power designs 133 6.4.1 High code density 133 6.4.2 Short pipeline 133 6.4.3 Instruction fetch optimizations 134 6.5 System-level design considerations 135 6.5.1 Low-power designs overview 135 6.5.2 Clock sources 135 6.5.3 Low-power memories 135 6.5.4 Caches 135 6.5.5 Low-power analog components 136 6.5.6 Maximizing clock gating opportunities 136 6.5.7 Sleep mode that completely powers down the processor 137 x Contents 7. Design of bus infrastructure components 7.1 Overview of a simple AMBA system design 142 7.2 Typical AHB slave design rules 144 7.3 Typical AHB infrastructure components 146 7.3.1 AHB decoders 146 7.3.2 Default slave 147 7.3.3 AHB Slave multiplexer 149 7.3.4 ROM and RAM with AHB interface 151 7.3.5 AHB to APB Bridge 159 7.4 Bridging from Cortex-M3/Cortex-M4 AHB Lite to AHB5 168 8. Design of simple peripherals 8.1 Common practices for peripheral designs 172 8.2 Designing Simple APB Peripherals 173 8.2.1 General Purpose Input Output (GPIO) interface 180 8.2.2 Simple APB Timer 186 8.2.3 Simple UART 190 8.3 ID registers 199 8.4 Other peripheral design considerations 200 8.4.1 Security of system control functions 200 8.4.2 Processor’s halting 200 8.4.3 Handling of 64-bit data 200 9. Putting the system together 9.1 Creating a simple microcontroller-like system 204 9.2 Design partitioning 205 9.3 What is inside a simulation environment? 206 9.4 Prepare the minimal software support for simulation 207 9.4.1 Overview of example code based on CMSIS-CORE 207 9.4.2 Device header file for example MCU (cm3_mcu.h) 208 9.4.3 Device start-up file for example MCU (startup_cm3_mcu.s) 211 9.4.4 UART utilities 212 9.4.5 System initialization function 213 xi Contents 9.4.6 Retargeting 214 9.4.7 Other software support package considerations 215 9.5 System-level simulation 216 9.5.1 Compiling hello world 216 9.5.2 Using Modelsim/QuestaSim to compile and simulate the design 217 9.6 Advanced processor systems and Corstone Foundation IP 220 9.7 Verification 221 9.8 ASIC implementation flow 223 9.9 Design for Testing/Testability (DFT) 224 10.
Load more

Recommended publications
  • Prostep Ivip CPO Statement Template
    CPO Statement of Mentor Graphics For Questa SIM Date: 17 June, 2015 CPO Statement of Mentor Graphics Following the prerequisites of ProSTEP iViP’s Code of PLM Openness (CPO) IT vendors shall determine and provide a list of their relevant products and the degree of fulfillment as a “CPO Statement” (cf. CPO Chapter 2.8). This CPO Statement refers to: Product Name Questa SIM Product Version Version 10 Contact Ellie Burns [email protected] This CPO Statement was created and published by Mentor Graphics in form of a self-assessment with regard to the CPO. Publication Date of this CPO Statement: 17 June 2015 Content 1 Executive Summary ______________________________________________________________________________ 2 2 Details of Self-Assessment ________________________________________________________________________ 3 2.1 CPO Chapter 2.1: Interoperability ________________________________________________________________ 3 2.2 CPO Chapter 2.2: Infrastructure _________________________________________________________________ 4 2.3 CPO Chapter 2.5: Standards ____________________________________________________________________ 4 2.4 CPO Chapter 2.6: Architecture __________________________________________________________________ 5 2.5 CPO Chapter 2.7: Partnership ___________________________________________________________________ 6 2.5.1 Data Generated by Users ___________________________________________________________________ 6 2.5.2 Partnership Models _______________________________________________________________________ 6 2.5.3 Support of
    [Show full text]
  • Powerplay Power Analysis 8 2013.11.04
    PowerPlay Power Analysis 8 2013.11.04 QII53013 Subscribe Send Feedback The PowerPlay Power Analysis tools allow you to estimate device power consumption accurately. As designs grow larger and process technology continues to shrink, power becomes an increasingly important design consideration. When designing a PCB, you must estimate the power consumption of a device accurately to develop an appropriate power budget, and to design the power supplies, voltage regulators, heat sink, and cooling system. The following figure shows the PowerPlay Power Analysis tools ability to estimate power consumption from early design concept through design implementation. Figure 8-1: PowerPlay Power Analysis From Design Concept Through Design Implementation PowerPlay Early Power Estimator Quartus II PowerPlay Power Analyzer Higher Placement and Simulation Routing Results Results Accuracy Quartus II Design Profile User Input Estimation Design Concept Design Implementation Lower PowerPlay Power Analysis Input For the majority of the designs, the PowerPlay Power Analyzer and the PowerPlay EPE spreadsheet have the following accuracy after the power models are final: • PowerPlay Power Analyzer—±20% from silicon, assuming that the PowerPlay Power Analyzer uses the Value Change Dump File (.vcd) generated toggle rates. • PowerPlay EPE spreadsheet— ±20% from the PowerPlay Power Analyzer results using .vcd generated toggle rates. 90% of EPE designs (using .vcd generated toggle rates exported from PPPA) are within ±30% silicon. The toggle rates are derived using the PowerPlay Power Analyzer with a .vcd file generated from a gate level simulation representative of the system operation. © 2013 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are trademarks of Altera Corporation and registered in the U.S.
    [Show full text]
  • Publication Title 1-1962
    publication_title print_identifier online_identifier publisher_name date_monograph_published_print 1-1962 - AIEE General Principles Upon Which Temperature 978-1-5044-0149-4 IEEE 1962 Limits Are Based in the rating of Electric Equipment 1-1969 - IEEE General Priniciples for Temperature Limits in the 978-1-5044-0150-0 IEEE 1968 Rating of Electric Equipment 1-1986 - IEEE Standard General Principles for Temperature Limits in the Rating of Electric Equipment and for the 978-0-7381-2985-3 IEEE 1986 Evaluation of Electrical Insulation 1-2000 - IEEE Recommended Practice - General Principles for Temperature Limits in the Rating of Electrical Equipment and 978-0-7381-2717-0 IEEE 2001 for the Evaluation of Electrical Insulation 100-2000 - The Authoritative Dictionary of IEEE Standards 978-0-7381-2601-2 IEEE 2000 Terms, Seventh Edition 1000-1987 - An American National Standard IEEE Standard for 0-7381-4593-9 IEEE 1988 Mechanical Core Specifications for Microcomputers 1000-1987 - IEEE Standard for an 8-Bit Backplane Interface: 978-0-7381-2756-9 IEEE 1988 STEbus 1001-1988 - IEEE Guide for Interfacing Dispersed Storage and 0-7381-4134-8 IEEE 1989 Generation Facilities With Electric Utility Systems 1002-1987 - IEEE Standard Taxonomy for Software Engineering 0-7381-0399-3 IEEE 1987 Standards 1003.0-1995 - Guide to the POSIX(R) Open System 978-0-7381-3138-2 IEEE 1994 Environment (OSE) 1003.1, 2004 Edition - IEEE Standard for Information Technology - Portable Operating System Interface (POSIX(R)) - 978-0-7381-4040-7 IEEE 2004 Base Definitions 1003.1, 2013
    [Show full text]
  • DIGITAL COMMUNICATION and CONTROL CIRCUITS for 60Ghz
    DIGITAL COMMUNICATION AND CONTROL CIRCUITS FOR 60GHz FULLY INTEGRATED CMOS DIGITAL RADIO A Thesis Presented to The Academic Faculty by Gopal B. Iyer In Partial Fulfillment of Requirements for the Degree Master of Science in School of Electrical and Computer Engineering Georgia Institute of Technology May 2010 COPYRIGHT © 2010 BY GOPAL B. IYER DIGITAL COMMUNICATION AND CONTROL CIRCUITS FOR 60GHz FULLY INTEGRATED CMOS DIGITAL RADIO Approved by: Dr. Joy Laskar, Advisor School of Electrical and Computer Engineering Georgia Institute of Technology Dr. Saibal Mukhopadhyay School of Electrical and Computer Engineering Georgia Institute of Technology Dr. Manos Tentzeris School of Electrical and Computer Engineering Georgia Institute of Technology Date Approved: 2nd April 2010 I dedicate all my research work and the culmination, this thesis: to my Mom, Dad, my sisters, Sheela and Sheetal my brother-in-law, Vinayak, and to the apple of my eye, my nephew, Vivek ACKNOWLEDGEMENTS I would like to thank my advisor Dr. Joy Laskar for his inspiring leadership and guidance throughout the course of my research project. I would also like to express my gratitude to Dr. Saibal Mukhopadhyay and Dr. Manos Tentzeris for taking the time and serving on my reading committee. I wish to acknowledge Dr Stephane Pinel and Dr. Bevin Perumana for providing excellent technical guidance in helping me complete my research work. In particular I would like to thank Dr. Bevin Perumana, for mentoring me in the art of Mixed Signal Design. I wish to thank Dr. Padmanava Sen and Dr. Saikat Sarkar for their constant support and valuable friendship. I take this opportunity to thank all the team members of the Millimeter-Wave Applications Group, who have been a part of this Digital Radio Transceiver project.
    [Show full text]
  • DESIGN VERIFICATION of POWER MANAGEMENT UNIT and CLOCK GENERATION BLOCK of Wi-Fi Soc
    ISSN: 2278 – 909X International Journal of Advanced Research in Electronics and Communication Engineering (IJARECE) Volume 5, Issue 2, February 2016 DESIGN VERIFICATION OF POWER MANAGEMENT UNIT AND CLOCK GENERATION BLOCK OF Wi-Fi SoC Chandrahas Reddy.M1 and Sugandhi.k2 1 M.Tech .Vlsi Design, SRM University, Chennai, India 2Asst.Professor (Sr.G), Department of Electronics and Communication SRM University, Chennai, India. Abstract variants during this execution flow. A typical SOC may contains the cores like a It is all about the importance of processor or processor sub-system, a the system on chip and the typical processor bus, a peripheral bus, a bridge intellectual property design verification between the two buses, and many flow that is followed in the industry, peripheral devices such as data motivation behind this project and the transformation engines, data ports (e.g. time plan that was followed in the UARTs, MACs) and controllers (e.g., execution of project. DMA). The sub-systems included in a specific SOC depend on the intended The term “system on a chip”, or device and a series of tradeoffs and SOC really implies two things, the requirements, such as cost, form factor, product itself and the methodology used power, performance, and functionality. to design it. A SOC product integrates several sub-systems, many or all of The verification methodology of an which would’ve been separate discrete SOC flow includes the stimulation of chips in the past into a single chip. design by providing input stimuli through Depending on how tightly you restrict Testbench setup and verify that it the definition, a SOC may be only a functioning as per intended specifications single silicon die, or possibly many dies and this input stimulus exercises through a inside a single package.
    [Show full text]
  • Performed the Most Often. in FPGA Design Flow, Functional and Gate
    performed the most often. In FPGA design flow, functional and gate-level timing simulation is typically performed when designers suspect that there might be a mismatch between RTL and functional or gate-level timing simulation results, which can lead to an incorrect design. The mismatch can be caused for several reasons discussed in more detail in Tip #59. Note that the nomenclature of simulation types is not consistent. The same name, for instance “gate-level simulation”, can have slightly different meaning in simulation flows of different FPGA vendors. The situation is even more confusing in ASIC simulation flows, which have many more different simulation types, such as transistor-level, and dynamic simulation. The following figure shows simulation types designers can perform during Xilinx FPGA synthesis and physical implementation process. Figure 1: Simulation types Xilinx FPGA designers can perform simulation after each level of design transformation from the original RTL to the bitstream. The following example is a 12-bit OR gate implemented in Verilog. module sim_types(input [11:0] user_in, output user_out); assign user_out = |user_in; endmodule XST post-synthesis simulation model is implemented using LUT6 and LUT2 primitives, which are parts of Xilinx UNISIMS RTL simulation library. wire out, out1_14; LUT6 #( .INIT ( 64'hFFFFFFFFFFFFFFFE )) out1 ( .I0(user_in[3]), .I1(user_in[2]), .I2(user_in[5]), .I3(user_in[4]), .I4(user_in[7]), .I5(user_in[6]), .O(out)); LUT6 #( .INIT ( 64'hFFFFFFFFFFFFFFFE )) out2 ( .I0(user_in[9]), .I1(user_in[8]), .I2(user_in[11]), .I3(user_in[10]), .I4(user_in[1]), .I5(user_in[0]), .O(out1_14)); LUT2 #( .INIT ( 4'hE )) out3 ( .I0(out), .I1(out1_14), .O(user_out) ); Post-synthesis simulation model can be generated using the following command: $ netgen -w -ofmt verilog -sim sim.ngc post_synthesis.v Post-translate simulation model is implemented using X_LUT6 and X_LUT2 primitives, which are parts of Xilinx SIMPRIMS simulation library.
    [Show full text]
  • Verilog IEEE Standard 1364-2005
    IEEE Standard for Verilog® Hardware Description Language IEEE Computer Society Sponsored by the Design Automation Standards Committee I E E E 3 Park Avenue IEEE Std 1364™-2005 New York, NY 10016-5997, USA (Revision of IEEE Std 1364-2001) 7 April 2006 Authorized licensed use limited to: Bucknell University. Downloaded on June 12,2014 at 13:56:54 UTC from IEEE Xplore. Restrictions apply. Authorized licensed use limited to: Bucknell University. Downloaded on June 12,2014 at 13:56:54 UTC from IEEE Xplore. Restrictions apply. IEEE Std 1364™-2005 (Revision of IEEE Std 1364-2001) IEEE Standard for Verilog® Hardware Description Language Sponsor Design Automation Standards Committee of the IEEE Computer Society Abstract: The Verilog hardware description language (HDL) is defined in this standard. Verilog HDL is a formal notation intended for use in all phases of the creation of electronic systems. Be- cause it is both machine-readable and human-readable, it supports the development, verification, synthesis, and testing of hardware designs; the communication of hardware design data; and the maintenance, modification, and procurement of hardware. The primary audiences for this standard are the implementors of tools supporting the language and advanced users of the language. Keywords: computer, computer languages, digital systems, electronic systems, hardware, hard- ware description languages, hardware design, HDL, PLI, programming language interface, Verilog, Verilog HDL, Verilog PLI The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2006 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 7 April 2006. Printed in the United States of America.
    [Show full text]
  • Systemverilog – Unified Hardware Design, Specification, and Verification Language
    This is a preview - click here to buy the full publication IEC 62530 Edition 2.0 2011-05 INTERNATIONAL IEEE Std 1800™ STANDARD colour inside SystemVerilog – Unified Hardware Design, Specification, and Verification Language INTERNATIONAL ELECTROTECHNICAL COMMISSION PRICE CODE XX ICS 25.040 ISBN 978-2-88912-450-3 This is a preview - click here to buy the full publication This is a preview - click here to buy the full publication - i - IEC 62530:2011(E) IEEE Std 1800-2009 Contents Part One: Design and Verification Constructs 1. Overview.................................................................................................................................................... 2 1.1 Scope................................................................................................................................................ 2 1.2 Purpose............................................................................................................................................. 2 1.3 Merger of IEEE Std 1364-2005 and IEEE Std 1800-2005.............................................................. 3 1.4 Special terms.................................................................................................................................... 3 1.5 Conventions used in this standard.................................................................................................... 3 1.6 Syntactic description........................................................................................................................ 4
    [Show full text]
  • The Verilog PLI Is Dead (Maybe) -- Long Live the Systemverilog
    The Verilog PLI Is Dead (maybe) Long Live The SystemVerilog DPI! Stuart Sutherland Sutherland HDL, Inc. [email protected] ABSTRACT In old England, when one monarch died a successor immediately took the throne. Hence the chant, “The king is dead—long live the king!”. The Verilog Programming Language Interface (PLI) appears to be undergoing a similar succession, with the advent of the new SystemVerilog Direct Programming Interface (DPI). Is the old Verilog PLI dead, and the SystemVerilog DPI the new king? This paper addresses the question of whether engineers should continue to use the Verilog PLI, or switch to the new SystemVerilog DPI. The paper will show that the DPI can simplify interfacing to the C language, and has capabilities that are not possible with the PLI. However, the Verilog PLI also has unique capabilities that cannot be done using the DPI. Table of Contents 1.0 Introduction ............................................................................................................................2 2.0 An overview of the DPI .........................................................................................................2 3.0 Verilog PLI capabilities .........................................................................................................3 3.1 How the PLI calls C functions ..................................................................................... 3 3.2 The evolution of the Verilog PLI ................................................................................. 4 3.3 Verilog
    [Show full text]
  • Pre-Release Version (Fdis)
    This is a preview - click here to buy the full publication IEC 62530 ® Edition 3.0 2021-03 IEEE Std 1800™ PRE-RELEASE VERSION (FDIS) SystemVerilog – Unified Hardware Design, Specification, and Verification Language INTERNATIONAL ELECTROTECHNICAL COMMISSION ICS 25.040.01 Warning! Make sure that you obtained this publication from an authorized distributor. ® Registered trademark of the International Electrotechnical Commission This is a preview - click here to buy the full publication 91/1714/FDIS FINAL DRAFT INTERNATIONAL STANDARD (FDIS) PROJECT NUMBER: IEC 62530 ED3 DATE OF CIRCULATION: CLOSING DATE FOR VOTING: 2021-03-05 2021-04-16 SUPERSEDES DOCUMENTS: IEC TC 91 : ELECTRONICS ASSEMBLY TECHNOLOGY SECRETARIAT: SECRETARY: Japan Mr Masahide Okamoto OF INTEREST TO THE FOLLOWING COMMITTEES: HORIZONTAL STANDARD: FUNCTIONS CONCERNED: EMC ENVIRONMENT QUALITY ASSURANCE SAFETY SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING This document is a draft distributed for approval. It may not be referred to as an International Standard until published as such. In addition to their evaluation as being acceptable for industrial, technological, commercial and user purposes, Final Draft International Standards may on occasion have to be considered in the light of their potential to become standards to which reference may be made in national regulations. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. TITLE: SystemVerilog - Unified Hardware Design, Specification, and Verification Language (IEEE Std 1800-2017) PROPOSED STABILITY DATE: 2026 N OTE FROM TC/SC OFFICERS: This will be an IEC/IEEE dual-logo publication.
    [Show full text]
  • Fundamentals of Digital Logic with VHDL Design .-Mcgraw-Hill, 2000
    1 SYLLABUS FOR COURSE ADVANCED DIGITAL SYSTEMS (VHDL) Lecturer: Dr. Evgeni Perelroyzen Prerequisites for Course 1.Logic Circuits 2.Optimized Implementation of Logic Functions 3.Number Representation 4.Basic Combinational Circuits 5.Basic Sequential Circuits Detailed Teaching Plan 1. DESIGN CONCEPTS 1.1. Digital Hardware 1.1.1. Standard Chips - 7400-Series Standard Chips 1.1.2. Programmable Logic Devices - Programmable Logic Array (PLA) - Programmable Array Logic (PAL) - Programming of PLAs and PALs - Complex Programmable Logic Devices (CPLDs) - Field-Programmable Gate Arrays (FPGA) 1.1.3. Custom-Designed Chips 1.2. The Design Process [1, 5, 6] 1.2.1. Design Methodology. Top-Down Design(Flow) [5, 6, 9] 1.2.2. A Systematic Approach to Logic Design [5] 1.2.3. Verification [6, 9] - Summary of the different simulation alternatives [6] - Simulation Speed - Formal Verification - Recommendations for Verification 1.3. Design of Digital Hardware-Digital System Design Process [1, 9] 1.3.1. Basic Design Loop 1.3.2. Design of a Digital Hardware Unit 1.3.3. Overview of Digital Logic Design [5] 1.3.4. Overview of Combinational Circuit Design [5] 2 1.3.5. Overview of Sequential Circuit Design [5] 2. INTRODUCTION TO CAD TOOLS 2.1. Hardware Design Environments – Design Automation [9] 2.2. The Art of Modeling [9] 2.3. Design Entry 2.4. Hardware Simulation(Modeling Digital Systems) [1, 3, 6, 9] - Domains and Levels of Simulation(Modeling) [3] - Functional and Timing Simulation [1] - Oblivious Simulation [9] - Event-Driven Simulation [9] 2.5. Hardware Synthesis and Optimization [1, 9] 2.6. Physical Design 2.7.
    [Show full text]
  • FPGA Developement
    Department of Computer Science and Electrical Engineering CMPECMPE 415:415: FPGAFPGA DevelopmentDevelopment Prof. Ryan Robucci Illustrations snapshots are from the Design Warrior’s Guide to FPGAs by Clive Maxfield, Elsevier VocabVocab LessonLesson ● CAD: Computer Aided Design ● CAE: Computer Aided Engineering ● EDA: Electronic Design Automation ● Historically, – CAE refereed to front end tools like design capture and simulation – CAD refereed to backend tools like layout, place, and route – EDA was accepted as the merger of all topics HDLHDL ● As gate counts and designs became large, HDL replaced schematics since there was a need for a more, compact, more manageable description Level Type Description Algorithmic Functional High level functional description loops, Behavioral processes RTL Functional Description of registers and logic between them. Boolean Expressions and Registers implied by storage, This includes simple if structors Gate Structural Instantiations of primitive gates and registers Switch Structural Instantiations of Transistors Also called transistor level ASICASIC DesignDesign FlowFlow •Physical Constraints (e.g. Pin and Logic Placement) •Timing constraints Mask Logic Export Simulator Place and In-Circuit Design Gate-Level & Behavioral/ Synthesis Route Verifi- RTL Netlist Silicon Functional (PAR) Fab. cation Verification Post-Synthesis Circuit Gate-Level Extraction Functional Verification Back Annotation Delay Est. Standard Delay Format (SDF) Of key importance Post-PAR Verilog Used for are the length in Dynamic Netlist Timing Simulation Timing W/ Timing time of the Analysis design cycles. (Functional Sim Static w/ Timing) Timing Analysis FPGAFPGA DesignDesign FlowFlow •Physical Constraints Mapping (e.g. Pin and Logic Placement) •Timing constraints Packing Logic Simulator Place and Bitfile In-Circuit Design Generation Behavioral/ Synthesis Route Verifi- RTL Netlist and Functional (PAR) Program cation Verification Post-Synthesis Build Physical Gate-Level Circuit Desc.
    [Show full text]