DOCSLIB.ORG

VHDL Testbench Techniques That Leapfrog Systemverilog

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
VHDL Testbench Techniques That Leapfrog Systemverilog VHDL Testbench Techniques that Leapfrog SystemVerilog by Jim Lewis VHDL Training Expert at SynthWorks IEEE 1076 Working Group Chair OSVVM Chief Architect [email protected] SynthWorks SynthWorks VHDL Testbench Techniques Copyright © 2013 by SynthWorks Design Inc. Reproduction of this entire document in whole for individual usage is permitted. All other rights reserved. In particular,without express written permission of SynthWorks Design Inc, You may not alter, transform, or build upon this work, You may not use any material from this guide in a group presentation, tutorial, training, or classroom You must include this page in any printed copy of this document. This material is derived from SynthWorks' class, VHDL Testbenches and Verification This material is updated from time to time and the latest copy of this is available at http://www.SynthWorks.com/papers Contact Information Jim Lewis, President SynthWorks Design Inc 11898 SW 128th Avenue Tigard, Oregon 97223 503-590-4787 [email protected] www.SynthWorks.com 2 SynthWorks VHDL Testbench Techniques O Goals: Thorough, Timely, and Readable Testing O Agenda O Testbench Architecture O Transactions O Writing Tests O Randomization O Functional Coverage O Constrained Random is Too Slow! O Intelligent Coverage is More Capable O Coverage Closure is Faster with Intelligent Coverage O Self-Checking & Scoreboards O Scoreboards O Dispelling FUD 3 SynthWorks Testbench Architecture O Historically a separate testbench is written for different levels of testing RTL Stim UartCmd Core Stim UART UartCmd Uart … System Stim Memio CpuIf UART UartCmd Uart … O Each testbench slightly larger than the previous. 4 SynthWorks Testbench Architecture O Many interfaces transport the same information TB_System Stim Model Memio CpuIf UART UartCmd Uart … O Change from RTL to Core to System by: O Separating stimulus from interface signaling (signal wiggling) O Changing the Model (changes signal wiggling) O Changing the connections (via VHDL-2008 external names) O Leave items not used in a test unbound or use a dummy architecture O Reduction in number of testbenches can minimize wasted effort. O But we need to plan from the System level 5 SynthWorks Testbench Architecture TbMemIO TestCtrl TestCtrl Entity Test1 CPU DUT: MemIO UartRx Architecture Model Model Test2 Clock & CpuIf MemIf UartTx Architecture Reset Model IntCtrl UART . Timer SRAM TestN Model Architecture O System / Chip Level Testbench O TLM (transaction level model) implements signaling to DUT O TestCtrl to sequence and/or synchronize models O Each test is a separate architecture of TestCtrl O Plan to pre-use system level models for Core and RTL tests 6 SynthWorks Transactions O Interface Operations, ie: CpuWrite, CpuRead, … O Essential for reuse and pre-use O 2 Aspects: Initiation (stimulus) and Implementation (model) Clk nReset nAds Read Addr Invalid ADDR0 ADDR0 Invalid Data Invalid D1 D1 Inv nRdy CpuWrite CpuRead 7 SynthWorks Transaction Initiation O Writing tests by wiggling signals is slow, error prone, and inhibits reuse -- CPU Write nAds <= '0' after tpd, '1' after tperiod + tpd ; Addr <= ADDR0 after tpd ; Data <= X"A5A5" after tperiod + tpd ; Wr_nRd <= '0' after tpd ; wait until nRdy = '0' and rising_edge(Clk) ; O Transaction initiation using procedures: . CpuWrite(CpuRec, ADDR0, X"A5A5"); CpuRead (CpuRec, ADDR0, DataO); . O Simplifies writing tests. O Increases readability and maintainability 8 SynthWorks Transaction Implementation O Implement transactions using either Subprograms or Entities O Subprograms do both O Transaction initiation by calling the subprogram O Transaction implementation (signal wiggling) internal to subprogram procedure CpuWrite ( signal CpuRec : InOut CpuRecType ; constant AddrI : In std_logic_vector; constant DataI : In std_logic_vector ) is begin CpuRec.nAds <= '0' after tpd, '1' after tperiod + tpd ; CpuRec.Addr <= AddrI after tpd ; CpuRec.Data <= DataI after tperiod + tpd ; CpuRec.Wr_nRd <= '1' after tpd ; wait until CpuRec.nRdy = '0' and rising_edge(CpuRec.Clk); end procedure ; O Use a package to separate the stimulus from implementation (model) 9 SynthWorks Transaction Implementation O Entities + O Transaction initiation by calling the subprogram O Transaction implementation (signal wiggling) done by entity TestCtrl CpuModel DUT CpuRec CpuBus CpuTestProc CpuWrite(...) CpuRead(...) O Advantages of Entity Approach O Model is concurrent O Implement it with either behavioral or RTL code O Keeps functionality, protocol checkers, timing checkers, result loggers in the same model O Ok for some interfaces to use Entity and others to use Subprograms 10 SynthWorks Transaction Interface O Records simplify interface between subprogram and DUT or model O Simplify updates O Can use 1 record with resolved types type Model1RecType is record CmdRdy : std_logic ; CmdAck : std_logic ; UnsignedToModel : unsigned(15 downto 0) ; UnsignedFromModel : unsigned(15 downto 0) ; IntegerToModel : resolved integer ; IntegerFromModel : resolved integer ; TimeToModel : resolved time ; RealToModel : resolved real ; end record ; O Can use 2 records O 1 to the DUT from the model and 1 to the model from the DUT O Increases number of signals on subprogram interface 11 SynthWorks Writing Tests O Tests can be either: O Directed - particularly good for testing registers O Algorithmic - particularly good for math O File Based - large or existing data sets (Images, Matlab, …) O Constrained Random O Intelligent Coverage O Not one approach works for everything. O Use of a transaction based framework simplifies mixing of test types. 12 SynthWorks Writing Tests O TestCtrl specifies transactions for each model O Controls, coordinates, and synchronizes test activities TestCtrl TbMemIO TestCtrlTestCtrl CpuTestProc CpuRec CpuWrite(...) CpuModel CPU Bus CpuRead(...) UartTxRec UartTbTxProc Serial Data UartSend(...) UartTxBfm to DUT UartTbRxProc UartRxRec Serial Data UartCheck() UartRxBfm from DUT 13 SynthWorks Writing Tests architecture Test1 of TestCtrl is begin CpuTestProc : process begin Tests are a separate architecture wait until nReset = '1' ; of TestCtrl (TestCtrl_UartRx1.vhd, CpuWrite(. .) ; TestCtrl_UartRx2.vhd, …) CpuRead(. .) ; . end process ; One or more processes for each UartTbTxProc : process independent source of stimulus begin WayPointBlock(SyncPoint) ; Interface Stimulus is generated UartSend(. .) ; . with one or more procedure calls end process ; UartTbRxProc : process Synchronize processes using begin handshaking UartCheck(. .) ; . end process ; end Test1 ; 1414 SynthWorks OSVVM & Writing Tests O Open Source VHDL Verification Methodology O Packages + Methodology for: O Constrained Random (CR) O Functional Coverage (FC) O Intelligent Coverage - Random test generation using FC holes O Key Benefits O Works in any VHDL testbench O Mixes well with other approaches (directed, algorithmic, file, random) O Recommended to be use with transaction based testbenches O Readable by All (in particular RTL engineers) O Low cost solution to leading edge verification O Packages are FREE O Works with regular VHDL simulators 15 SynthWorks Why Randomize? O Directed test of a FIFO (tracking words in FIFO): O Constrained Random test of a FIFO: O Randomization O Is ideal for large variety of similar items O Modes, processor instructions, … network packets. O Generates realistic stimulus in a timely fashion (to write) O Is more thorough since stimulus is not ordered (not looping) 16 SynthWorks Randomization in OSVVM O Randomize a value in an inclusive range, 0 to 15, except 5 & 11 Data1 := RV.RandInt(Min => 0, Max => 15) ; Data2 := RV.RandInt(0, 15, (5,11) ); -- except 5 & 11 O Randomize a value within the set (1, 2, 3, 5, 7, 11), except 5 & 11 Data3 := RV.RandInt( (1,2,3,5,7,11) ); Data4 := RV.RandInt( (1,2,3,5,7,11), (5,11) ); O Weighted Randomization: Weight, Value = 0 .. N-1 Data5 := RV.DistInt ( (7, 2, 1) ) ; O Weighted Randomization: Value + Weight . -- ((val1, wt1), (val2, wt2), ...) Data6 := RV.DistValInt( ((1,7), (3,2), (5, 1)) ); O By itself, this is not constrained random. 17 SynthWorks Randomization in OSVVM O Code patterns create constraints for CR tests O Randomize values, transactions, and sequences of transactions O Example: Weighted selection of test sequences (CR) variable RV : RandomPType ; . StimGen : while TestActive loop case RV.DistInt( (7, 2, 1) ) is -- Select sequence when 0 => -- Normal Handling -- Selected 70% . when 1 => -- Error Case 1 -- Selected 20% . when 2 => -- Error Case 2 -- Selected 10% . O Still uses transactions, so mixes readily with other test approaches 18 SynthWorks What is Functional Coverage? O Functional Coverage (FC) O Code that correlates and/or bins items O Observes conditions from test plan happening in simulation O In VHDL / OSVVM, implemented using a package O Item Coverage - FC relationships within a single object O Bin transfer sizes: 1, 2, 3, 4-127, 128-252, 253, 254, 255 O Cross Coverage - FC relationships between multiple objects O Has the each pair of registers been used with the ALU? O Why not just use Code Coverage? O Tells us a line was executed, but does not correlate independent items O Not necessarily accurate in combinational logic O Test Done = O 100 % Functional Coverage + 100 % Code Coverage 19 SynthWorks Why Functional Coverage? O Randomization requires functional coverage O Otherwise what did the test do? O "I have written a directed test for each item in the test plan, I am done right?" O For a small design maybe O However, this assumes coverage, but does not verify it O As complexity grows
Load more

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]
  • 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]
  • 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]
  • 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]
  • VHDL Modelling Guidelines Simulation and Documentation Aspects
    Second draft, 23 February 1997 CENELEC TC217/WG2 report 2.14 English version VHDL Modelling Guidelines Simulation and Documentation Aspects This CENELEC Report is under preparation and review by the Technical Committee CENELEC TC 217 Working Group 2. CENELEC members are the national electrotechnical committees of Austria, Belgium, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and United Kingdom. CENELEC European Committee for Electrotechnical Standardisation Comité Européen de Normalisation Electrotechnique Europäisches Komitee für Elektrotechnische Normung Central Secretariat: rue de Stassart 35, B-1050 Brussels CENELEC TC217/WG2 report 2.142 Second draft, 23 February 1997 3DJH LQWHQWLRQDOO\ OHIW EODQN Second draft, 23 February 19973 CENELEC TC217/WG2 report 2.14 )25(:25' 7KLV 7HFKQLFDO 5HSRUW LV WKH ILUVW GUDIW RI WKH &(1(/(& 7&:* UHSRUW 7KH UHSRUW LV GHULYHG IURP WKH (XURSHDQ 6SDFH $JHQF\ V (6$©V 9+'/ 0RGHOOLQJ *XLGHOLQHV UHIHUHQFH $6,& LVVXH GDWHG 6HSWHPEHU 7KLV GUDIW KDV EHHQ SUHSDUHG WDNLQJ LQWR DFFRXQW FRPPHQWV IURP &(1(/(& :* PHPEHUV SUHVHQWHG RQ WKH GHGLFDWHG HPDLO UHIOHFWRU 7KH DXWKRU ZRXOG OLNH WR WKDQN DOO FRQWULEXWRUV IRU WKHLU YDOXDEOH LQSXW 7KH (6$ 9+'/ 0RGHOOLQJ *XLGHOLQHV KDYH EHHQ XVHG LQ (6$ GHYHORSPHQW DQG VWXG\ FRQWUDFWV WR HQVXUH KLJKTXDOLW\ PDLQWDLQDEOH 9+'/ PRGHOV 7KH\ KDYH EHHQ SUHSDUHG E\ 3HWHU 6LQDQGHU ZLWK VXSSRUW IURP 6DQGL +DELQF ERWK DW WKH (6$(67(& 0LFURHOHFWURQLFV DQG 7HFKQRORJ\ 6HFWLRQ :60 32 %R[ $* 1RRUGZLMN
    [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]
  • Waveform Editor
    1. Quartus II Simulator QII53017-9.1.0 This chapter describes how to perform different types of simulations with the Quartus II simulator. Introduction With today’s FPGAs becoming faster and more complex, designers face challenges in validating their designs. Simulation verifies the correctness of the design, reducing board testing and debugging time. The Altera® Quartus® II simulator is included in the Quartus II software to assist designers with design verification. The Quartus II simulator has a comprehensive set of features that are covered in the following sections: ■ “Simulation Flow” on page 1–2 ■ “Waveform Editor” on page 1–5 ■ “Simulator Settings” on page 1–13 ■ “Simulation Report” on page 1–16 ■ “Debugging with the Quartus II Simulator” on page 1–19 ■ “Scripting Support” on page 1–21 The Quartus II simulator supports the following device families: ■ ACEX® 1K ■ APEX™ 20KC, APEX 20KE, APEX II ■ Arria® GX ■ Cyclone® III, Cyclone II, Cyclone ■ FLEX® 10K, FLEX 10KA, FLEX 10KE, FLEX 6000 ■ HardCopy® II, HardCopy ■ MAX® II, MAX 3000A, MAX 7000AE, MAX 7000B, MAX 7000S ■ Stratix® III, Stratix II, Stratix, Stratix GX, Stratix II GX 1 The Quartus II simulator does not support newer devices introduced after Stratix III and Quartus II software version 8.1 and onwards. Use the ModelSim-Altera Edition to run simulations on designs targeting device introductions after Stratix III. For more information about the ModelSim-Altera Edition simulator, refer to the Mentor Graphics ModelSim Support chapter in volume 3 of the Quartus II Handbook. In the Quartus II software version 10.0 and onwards, the Quartus II simulator and Waveform Editor is removed.
    [Show full text]
  • VHDL Verification of FPGA Based ESF-CCS for Nuclear Power Plant I&C
    VHDL Verification of FPGA based ESF-CCS for Nuclear Power Plant I&C System Restu MAERANI1, and Jae Cheon JUNG2 1. Department of NPP Engineering, KINGS, Ulsan, 45014, Indonesia ([email protected]) 2. Department of NPP Engineering, KINGS, Ulsan, 45014, Republic of Korea ([email protected]) Abstract: Verification becomes the focus of activities during the integration phase of design life cycle in the development of the system. Verification methods that will not take much cost and time should be properly selected, accordance with the Measurement of Effectiveness (MOEs) need. Verification is one phase that must be done after completing the implementation process. Since Instrumentation & Control (I&C) system has a role as a very crucial to the control protection system in Nuclear Power Plant (NPP), then software verification is very essential and shall to be achieved for safety critical issue in system level. According to IEEE 1076-2008 standard, VHDL is a language that is easy to read by machines and humans; and make it easier for process development, verification, synthesis and testing for hardware reliability in the design. Because this design uses VHDL code for Field Programmable Gate Array (FPGA) based Engineered Safety features – Component Control System (ESF-CCS) and by referring to the NUREG/CR-7006 during VHDL verification on behavioral simulation process, it should be equivalent with the post layout simulation. Furthermore, Vivado will be used as the VHDL verifier, where the VHDL code itself is created, in order to simplify the process of verification with this design life cycle phase on re-engineering process.
    [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]
  • Xilinx Development Systems: Product Descriptions, Data Book
    1 Development Systems: Product Descriptions November 25, 1997 (Version 2.0) 12* Development Systems Descriptions It’s simple to order a Xilinx Development System. Just choose a Foundation or Alliance Series and a few options. Give your local Xilinx Sales Office a call for information about our evaluation kits. Foundation Series • Foundation Base System (PC) • Foundation Base-Express System (PC) • Foundation Standard System (PC) • Foundation Express System (PC) Alliance Series • Alliance Base (PC or Workstation) • Alliance Standard (PC or Workstation) Alliance Series Options • VIEWlogic Workview Office Standard Development System Options (PC) November 25, 1997 (Version 2.0) 2-3 Development Systems: Product Descriptions Foundation Series: Foundation Base System (PC) Overview Package Features - Foundation Base The Foundation Series provides a complete, ready-to-use System design system for the design of Xilinx programmable logic FND FND FND FND devices. The Foundation Base System provides design Feature BAS STD BSX EXP entry (schematic and Abel HDL), simulation, and device √√√√ implementation tools for a broad array of FPGA and CPLD CPLD Devices √1 √√1 √ devices targeted for low density and high volume applica- FPGA Devices tions. Libraries and Interface √√√√ Schematic Editor √√√√ System Features HDL Editor √√√√ • Project manager Graphical State Editor √√√√ • Schematic editor ABEL 6 Entry / Synthesis √√√√ • Integrated HDL editor with support for the Abel 6 HDL VHDL Entry / Synthesis √√ • Functional and timing simulator √√ • EDIF, VHDL (VITAL compliant), and Verilog / SDF Verilog Entry / Synthesis √√√√ design interfaces Schematic-centric Synthesis • Device implementation software for Xilinx CPLDs and HDL-centric Synthesis √ FPGAs Simulator √√√√ • Comprehensive on-line help, on-line documentation, Device Implementation √√√√ and software tutorials Maintenance2 √√√√ • Software maintenance, including hotline support and 11/12/97 software updates Notes: 1.
    [Show full text]
  • Documentation for JTAG Switcher
    Documentation for JTAG Switcher 18 October 2019 License The MIT License Copyright (c) 2018-2019 Lauterbach GmbH, Ingo Rohloff Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUD- ING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. i Table of Contents 1 Introduction 2 1.1 IEEE 1149.1 aka JTAG . .2 1.2 JTAG overview . .3 1.3 JTAG chaining . .5 2 JTAG Switcher overview 6 2.1 Motivation . .6 2.2 Basic circuitry . .8 2.3 Design decisions . .9 2.3.1 JTAG Switcher should conform to IEEE 1149.1 . .9 2.3.2 Transparency . .9 2.3.3 First in JTAG chain . .9 2.3.4 JTAG slave TCK clock gating .
    [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]