Systemverilog Verification of Wishbone-Compliant Serial Peripheral Interface

Total Page:16

File Type:pdf, Size:1020Kb

Systemverilog Verification of Wishbone-Compliant Serial Peripheral Interface Rochester Institute of Technology RIT Scholar Works Theses 12-2017 SystemVerilog Verification of Wishbone-Compliant Serial Peripheral Interface Avinash Srinivasan [email protected] Follow this and additional works at: https://scholarworks.rit.edu/theses Recommended Citation Srinivasan, Avinash, "SystemVerilog Verification of Wishbone-Compliant Serial eripherP al Interface" (2017). Thesis. Rochester Institute of Technology. Accessed from This Master's Project is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. SystemVerilog Verification Of Wishbone-Compliant Serial Peripheral Interface by Avinash Srinivasan Graduate Paper Submitted in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering Approved by: Mr. Mark A. Indovina, Lecturer Graduate Research Advisor, Department of Electrical and Microelectronic Engineering Dr. Sohail A. Dianat, Professor Department Head, Department of Electrical and Microelectronic Engineering Department of Electrical and Microelectronic Engineering Kate Gleason College of Engineering Rochester Institute of Technology Rochester, New York December, 2017 I dedicate my work to my mentor Professor Mark Indovina, my father Srinivasan Krishnarao, mother Ratna Srinivasan, brother Abhishek, sister-in-law Swathi and friends for their support during my thesis. Declaration I hereby declare that except where specific reference is made to the work of others, that all content of this Graduate Paper is original and have not been submitted in whole or in part for consideration for any other degree or qualification in this, or any other University. This research project is the result of my own work and includes nothing which is the outcome of work done in collaboration, except where specifically indicated in the text. Avinash Srinivasan December 19, 2017 Acknowledgements I wholeheartedly thank my graduate advisor and mentor Professor Mark Indovina for his continued support, feedback, encouragement and guidance through out my graduate career and research. I also thank Dr. Dorin Patru and Dr. Jayanthi Venkataraman for their support and guidance through out my graduate career. Abstract Synchronous serial interfaces provide economical on-board communication between the processor, digital to analog and analog to digital converters, memory, and other build- ing blocks on the chip. A number of Integrated Circuit (IC) manufacturers develop and produce components that are compatible with serial interfaces. The common serial inter- faces include Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I2C), Universal Asynchronous Receiver Transmitter (UART), and Universal Serial Bus (USB). SPI is widely used and advantageous over other serial interfaces due to its features of simplicity, low cost, clock synchronous, and non-interrupting high-speed data transfer rate. SPI is the core controller of the design. An open source hardware computer bus Wishbone is selected as the host controller enabling parallel data exchange for faster communication. Both the hardware buses employ a master-slave configuration which makes the bus-interfacing easier. This research presents a verification environment using SystemVerilog for the SPI Mas- ter device. An existing design from Open Cores is re-used, described as per latest speci- fications in Verilog at the Register Transfer Level (RTL) and is in conformity with the design-reuse methodology. This paper provides an understanding of the verification, lay- ered test benches, Object-Oriented Technology (OOT), SystemVerilog, SPI features, SPI advantages, disadvantages, and applications, SPI data transmission and transfer formats, SPI registers, SPI sub-system and Wishbone-SPI architecture, and the test bench devel- opment methodology. The focus is to understand how OOT and SystemVerilog improve productivity and functional coverage in a verification environment by the use of different constructs, constrained-random techniques, coverage, and assertions. A test bench was developed to verify the SPI master core. Testbench components include a random trans- action generator, a Wishbone driver, an SPI master as the design under test, a receiver as the SPI slave, a monitor with tasks to monitor the host and the core, test cases, and a scoreboard to record metrics, assertions and store expected and actual data. Contents Contents v List of Figures ix List of Tablesx 1 Introduction1 1.1 Research Goals . .4 1.2 Contributions . .4 1.3 Organization . .4 2 Verification6 2.1 Overview . .6 2.1.1 Aspects . .7 2.1.1.1 Functional . .8 2.1.1.2 Timing . .8 2.1.1.3 Performance . .8 2.1.2 Methods . .8 2.1.2.1 Simulation-based . .9 2.1.2.2 Emulation-based . .9 2.1.2.3 Formal . .9 2.1.2.4 Semi-Formal . .9 2.1.2.5 Assertion-based . 10 2.1.2.6 Co-verification of Hardware and Software . 10 2.2 Verification Plan: A Layered Approach . 10 2.3 Benefits of a Layered Approach . 14 Contents vi 3 SystemVerilog 16 3.1 Object-Oriented Technology . 16 3.1.1 Overview . 16 3.1.1.1 Abstraction . 17 3.1.1.2 Encapsulation . 17 3.1.1.3 Inheritance . 17 3.1.1.4 Polymorphism . 17 3.1.2 Benefits . 17 3.2 SystemVerilog . 18 3.2.1 Overview . 18 3.2.2 Benefits . 18 4 Serial Peripheral and Wishbone Interface 20 4.1 Overview . 20 4.2 SPI Features . 21 4.2.1 Data Transfer and Addressing . 21 4.2.2 Synchronization . 22 4.2.3 Error Detection and Data Integrity . 22 4.2.4 Host-side interface . 22 4.2.5 Performance . 22 4.3 SPI Advantages, Disadvantages and Applications . 23 4.3.1 Advantages . 23 4.3.2 Disadvantages . 23 4.3.3 Applications . 23 4.4 SPI Interfaces . 24 4.4.1 Master Out Slave In (MOSI) . 25 4.4.2 Master In Slave Out (MISO) . 25 4.4.3 Slave Select (SS) . 25 4.4.4 Serial Clock (SCK) . 25 4.5 SPI Data Transfer Modes and Formats . 25 4.5.1 CPHA Equals Zero Transfer Format . 26 4.5.2 CPHA Equals One Transfer Format . 27 4.6 SPI Sub-System . 28 4.7 SPI Registers . 30 Contents vii 4.7.1 Data Direction Control Register . 30 4.7.2 Control Register . 31 4.7.3 Status Register . 32 4.8 Beginning and Ending SPI Transfers . 33 4.9 Wishbone Bus Interface . 33 4.10 System Architecture . 37 5 Testbench Methodology and Results 39 5.1 Testbench Methodology . 39 5.2 Testbench Components . 41 5.2.1 Interface . 41 5.2.2 Transaction . 41 5.2.3 Driver . 41 5.2.4 Monitor . 42 5.2.4.1 Wishbone Monitor . 42 5.2.4.2 SPI Monitor . 42 5.2.5 Scoreboard . 42 5.2.6 Environment . 42 5.2.7 Test Case . 43 5.2.8 Top-Level . 43 5.3 Testbench Results . 43 5.3.1 Design’s Area, Power and Module Hierarchy . 43 5.3.2 Code Methodology . 44 5.3.3 Wishbone and SPI Transaction Waveforms . 45 5.3.3.1 Wishbone Transactions to SPI devices . 45 5.3.3.2 SPI Master-Slave Communication . 46 6 Conclusion 48 6.1 Future Work . 48 References 50 I Source Code 54 I.1 Transactions . 54 I.2 Interface . 57 Contents viii I.3 Driver . 59 I.4 Scoreboard . 63 I.5 Monitor . 65 I.6 Environment . 69 I.7 Testcase . 70 I.8 Test . 71 I.9 Design Under Test . 72 I.9.1 Clock Generator . 72 I.9.2 Shift Register . 75 I.9.3 SPI Master . 92 I.9.4 SPI Slave . 103 List of Figures 2.1 Verification Strategies . .7 2.2 Signal and Command Layers . 11 2.3 Functional, Signal and Command Layers . 12 2.4 Scenario, Functional, Signal and Command Layers . 13 2.5 Complete Layered Testbench . 14 4.1 Processor-SPI Interaction . ..
Recommended publications
  • Systemverilog
    SystemVerilog ● Industry's first unified HDVL (Hw Description and Verification language (IEEE 1800) ● Major extension of Verilog language (IEEE 1364) ● Targeted primarily at the chip implementation and verification flow ● Improve productivity in the design of large gate-count, IP- based, bus-intensive chips Sources and references 1. Accellera IEEE SystemVerilog page http://www.systemverilog.com/home.html 2. “Using SystemVerilog for FPGA design. A tutorial based on a simple bus system”, Doulos http://www.doulos.com/knowhow/sysverilog/FPGA/ 3. “SystemVerilog for Design groups”, Slides from Doulos training course 4. Various tutorials on SystemVerilog on Doulos website 5. “SystemVerilog for VHDL Users”, Tom Fitzpatrick, Synopsys Principal Technical Specialist, Date04 http://www.systemverilog.com/techpapers/date04_systemverilog.pdf 6. “SystemVerilog, a design and synthesis perspective”, K. Pieper, Synopsys R&D Manager, HDL Compilers 7. Wikipedia Extensions to Verilog ● Improvements for advanced design requirements – Data types – Higher abstraction (user defined types, struct, unions) – Interfaces ● Properties and assertions built in the language – Assertion Based Verification, Design for Verification ● New features for verification – Models and testbenches using object-oriented techniques (class) – Constrained random test generation – Transaction level modeling ● Direct Programming Interface with C/C++/SystemC – Link to system level simulations Data types: logic module counter (input logic clk, ● Nets and Variables reset, ● enable, Net type,
    [Show full text]
  • IOTA: Detecting Erroneous I/O Behavior Via I/O Transaction Auditing
    Appears in the First Workshop on Compiler and Architectural Techniques for Application Reliability and Security (CATARS) In Conjunction with the 2008 International Conference on Dependable Systems and Networks (DSN 2008) Anchorage, Alaska, June 2008 IOTA: Detecting Erroneous I/O Behavior via I/O Transaction Auditing Albert Meixner and Daniel J. Sorin Duke University [email protected], [email protected] Abstract nosed, the system could suggest that the user or system The correctness of the I/O system—and thus the administrator replace this device. If a driver bug is diag- nosed, the bug can be reported and the driver can be correctness of the computer—can be compromised by restarted (which is often sufficient). If a security breach hardware faults, driver bugs, and security breaches in is diagnosed, the system can shutdown the driver under downloaded device drivers. To detect erroneous I/O suspicion and alert the user. In this work, we focus on behavior, we have developed I/O Transaction Auditing error detection, rather than diagnosis and recovery. (IOTA), which checks the high-level behavior of I/O Our error detection mechanism, I/O Transaction transactions. In an IOTA-protected system, the operat- Auditing (IOTA), uses end-to-end checking [13] of I/O ing system creates a signature of the I/O transactions it transactions. We define a transaction as a high-level, expects to occur and every I/O device computes a signa- semantically atomic I/O operation, such as sending an ture of the transactions it actually performs. By compar- Ethernet frame. A transaction represents the basic I/O ing these signatures, IOTA can discover erroneous operation for higher level OS services such as the file behavior in both the hardware and the software respon- system or network stack.
    [Show full text]
  • Gotcha Again More Subtleties in the Verilog and Systemverilog Standards That Every Engineer Should Know
    Gotcha Again More Subtleties in the Verilog and SystemVerilog Standards That Every Engineer Should Know Stuart Sutherland Sutherland HDL, Inc. [email protected] Don Mills LCDM Engineering [email protected] Chris Spear Synopsys, Inc. [email protected] ABSTRACT The definition of gotcha is: “A misfeature of....a programming language...that tends to breed bugs or mistakes because it is both enticingly easy to invoke and completely unexpected and/or unreasonable in its outcome. A classic gotcha in C is the fact that ‘if (a=b) {code;}’ is syntactically valid and sometimes even correct. It puts the value of b into a and then executes code if a is non-zero. What the programmer probably meant was ‘if (a==b) {code;}’, which executes code if a and b are equal.” (http://www.hyperdictionary.com/computing/gotcha). This paper documents 38 gotchas when using the Verilog and SystemVerilog languages. Some of these gotchas are obvious, and some are very subtle. The goal of this paper is to reveal many of the mysteries of Verilog and SystemVerilog, and help engineers understand the important underlying rules of the Verilog and SystemVerilog languages. The paper is a continuation of a paper entitled “Standard Gotchas: Subtleties in the Verilog and SystemVerilog Standards That Every Engineer Should Know” that was presented at the Boston 2006 SNUG conference [1]. SNUG San Jose 2007 1 More Gotchas in Verilog and SystemVerilog Table of Contents 1.0 Introduction ............................................................................................................................3 2.0 Design modeling gotchas .......................................................................................................4 2.1 Overlapped decision statements ................................................................................... 4 2.2 Inappropriate use of unique case statements ...............................................................
    [Show full text]
  • DESIGN of WISHBONE INTERFACED I2CMASTER CORE CONTROLLER USING VERILOG Ramesh Babu Dasara1, Y
    DESIGN OF WISHBONE INTERFACED I2CMASTER CORE CONTROLLER USING VERILOG Ramesh Babu Dasara1, Y. Chandra Sekhar Reddy2 1Pursuing M.tech, 2Assistant Professor, from Nalanda Institute of Engineering and Technology (NIET), Siddharth Nagar, Kantepudi village, Sattenepalli Mandal, Guntur Dist.,A.P. (India) ABSTRACT In this paper we are implementing one of the serial communication protocol called Inter integrated circuit (I2C) master controller. The protocol is made of set of standards with the master and slave configuration to allow data transfer. The I2C master with wishbone controller is implemented in Verilog HDL. The modules are synthesized in Xilinx 13.2i. Then simulated to observe the operation of the Master controller and wishbone controller which performs high speed data transfer in presence of master or slave. This yields higher speed data transfer over the network. Keywords: Master,Wishbone, SDA,SCK,SLAVE I. INTRODUCTION In electronic world to make communication between any two digital hardware devices needs serial communication standards. There are several communication standards are RS232, RS435, and SPI to make high speed and low speed data transfer. To implement protocols actually we require more number of pin connections, whereas the size of IC gradually decreasing so we need a protocol that can have minimum number of pin connections. The protocols existed earlier are SPI, MOCROWIRE and USB needs point to point connection such that needs multiplexing of data and address. The proposed protocol requires only two lines two communicate with nay number of devices while other needs more number of pin connections. The I2c is best suited for medium range communication between the circuit boards within the equipment.
    [Show full text]
  • Open Borders for System-On-A-Chip Buses: a Wire Format for Connecting Large Physics Controls
    PHYSICAL REVIEW SPECIAL TOPICS - ACCELERATORS AND BEAMS 15, 082801 (2012) Open borders for system-on-a-chip buses: A wire format for connecting large physics controls M. Kreider,1,2 R. Ba¨r,1 D. Beck,1 W. Terpstra,1 J. Davies,2 V. Grout,2 J. Lewis,3 J. Serrano,3 and T. Wlostowski3 1GSI Helmholtz Centre for Heavy Ion Research, Darmstadt, Germany 2Glyndwˆ r University, Wrexham, United Kingdom 3CERN, Geneva, Switzerland (Received 27 January 2012; published 23 August 2012) System-on-a-chip (SoC) bus systems are typically confined on-chip and rely on higher level compo- nents to communicate with the outside world. The idea behind the EtherBone (EB) protocol is to extend the reach of the SoC bus to remote field-programmable gate arrays or processors. The EtherBone core implementation connects a Wishbone (WB) Ver. 4 Bus via a Gigabit Ethernet based network link to remote peripheral devices. EB acts as a transparent interconnect module towards attached WB Bus devices. EB was developed in the scope of the WhiteRabbit Timing Project at CERN and GSI/FAIR. WhiteRabbit will make use of EB as a means to issue commands to its timing nodes and control connected accelerator hardware. DOI: 10.1103/PhysRevSTAB.15.082801 PACS numbers: 84.40.Ua, 29.20.Àc, 07.05.Àt systems hosted inside a field-programmable gate array I. PURPOSE AND ENVIRONMENT (FPGA). EtherBone was named after these underlying This article builds on the paper by the title ‘‘EtherBone—A technologies, Ethernet and Wishbone. However, EB re- network Layer for the Wishbone SoC Bus’’ in the sides in the Open Systems Interconnection session layer ICALEPCS 2011 conference proceedings and aims to pro- (OSI layer 5) and does not depend on a specific choice of vide details on design choices and performance analysis for lower layer protocols in implementation.
    [Show full text]
  • Yikes! Why Is My Systemverilog Still So Slooooow?
    DVCon-2019 San Jose, CA Voted Best Paper 1st Place World Class SystemVerilog & UVM Training Yikes! Why is My SystemVerilog Still So Slooooow? Cliff Cummings John Rose Adam Sherer Sunburst Design, Inc. Cadence Design Systems, Inc. Cadence Design System, Inc. [email protected] [email protected] [email protected] www.sunburst-design.com www.cadence.com www.cadence.com ABSTRACT This paper describes a few notable SystemVerilog coding styles and their impact on simulation performance. Benchmarks were run using the three major SystemVerilog simulation tools and those benchmarks are reported in the paper. Some of the most important coding styles discussed in this paper include UVM string processing and SystemVerilog randomization constraints. Some coding styles showed little or no impact on performance for some tools while the same coding styles showed large simulation performance impact. This paper is an update to a paper originally presented by Adam Sherer and his co-authors at DVCon in 2012. The benchmarking described in this paper is only for coding styles and not for performance differences between vendor tools. DVCon 2019 Table of Contents I. Introduction 4 Benchmarking Different Coding Styles 4 II. UVM is Software 5 III. SystemVerilog Semantics Support Syntax Skills 10 IV. Memory and Garbage Collection – Neither are Free 12 V. It is Best to Leave Sleeping Processes to Lie 14 VI. UVM Best Practices 17 VII. Verification Best Practices 21 VIII. Acknowledgment 25 References 25 Author & Contact Information 25 Page 2 Yikes! Why is
    [Show full text]
  • A Syntax Rule Summary
    A Syntax Rule Summary Below we present the syntax of PSL in Backus-Naur Form (BNF). A.1 Conventions The formal syntax described uses the following extended Backus-Naur Form (BNF). a. The initial character of each word in a nonterminal is capitalized. For ex- ample: PSL Statement A nonterminal is either a single word or multiple words separated by underscores. When a multiple word nonterminal containing underscores is referenced within the text (e.g., in a statement that describes the se- mantics of the corresponding syntax), the underscores are replaced with spaces. b. Boldface words are used to denote reserved keywords, operators, and punc- tuation marks as a required part of the syntax. For example: vunit ( ; c. The ::= operator separates the two parts of a BNF syntax definition. The syntax category appears to the left of this operator and the syntax de- scription appears to the right of the operator. For example, item (d) shows three options for a Vunit Type. d. A vertical bar separates alternative items (use one only) unless it appears in boldface, in which case it stands for itself. For example: From IEEE Std.1850-2005. Copyright 2005 IEEE. All rights reserved.* 176 Appendix A. Syntax Rule Summary Vunit Type ::= vunit | vprop | vmode e. Square brackets enclose optional items unless it appears in boldface, in which case it stands for itself. For example: Sequence Declaration ::= sequence Name [ ( Formal Parameter List ) ]DEFSYM Sequence ; indicates that ( Formal Parameter List ) is an optional syntax item for Sequence Declaration,whereas | Sequence [*[ Range ] ] indicates that (the outer) square brackets are part of the syntax, while Range is optional.
    [Show full text]
  • UVM Based Reusable Verification IP for Wishbone Compliant SPI Master
    UVM Based Reusable Verification IP for Wishbone Compliant SPI Master Core Lakhan Shiva Kamireddy∗, Lakhan Saiteja Ky ∗VLSI CAD Research Group, Department of Electrical and Computer Engineering, University of Colorado Boulder, CO 80303, USA, Email: [email protected] yDepartment of Electronics and Electrical Communication Engineering, Indian Institute of Technology Kharagpur West Bengal 721302, India, Email: [email protected] Abstract—The System on Chip design industry relies heavily ming, coverage analysis, constrained randomization and as- on functional verification to ensure that the designs are bug- sertion based VIP. A methodological approach for verification free. As design engineers are coming up with increasingly dense increases the efficiency and reduces the verification effort. In chips with much functionality, the functional verification field has advanced to provide modern verification techniques. In this paper, we use UVM, a System Verilog based methodology this paper, we present verification of a wishbone compliant for testing an SPI master core that is wishbone compliant. Serial Peripheral Interface (SPI) Master core using a System The paper is organized into the following sections: Section Verilog based standard verification methodology, the Universal II introduces the key features of SV and UVM environment. Verification Methodology (UVM). By making use of UVM factory In Section-III, we introduce the SPI Master IP core for pattern with parameterized classes, we have developed a robust and reusable verification IP. SPI is a full duplex communication which the UVM framework is developed. Section-IV presents protocol used to interface components most likely in embedded our approach towards the development of UVM based VIP. systems. We have verified an SPI Master IP core design that Simulation results with snapshots and a critical discussion of is wishbone compliant and compatible with SPI protocol and the limitations of the design are presented in Section-V.
    [Show full text]
  • Wishbone Bus Architecture – a Survey and Comparison
    International Journal of VLSI design & Communication Systems (VLSICS) Vol.3, No.2, April 2012 WISHBONE BUS ARCHITECTURE – A SURVEY AND COMPARISON Mohandeep Sharma 1 and Dilip Kumar 2 1Department of VLSI Design, Center for Development of Advanced Computing, Mohali, India [email protected] 2ACS - Division, Center for Development of Advanced Computing, Mohali, India [email protected] ABSTRACT The performance of an on-chip interconnection architecture used for communication between IP cores depends on the efficiency of its bus architecture. Any bus architecture having advantages of faster bus clock speed, extra data transfer cycle, improved bus width and throughput is highly desirable for a low cost, reduced time-to-market and efficient System-on-Chip (SoC). This paper presents a survey of WISHBONE bus architecture and its comparison with three other on-chip bus architectures viz. Advanced Microcontroller Bus Architecture (AMBA) by ARM, CoreConnect by IBM and Avalon by Altera. The WISHBONE Bus Architecture by Silicore Corporation appears to be gaining an upper edge over the other three bus architecture types because of its special performance parameters like the use of flexible arbitration scheme and additional data transfer cycle (Read-Modify-Write cycle). Moreover, its IP Cores are available free for use requiring neither any registration nor any agreement or license. KEYWORDS SoC buses, WISHBONE Bus, WISHBONE Interface 1. INTRODUCTION The introduction and advancement of multimillion-gate chips technology with new levels of integration in the form of the system-on-chip (SoC) design has brought a revolution in the modern electronics industry. With the evolution of shrinking process technologies and increasing design sizes [1], manufacturers are integrating increasing numbers of components on a chip.
    [Show full text]
  • JTAG Simulation VIP Datasheet
    VIP Datasheet Simulation VIP for JTAG Provides JTAG and cJTAG support Overview Cadence® Simulation VIP is the world’s most widely used VIP for digital simulation. Hundreds of customers have used Cadence VIP to verify thousands of designs, from IP blocks to full systems on chip (SoCs). The Simulation VIP is ready-made for your environment, providing consistent results whether you are using Cadence Incisive®, Synopsys VCS®, or Mentor Questa® simulators. You have the freedom to build your testbench using any of these verification languages: SystemVerilog, e, Verilog, VHDL, or C/C++. Cadence Simulation VIP supports the Universal Verification Methodology (UVM) as well as legacy methodologies. The unique flexible architecture of Cadence VIP makes this possible. It includes a multi-language testbench interface with full access to the source code to make it easy to integrate VIP with your testbench. Optimized cores for simulation and simulation-acceleration allow you to choose the verification approach that best meets your objectives. Deliverables Specification Support People sometimes think of VIP as just a bus functional model The JTAG VIP supports the JTAG Protocol v1.c from 2001 as (BFM) that responds to interface traffic. But SoC verification defined in the JTAG Protocol Specification. requires much more than just a BFM. Cadence Simulation VIP components deliver: • State machine models incorporate the subtle features of Supported Design-Under-Test Configurations state machine behavior, such as support for multi-tiered, Master Slave Hub/Switch power-saving modes Full Stack Controller-only PHY-only • Pre-programmed assertions that are built into the VIP to continuously watch simulation traffic to check for protocol violations.
    [Show full text]
  • Systemverilog for VHDL Users
    SystemVerilog for VHDL Users Tom Fitzpatrick Principal Technical Specialist Synopsys, Inc. Agenda • Introduction • SystemVerilog Design Features • SystemVerilog Assertions • SystemVerilog Verification Features • Using SystemVerilog and VHDL Together 2 SystemVerilog Charter • Charter: Extend Verilog IEEE 2001 to higher abstraction levels for Architectural and Algorithmic Design , and Advanced Verification. Advanced Transaction-Level V g e verification capability Full Testbench lo h A r ri c sse ilo for semiformal and Language with e en g b rt formal methods. Coverage V t io es n The Assertion T IEEE Verilog Language Standard For Verilog A I r V 2001 P c e A Design h r e i il & c Abstraction: te o fa c g I r Direct C interface, tu e Interface r DP t a n Assertion API and l I semantics, abstract Coverage API data types, abstract operators and expressions 3 SystemVerilog: Verilog 1995 Event handling Basic datatypes (bit, int, reg, wire…) Verilog-95: 4 state logic Basic programming (for, if, while,..) Single language Hardware concurrency Gate level modelling for design & design entity modularization and timing testbench Switch level modeling and timing ASIC timing 4 SystemVerilog: VHDL Operator VHDL adds Packages Overloading higher level Dynamic Simple assertions pointers data types and Architecture memory configuration management User-defined types allocation records/ functionality enums Dynamic multi-D arrays structs hardware generation Automatic variables Signed numbers Strings Event handling Basic datatypes (bit, int, reg, wire…) 4 state logic Basic programming (for, if, while,..) Hardware concurrency Gate level modelling design entity modularization and timing Switch level modeling and timing ASIC timing 5 Semantic Concepts: C Associative Operator Overloading & Sparse arrays Packages pointers Further programming Dynamic Void type (do while, memory break, continue, allocation Unions records/ ++, --, +=.
    [Show full text]
  • (DFT) Architecture and It's Verification Using Universal Verification Methodology
    Rochester Institute of Technology RIT Scholar Works Theses 12-2019 Design of an Efficient Design forest T (DFT) Architecture and it's Verification Using Universal Verification Methodology Sushmitha Mavuram [email protected] Follow this and additional works at: https://scholarworks.rit.edu/theses Recommended Citation Mavuram, Sushmitha, "Design of an Efficient Design forest T (DFT) Architecture and it's Verification Using Universal Verification Methodology" (2019). Thesis. Rochester Institute of Technology. Accessed from This Master's Project is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. DESIGN OF AN EFFICIENT DESIGN FOR TEST (DFT) ARCHITECTURE AND IT’S VERIFICATION USING UNIVERSAL VERIFICATION METHODOLOGY by Sushmitha Mavuram GRADUATE PAPER Submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in Computer Engineering Approved by: Mr. Mark A. Indovina, Graduate Research Advisor Senior Lecturer, Department of Electrical and Microelectronic Engineering Dr. Marcin Lukowiak, Committee Member Professor, Department of Computer Engineering Dr. Amlan Ganguly, Department Head Professor, Department of Computer Engineering DEPARTMENT OF COMPUTER ENGINEERING KATE GLEASON COLLEGE OF ENGINEERING ROCHESTER INSTITUTE OF TECHNOLOGY ROCHESTER,NEW YORK DECEMBER, 2019 I dedicate this work to my mother Surekha, my father Jithender and my friends, for their support and encouragement throughout my master’s program at Rochester Institute of Technology. Declaration I hereby declare that all the contents of this graduate project paper are original, except where specific references are made to the work of others.
    [Show full text]