Verilator Manual (PDF)

Total Page:16

File Type:pdf, Size:1020Kb

Verilator Manual (PDF) Verilator Release 4.213 Wilson Snyder 2021-09-27 GETTING STARTED 1 Overview 1 2 Examples 2 2.1 Example C++ Execution.........................................2 2.2 Example SystemC Execution......................................3 2.3 Examples in the Distribution.......................................4 3 Installation 6 3.1 Package Manager Quick Install.....................................6 3.2 Git Quick Install.............................................6 3.3 Detailed Build Instructions........................................7 3.4 Verilator Build Docker Container.................................... 10 3.5 Verilator Executable Docker Container................................. 11 4 Verilating 13 4.1 C++ and SystemC Generation...................................... 13 4.2 Hierarchical Verilation.......................................... 14 4.3 Cross Compilation............................................ 15 4.4 Multithreading.............................................. 15 4.5 GNU Make................................................ 17 4.6 CMake.................................................. 17 5 Connecting to Verilated Models 20 5.1 Structure of the Verilated Model..................................... 20 5.2 Connecting to C++............................................ 21 5.3 Connecting to SystemC......................................... 22 5.4 Direct Programming Interface (DPI)................................... 22 5.5 Verification Procedural Interface (VPI)................................. 25 5.6 Wrappers and Model Evaluation Loop.................................. 26 5.7 Verilated and VerilatedContext...................................... 27 6 Simulating (Verilated-Model Runtime) 28 6.1 Benchmarking & Optimization..................................... 28 6.2 Coverage Analysis............................................ 29 6.3 Code Profiling.............................................. 31 6.4 Thread Profiling............................................. 31 6.5 Profiling ccache efficiency........................................ 33 6.6 Save/Restore............................................... 33 6.7 Profile-Guided Optimization....................................... 33 7 Contributing and Reporting Bugs 36 i 7.1 Announcements............................................. 36 7.2 Reporting Bugs.............................................. 36 7.3 Contributing to Verilator......................................... 37 8 FAQ/Frequently Asked Questions 39 8.1 Questions................................................. 39 9 Input Languages 47 9.1 Language Standard Support....................................... 47 9.2 Language Limitations.......................................... 48 9.3 Language Keyword Limitations..................................... 52 10 Language Extensions 54 11 Executable and Argument Reference 60 11.1 verilator Arguments........................................... 60 11.2 Configuration Files............................................ 79 11.3 verilator_coverage............................................ 82 11.4 verilator_gantt.............................................. 83 11.5 verilator_profcfunc............................................ 85 11.6 Simulation Runtime Arguments..................................... 85 12 Errors and Warnings 87 12.1 Disabling Warnings........................................... 87 12.2 Error And Warning Format........................................ 87 12.3 List Of Warnings............................................. 88 13 Files 106 13.1 Files in the Git Tree........................................... 106 13.2 Files Read/Written............................................ 106 14 Environment 109 15 Deprecations 111 16 Contributors and Origins 112 16.1 Authors.................................................. 112 16.2 Contributors............................................... 112 16.3 Historical Origins............................................ 113 17 Revision History 115 17.1 Revision History and Change Log.................................... 115 18 Copyright 190 ii CHAPTER ONE OVERVIEW Welcome to Verilator! The Verilator package converts Verilog1 and SystemVerilog2 hardware description language (HDL) designs into a C++ or SystemC model that after compiling can be executed. Verilator is not a traditional simulator, but a compiler. Verilator is typically used as follows: 1. The verilator executable is invoked with parameters similar to GCC, or other simulators such as Cadence Verilog-XL/NC-Verilog, or Synopsys VCS. Verilator reads the specified SystemVerilog code, lints it, optionally adds coverage and waveform tracing support, and compiles the design into a source level multithreaded C++ or SystemC “model”. The resulting model’s C++ or SystemC code is output as .cpp and .h files. This is referred to as “Verilating” and the process is “to Verilate”; the output is a “Verilated” model. 2. For simulation, a small user written C++ wrapper file is required, the “wrapper”. This wrapper defines the C++ standard function “main()” which instantiates the Verilated model as a C++/SystemC object. 3. The user C++ wrapper, the files created by Verilator, a “runtime library” provided by Verilator, and if applicable SystemC libraries are then compiled using a C++ compiler to create a simulation executable. 4. The resulting executable will perform the actual simulation, during “simulation runtime”. 5. If appropriately enabled, the executable may also generate waveform traces of the design that may be viewed. It may also create coverage analysis data for post-analysis. The best place to get started is to try the Examples. 1 Verilog is defined by the Institute of Electrical and Electronics Engineers (IEEE) Standard for Verilog Hardware Description Language, Std. 1364, released in 1995, 2001, and 2005. The Verilator documentation uses the shorthand e.g. “IEEE 1394-2005” to refer to the e.g. 2005 version of this standard. 2 SystemVerilog is defined by the Institute of Electrical and Electronics Engineers (IEEE) Standard for SystemVerilog - Unified Hardware Design, Specification, and Verification Language, Standard 1800, released in 2005, 2009, 2012, and 2017. The Verilator documentation uses the shorthand e.g. “IEEE 1800-2017” to refer to the e.g. 2017 version of this standard. 1 CHAPTER TWO EXAMPLES This section covers the following examples: • Example C++ Execution • Example SystemC Execution • Examples in the Distribution 2.1 Example C++ Execution We’ll compile this example into C++. For an extended and commented version of what this C++ code is doing, see examples/make_tracing_c/sim_main.cpp in the distribution. First you need Verilator installed, see Installation. In brief, if you installed Verilator using the package manager of your operating system, or did a make install to place Verilator into your default path, you do not need anything special in your environment, and should not have VERILATOR_ROOT set. However, if you installed Verilator from sources and want to run Verilator out of where you compiled Verilator, you need to point to the kit: # See above; don't do this if using an OS-distributed Verilator export VERILATOR_ROOT=/path/to/where/verilator/was/installed export PATH=$VERILATOR_ROOT/bin:$PATH Now, let’s create an example Verilog, and C++ wrapper file: mkdir test_our cd test_our cat >our.v <<'EOF' module our; initial begin $display("Hello World"); $finish; end endmodule EOF cat >sim_main.cpp <<'EOF' #include "Vour.h" #include "verilated.h" int main(int argc, char** argv, char** env) { VerilatedContext* contextp = new VerilatedContext; contextp->commandArgs(argc, argv); Vour* top = new Vour{contextp}; while (!contextp->gotFinish()) { top->eval(); } delete top; delete contextp; (continues on next page) 2 Verilator, Release 4.213 (continued from previous page) return 0; } EOF Now we run Verilator on our little example. verilator -Wall --cc --exe --build sim_main.cpp our.v Breaking this command down: 1. -Wall so Verilator has stronger lint warnings enabled. 2. --cc to get C++ output (versus e.g. SystemC or only linting). 3. --exe, along with our sim_main.cpp wrapper file, so the build will create an executable instead of only a library. 4. --build so Verilator will call make itself. This is we don’t need to manually call make as a separate step. You can also write your own compile rules, and run make yourself as we show in Example SystemC Execution.) 5. An finally, our.v which is our SystemVerilog design file. Once Verilator completes we can see the generated C++ code under the obj_dir directory. ls -l obj_dir (See Files Read/Written for descriptions of some of the files that were created.) And now we run it: obj_dir/Vour And we get as output: Hello World - our.v:2: Verilog $finish Really, you’re better off using a Makefile to run the steps for you so when your source changes it will automatically run all of the appropriate steps. To aid this Verilator can create a makefile dependency file. For examples that do this see the examples directory in the distribution. 2.2 Example SystemC Execution This is an example similar to the Example C++ Execution, but using SystemC. We’ll also explicitly run make. First you need Verilator installed, see Installation. In brief, if you installed Verilator using the package manager of your operating system, or did a make install to place Verilator into your default path, you do not need anything special in your environment, and should not have VERILATOR_ROOT set. However, if you installed Verilator from sources and want to run Verilator out of where you compiled Verilator,
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]
  • Development of Systemc Modules from HDL for System-On-Chip Applications
    University of Tennessee, Knoxville TRACE: Tennessee Research and Creative Exchange Masters Theses Graduate School 8-2004 Development of SystemC Modules from HDL for System-on-Chip Applications Siddhartha Devalapalli University of Tennessee - Knoxville Follow this and additional works at: https://trace.tennessee.edu/utk_gradthes Part of the Electrical and Computer Engineering Commons Recommended Citation Devalapalli, Siddhartha, "Development of SystemC Modules from HDL for System-on-Chip Applications. " Master's Thesis, University of Tennessee, 2004. https://trace.tennessee.edu/utk_gradthes/2119 This Thesis is brought to you for free and open access by the Graduate School at TRACE: Tennessee Research and Creative Exchange. It has been accepted for inclusion in Masters Theses by an authorized administrator of TRACE: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. To the Graduate Council: I am submitting herewith a thesis written by Siddhartha Devalapalli entitled "Development of SystemC Modules from HDL for System-on-Chip Applications." I have examined the final electronic copy of this thesis for form and content and recommend that it be accepted in partial fulfillment of the equirr ements for the degree of Master of Science, with a major in Electrical Engineering. Dr. Donald W. Bouldin, Major Professor We have read this thesis and recommend its acceptance: Dr. Gregory D. Peterson, Dr. Chandra Tan Accepted for the Council: Carolyn R. Hodges Vice Provost and Dean of the Graduate School (Original signatures are on file with official studentecor r ds.) To the Graduate Council: I am submitting herewith a thesis written by Siddhartha Devalapalli entitled "Development of SystemC Modules from HDL for System-on-Chip Applications".
    [Show full text]
  • Using the ELECTRIC VLSI Design System Version 9.07
    Using the ELECTRIC VLSI Design System Version 9.07 Steven M. Rubin Author's affiliation: Static Free Software ISBN 0−9727514−3−2 Published by R.L. Ranch Press, 2016. Copyright (c) 2016 Static Free Software Permission is granted to make and distribute verbatim copies of this book provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this book under the conditions for verbatim copying, provided also that they are labeled prominently as modified versions, that the authors' names and title from this version are unchanged (though subtitles and additional authors' names may be added), and that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this book into another language, under the above conditions for modified versions. Electric is distributed by Static Free Software (staticfreesoft.com), a division of RuLabinsky Enterprises, Incorporated. Table of Contents Chapter 1: Introduction.....................................................................................................................................1 1−1: Welcome.........................................................................................................................................1 1−2: About Electric.................................................................................................................................2 1−3: Running
    [Show full text]
  • A Fedora Electronic Lab Presentation
    Chitlesh GOORAH Design & Verification Club Bristol 2010 FUDConBrussels 2007 - [email protected] [ Free Electronic Lab ] (formerly Fedora Electronic Lab) An opensource Design and Simulation platform for Micro-Electronics A one-stop linux distribution for hardware design Marketing means for opensource EDA developers (Networking) From SPEC, Model, Frontend Design, Backend, Development boards to embedded software. FUDConBrussels 2007 - [email protected] Electronic Designers Problems Approx. 6 month design development cycle Tackling Design Complexity Lower Power, Lower Cost and Smaller Space Semiconductor Industry's neck squeezed in 2008 Management (digital/analog) IP Portfolio FUDConBrussels 2007 - [email protected] FUDConBrussels 2007 - [email protected] A basic Design Flow FUDConBrussels 2007 - [email protected] TIP: Use verilator to lint your verilog files. Most of the Veripool tools are available under FEL. They are in sync with Wilson Snyder's releases. FUDConBrussels 2007 - [email protected] FUDConBrussels 2007 - [email protected] GTKWaveGTKWave Don'tDon't forgetforget itsits TCLTCL backendbackend WidelyWidely usedused togethertogether withwith SystemCSystemC FUDConBrussels 2007 - [email protected] Tools Standard Cell libraries FUDConBrussels 2007 - [email protected] BackendBackend designdesign Open Circuit Design, Electric FUDConBrussels 2007 - [email protected], Toped gEDA/gafgEDA/gaf Well known and famous. A very good example of opensource
    [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]
  • Simulator for the RV32-Versat Architecture
    Simulator for the RV32-Versat Architecture João César Martins Moutoso Ratinho Thesis to obtain the Master of Science Degree in Electrical and Computer Engineering Supervisor(s): Prof. José João Henriques Teixeira de Sousa Examination Committee Chairperson: Prof. Francisco André Corrêa Alegria Supervisor: Prof. José João Henriques Teixeira de Sousa Member of the Committee: Prof. Marcelino Bicho dos Santos November 2019 ii Declaration I declare that this document is an original work of my own authorship and that it fulfills all the require- ments of the Code of Conduct and Good Practices of the Universidade de Lisboa. iii iv Acknowledgments I want to thank my supervisor, Professor Jose´ Teixeira de Sousa, for the opportunity to develop this work and for his guidance and support during that process. His help was fundamental to overcome the multiple obstacles that I faced during this work. I also want to acknowledge Professor Horacio´ Neto for providing a simple Convolutional Neural Net- work application, used as a basis for the application developed for the RV32-Versat architecture. A special acknowledgement goes to my friends, for their continuous support, and Valter,´ that is developing a multi-layer architecture for RV32-Versat. When everything seemed to be doomed he always had a miraculous solution. Finally, I want to express my sincere gratitude to my family for giving me all the support and encour- agement that I needed throughout my years of study and through the process of researching and writing this thesis. They are also part of this work. Thank you. v vi Resumo Esta tese apresenta um novo ambiente de simulac¸ao˜ para a arquitectura RV32-Versat baseado na ferramenta de simulac¸ao˜ Verilator.
    [Show full text]
  • Getting Started in High Performance Electronic Design
    Getting started in high performance electronic design Wojtek Skulski Department of Physics and Astronomy University of Rochester Rochester, NY 14627-0171 skulski _at_ pas.rochester.edu First presented May/23/2002 Updated for the web July/03/2004 Wojtek Skulski May/2002 Department of Physics and Astronomy, University of Rochester Getting started with High performance electronic design • 3-hour class • Designing high performance surface mount and multilayer boards. • What tools and resources are available? • How to get my design manufactured and assembled? • Board design with OrCAD Capture and Layout. • When and where: • Thursday, May/23/2002, 9-12am, Bausch&Lomb room 106 (1st floor). • Slides updated for the web July/03/2004. • Reserve your handout. • Send e-mail to [email protected] if you plan to attend. • Walk-ins are invited, but there may be no handouts if you do not register. • See you there! Wojtek Skulski May/2002 Department of Physics and Astronomy, University of Rochester The goal and outline of this class • Goal: • Describe the tools available to us for designing high performance electronic instruments. • Outline • Why do we need surface mount and multilayer boards? • What tools and resources are available? • How to get my PCB manufactured? • How to get my board assembled? • Designing with OrCAD Capture and OrCAD Layout. • The audience • You know the basics of electronics. • … and you need to get going quickly with your design. Wojtek Skulski May/2002 Department of Physics and Astronomy, University of Rochester Disclaimer • I am describing tools and methods which work for me. • I do not claim that this information is complete.
    [Show full text]
  • Making Things Move DIY Mechanisms for Inventors, Hobbyists, and Artists
    Making Things Move DIY Mechanisms for Inventors, Hobbyists, and Artists Dustyn Roberts New York Chicago San Francisco Lisbon London Madrid Mexico City Milan New Delhi San Juan Seoul Singapore Sydney Toronto Copyright © 2011 by The McGraw-Hill Companies. All rights reserved. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher. ISBN: 978-0-07-174168-2 MHID: 0-07-174168-2 The material in this eBook also appears in the print version of this title: ISBN: 978-0-07-174167-5, MHID: 0-07-174167-4. All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trade- marked name, we use names in an editorial fashion only, and to the benefi t of the trademark owner, with no intention of infringe- ment of the trademark. Where such designations appear in this book, they have been printed with initial caps. McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. To contact a representative please e-mail us at [email protected]. Information has been obtained by McGraw-Hill from sources believed to be reliable. However, because of the possibility of hu- man or mechanical error by our sources, McGraw-Hill, or others, McGraw-Hill does not guarantee the accuracy, adequacy, or completeness of any information and is not responsible for any errors or omissions or the results obtained from the use of such information.
    [Show full text]
  • FPGA-Accelerated Evaluation and Verification of RTL Designs
    FPGA-Accelerated Evaluation and Verification of RTL Designs Donggyu Kim Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2019-57 http://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-57.html May 17, 2019 Copyright © 2019, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. FPGA-Accelerated Evaluation and Verification of RTL Designs by Donggyu Kim A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Krste Asanovi´c,Chair Adjunct Assistant Professor Jonathan Bachrach Professor Rhonda Righter Spring 2019 FPGA-Accelerated Evaluation and Verification of RTL Designs Copyright c 2019 by Donggyu Kim 1 Abstract FPGA-Accelerated Evaluation and Verification of RTL Designs by Donggyu Kim Doctor of Philosophy in Computer Science University of California, Berkeley Professor Krste Asanovi´c,Chair This thesis presents fast and accurate RTL simulation methodologies for performance, power, and energy evaluation as well as verification and debugging using FPGAs in the hardware/software co-design flow. Cycle-level microarchitectural software simulation is the bottleneck of the hard- ware/software co-design cycle due to its slow speed and the difficulty of simulator validation.
    [Show full text]
  • Static Analysis to Improve RTL Verification
    Static Analysis to Improve RTL Verification Akash Agrawal Thesis submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Master of Science in Computer Engineering Michael Hsiao, Chair Haibo Zeng A. Lynn Abbott February 16, 2017 Blacksburg, Virginia Keywords: Static Analysis, ATPG, RTL, Reachability Analysis Copyright 2017, Akash Agrawal Static Analysis to Improve RTL Verification Akash Agrawal ABSTRACT Integrated circuits have traveled a long way from being a general purpose microprocessor to an application specific circuit. It has become an integral part of the modern era of technology that we live in. As the applications and their complexities are increasing rapidly every day, so are the sizes of these circuits. With the increase in the design size, the associated testing effort to verify these designs is also increased. The goal of this thesis is to leverage some of the static analysis techniques to reduce the effort of testing and verification at the register transfer level. Studying a design at register transfer level gives exposure to the relational information for the design which is inaccessible at the structural level. In this thesis, we present a way to generate a Data Dependency Graph and a Control Flow Graph out of a register transfer level description of a circuit description. Next, the generated graphs are used to perform relation mining to improve the test generation process in terms of speed, branch coverage and number of test vectors generated. The generated control flow graph gives valuable information about the flow of information through the circuit design.
    [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]
  • PROTEUS DESIGN SUITE Visual Designer Help COPYRIGHT NOTICE
    PROTEUS DESIGN SUITE Visual Designer Help COPYRIGHT NOTICE © Labcenter Electronics Ltd 1990-2019. All Rights Reserved. The Proteus software programs (Proteus Capture, PROSPICE Simulation, Schematic Capture and PCB Layout) and their associated library files, data files and documentation are copyright © Labcenter Electronics Ltd. All rights reserved. You have bought a licence to use the software on one machine at any one time; you do not own the software. Unauthorized copying, lending, or re-distribution of the software or documentation in any manner constitutes breach of copyright. Software piracy is theft. PROSPICE incorporates source code from Berkeley SPICE3F5 which is copyright © Regents of Berkeley University. Manufacturer’s SPICE models included with the software are copyright of their respective originators. The Qt GUI Toolkit is copyright © 2012 Digia Plc and/or its subsidiary(-ies) and licensed under the LGPL version 2.1. Some icons are copyright © 2010 The Eclipse Foundation licensed under the Eclipse Public Licence version 1.0. Some executables are from binutils and are copyright © 2010 The GNU Project, licensed under the GPL 2. WARNING You may make a single copy of the software for backup purposes. However, you are warned that the software contains an encrypted serialization system. Any given copy of the software is therefore traceable to the master disk or download supplied with your licence. Proteus also contains special code that will prevent more than one copy using a particular licence key on a network at any given time. Therefore, you must purchase a licence key for each copy that you want to run simultaneously. DISCLAIMER No warranties of any kind are made with respect to the contents of this software package, nor its fitness for any particular purpose.
    [Show full text]