DOCSLIB.ORG

DESIGN VERIFICATION of POWER MANAGEMENT UNIT and CLOCK GENERATION BLOCK of Wi-Fi Soc

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. Either way, a comprehensive set of test cases which SOC is rarely the entire system on that includes all scenarios those verifies the single chip, but it usually encompasses designed module for both functionality and the computing functions of the device. timing behavior. Index Terms : System on The primary focus in SOC chip(SOC),Silicon die. verification is on checking the integration between the various components. The Introduction underlying assumption is that each System On a Chip (SOC) is an component was already checked by itself. implementation technology and may have The combined complexity of the multiple many transformations and many different sub-systems can be huge, and there are 285 All Rights Reserved © 2016 IJARECE ISSN: 2278 – 909X International Journal of Advanced Research in Electronics and Communication Engineering (IJARECE) Volume 5, Issue 2, February 2016 many seemingly independent activities As shown in the design flow hardware part that need to be closely correlated. As a and software part will be segregated and result, we need a way to define they are developed in parallel. Design complicated test scenarios as well as engineers will develop RTL models from measure how well we exercise such specifications and also write test bench for scenarios and corner cases. their blocks. Verification engineers setup the verification environment like tool The reuse of many hardware IP blocks in a integration, scripts, etc. mix-and-match style suggests reuse of the verification components as well. Many Typical design verification flow consists companies treat their verification IP as a of following steps as design goes from valuable asset, sometimes valued even design entry to tapeout. more than the hardware IP. Typically, there are independent groups working on 1. Functional Verification the subsystems, thus both the challenges 2. Timing Verification and the possible benefits of creating 3. Physical Verification reusable verification components are 1.1.1 Functional Verification magnified. In functional verification, 1.1 TYPICAL SOC VERIFIACTION FLOW engineers checks correctness of all features specified in design and this is carry out by The SOC verification undergoes RTL simulations of design. In RTL many stages of verification during the simulations, set comprehensive test cases cycle of design. A typical flow of are driven through Testbench setup and verification starting from the specifications these test cases includes the sequences that to design sign off is shown in Figure 1.1. are required to verify the scenarios. After this the functionally verified design with error free is fed to synthesizer and this will generate gate level netlist for specified design technology. 1.1.2 Timing Verification RTL simulations are run without timing information and it is not capable of finding potential design issues due to timing violations. Timing verification is carryout on synthesized netlist and called gate level simulations with timing information files for different corner cases Figure 1.1 SoC Verification Flow called SDF. The netlist is nothing but gate 286 All Rights Reserved © 2016 IJARECE ISSN: 2278 – 909X International Journal of Advanced Research in Electronics and Communication Engineering (IJARECE) Volume 5, Issue 2, February 2016 level description of the design. False paths operating at higher speeds, the design has (FP) and multi-cycle-paths (MCP) are to be verify thoroughly for its timing exceptions that present a completeness and indeed functionality. So particularly difficult problem when trying it requires robust verification environment to achieve the timing closure for high- i.e. Testbench which need to be organize performance designs. Typically these to suit for most of the similar design i.e. exceptions (as well as all timing developing more generic environment constraints) are considered late in the gives the industry to produce more design cycle and are specified in response products in less time. to timing problems during verification. For optimum timing results, all timing The objective of work included: exceptions must be guaranteed to be 1.In a system-on-chip (SOC) design flow, correct. So any potential timing violations the designed behavioral model i.e. register those were not caught in STA can be transfer level (RTL) code undergoes caught in gate level simulations during several transformations before it goes to netlist verification. synthesis. During each transformation, the 1.1.3 Physical Verification design logical behavior needs to be verified for it‟s indeed functionality. Layout vs. Schematics (LVS), Design Rule Checking(DRC), Signal 2.The typical complex SoC contains integrity, etc. is covered in physical several components/blocks, that are having verification. In DRC all physical interconnection with each other and also measurements are verifies as per specified those will be used for the host interface. So design technology (e.g. TSMC 180nm, the functionality of these modules should UMC 65nm Technology, etc.). In LVS the be verified. developed layout is compared with 3.Perform gate level simulations with required schematic and their connections SDFs to verify any timing violations, with power supplies and interconnection functional aspects of synthesized design. between the cells. Finally designed RTL models are sent to fabrication and 4.Run the regressions periodically to know successive validation/testing will be percentage of verification coverage for carried out on raw chip to investigate the design. indeed functionality before sending them to customer. Deliverables included: 1. Development of comprehensive 1.2 MOTIVATION test scenarios for module level and chip As today SOC design technologies level to achieve zero bugs in design. becomes more and more complex design with more cores present on a single chip 287 All Rights Reserved © 2016 IJARECE ISSN: 2278 – 909X International Journal of Advanced Research in Electronics and Communication Engineering (IJARECE) Volume 5, Issue 2, February 2016 2. The developed test cases must functional aspects of block and also it cover/verify all the features specified in introduces the gate level simulation design requirement. methodology with SDF. 3. The test cases should ensure less Chapter 4 illustrates the basic debugging efforts with maximum functional behavior of PMU and Clock reusability for future IPs. Generation Block through obtained waveforms. The timing violations that Key tools to be used: were caught during GLS are also 1. Software: Linux, Cadence Ncsim explained though waveforms and the final simulator, Synopsys Novas debug regression status also presented in this Platform. chapter. 2. Languages: Perl, TCL, Verilog and Chapter 5 talks about the future VHDL. scope of the project and also the conclusions drawn from the results. 1.4 ORGANIZATION OF REPORT BACKGROUND THEORY This report is organized in to 5 chapters. This chapter gives a brief description Chapter 1 gives a brief introduction about Wi-Fi Technology and also gives about the importance of the system on chip brief introduction about 802.11 protocol and the typical intellectual property design standards and its classification. It also verification flow that is followed in the describes the typical architecture of a Wi- industry, motivation behind this project Fi SOC at chip level and briefly explains and the time plan that was followed in the about the components present in this chip execution of project. like MAC hardware, PHY core, JTAG, PMU, etc. Chapter 2 gives a brief description about Wi-Fi Technology and also gives Wi-Fi, known as a popular wireless brief introduction about 802.11 protocol networking technology uses radio waves to standards and its classification. It also provide high-speed
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]
  • 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.
    [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]
  • 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]