a seminar reporton system verilog
TRANSCRIPT
COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY COCHIN UNIVERSITYCOLLEGE OF ENGINEERING KUTTANAD
(2006-2010)
DEPARTMENT OF ELECTRONICS & COMMNICATION ENGINEERING
A SEMINAR REPORT
ON
System verilog Submitted in partial fulfillment of the requirements in the award of Degree of
Bachelor of Technology in Electronics and Communication Engineering
BY
RAKESH KUMAR
Reg No: 00600697
ROLL NO: 35
S7,ECE
COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY
(COCHIN UNIVERSITY COLLEGE OF ENGINEERING KUTTANAD)
Certificate
Certified that this is a bonafide record of the seminar entitled
‘SYSTEM VERILOG’ Presented by
RAKESH KUMAR of the VII semester, Electronics and Communication in the year 2009 in partial
fulfillment of the requirements in the award of Degree of Bachelor of Technology in
Electronics and Communication Engineering of Cochin University of Science and Technology.
Seminar Guide
Head of Depatment
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 4 CUCEK
Acknowledgement
Many people have contributed to the success of this. Although a single sentence hardly suffices, I would like to thank Almighty God for blessing us with His grace. I extend mysincere and heart felt thanks to Mr. Manoj V.J., Head of Department, Electronics & Communication Engineering, for providing us the right ambience for carrying out this work. I am profoundly indebted to my seminar guide, Ms. Biji L., Ms. Renju, Ms. Preeja,Ms. Sandhya Rajan for innumerable acts of timely advice, encouragement and I sincerely express my gratitude to her. I express my immense pleasure and thankfulness to all the teachers and staff of the
Department of Electronics & Communication Engineering, CUCEK for their
cooperation and support. I would also like to thank all my friends, specially my family, who were the source of constant encouragement.
Rakesh Kumar
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 5 CUCEK
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 6 CUCEK
1. Abstract 5
CONTENTS
S .No. Topic Page No.
2. History 6
3. System Level Language 7 4. Introduction 8 5. ROOTS of SYSTEM VERILOG 9 6. SystemVerilog 3.0 Features 10 7. Interfaces 11 8. Abstract Data Type 12 9. Enumerated Data Type 13 10. String data type 13 11. User-defined Types 14 12. Structure 14 13. New Operator 15 14. Always tatement 15 15. OOP 16 16. Verilog Hierarchy Enhancements 17
17. Funtion 18
18. Enhanced for loops 19
19. Jump Statement 19
20. SystemVerilog 3.1 Features 20
21. SystemVerilog 3.1Is Based on Proven Technology 20 22. Test Bench Block 21
23. Object Oriented Classes 22 24. Clocking Domain 23 25. Direct C Language Interface 24 26. Vendor Interest 25 27. Application 26 28. Conclusion 27 29. References 28
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 7 CUCEK
ABSTRACT
IEEE 1800TM SystemVerilog is the industry's first unified hardware description and verification language (HDVL) standard. SystemVerilog is a major extension of the established IEEE 1364TM Verilog language.
SystemVerilog was created by the donation of the Superlog language to Accellera in 2002.[1] The bulk of the verification functionality is based on the OpenVera language donated by Synopsys. In 2005, SystemVerilog was adopted as IEEE Standard 1800-2005.
SystemVerilog is targeted primarily at the chip implementation and verification flow, with powerful links to the system-level design flow. SystemVerilog has been adopted by 100's of semiconductor design companies and supported by more than 75 EDA, IP and training solutions worldwide.
Verilog 1995 version has been in market for a very long time. IEEE extended the features of Verilog 1995 and released it as Verilog 2001. But this was no good for verification engineers, so verifcation engineers had to use languages like "e", VERA, Testbuider. It was rather painfull to have two language, one for design and other for verification. SystemVerilog combines the Verification capabilties of HVL (Hardware Verification Language) with ease of Verilog to provide a single platform for both design and verification.
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 8 CUCEK
The requirements for the language were first generated in 1981 under the VHSIC program. In this program, a number of U.S. companies were involved in designing VHSIC chips for the Department of Defense (DoD). At that time, most of the companies were using different hardware description languages to describe and develop their integrated circuits. As a result, different vendors could not effectively exchange designs with one another. Also, different vendors provided DoD with descriptions of their chips in different hardware description languages. Reprocurement and reuse was also a big issue. Thus, a need for a standardized hardware description language for design, documentation, and verification of digital systems was generated. A team of three companies, IBM, Texas Instruments, and Intermetrics, were first awarded the contract by the DoD to develop a version of the language in 1983. Version 7.2 of VHDL was developed and released to the public in 1985. There was a strong industry participation throughout the VHDL language development process, especially from the companies that were developing VHSIC chips.After the release of version 7.2, there was an increasing need to make the language an industry-wide standard. Consequentl, the language was transferred to the IEEE for standardization in 1986. After a substantia enhancement to the language, made by a team of industry,university, and DoD representatives, the language was standardized by the IEEE in December 1987; this version of the language is now known as the IEEE Std 1076-1987. The official language description appears in the IEEE Standard VHDL Language Reference Manual made available by the IEEE.
HISTORY
VERILOG 1995 VERILOG 2001
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 9 CUCEK
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 10
CUCEK
SystemVerilog extends the IEEE 1364 Verilog-2001 standard
INTRODUCTION
What is SystemVerilog?
– Adds abstract, system-level modeling constructs to Verilog – Adds extended test bench features to Verilog SystemVerilog is being released in two primary stages
– SystemVerilog 3.0 (released June 2002) Extends the hardware modeling aspects of Verilog
– SystemVerilog 3.1 (released June 2003) Extends the verification aspects of Verilog SystemVerilog is being defined by Accellera
– Accellera is a consortium of EDA and engineering companies – Expected that the IEEE add to the next 1364 Verilog standard
IEEE 1800TM SystemVerilog is the industry's first unified hardware description and verification language (HDVL) standard.
SystemVerilog is a major extension of the established IEEE 1364TM Verilog language.
SystemVerilog was created by the donation of the Superlog language to Accellera in 2002.
The bulk of the verification functionality is based on the OpenVera language donated by Synopsys.
In 2005, SystemVerilog was adopted as IEEE Standard 1800-2005
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 11
CUCEK
Accellera chose not to re-invent the wheel
ROOTS of SYSTEM VERILOG
and relied on donations of technology from a number of companies.
• High-level modeling constructs : Superlog language developed by Co-Design
• Testbench constructs : Open Vera language and VCS DirectC interface technology by Synopsys
• Assertions : OVA from Verplex, ForSpec from Intel, Sugar (renamed PSL) from IBM, and OVA from Synopsys
Most features in SystemVerilog 3.0 are from three sources:
SystemVerilog3.0 Is Based On Proven Technology
– A subset of the SUPERLOG language
Co-design Automation donated the “synthesizable” portion of its
SUPERLOG language to Accellera
Created by Peter Flake, Phil Moorby, and Simon Davidmann An implementation of the OVL assertions library Verplex donated their work on assertion libraries to Accellera Real Intent and Co-design donated their assertion syntax and semantics to
Accellera Proposals from the Accellera SystemVerilog committee The committee reviewed and refined the donations received The committee defined additional enhancements to Verilog
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 12
CUCEK
SystemVerilog 3.0 Features
• Interfaces between modules • Global declarations • Global tasks and functions • Global statements • Time unit and precision enhancements • C language data types • 2-state data types • User defined types • Enumerated types • Structures and unions • Type casting • Literal value enhancements
• Specialized always procedures • Increment/decrement operators • Unique decision statements • Priority decision statements • Bottom testing do–while loop • Jump statements • Statement labels • Block name enhancements • Task and function enhancement • Continuous assignment enhancements • Module port connection enhancements
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 13
CUCEK
Verilog connects models using module ports
INTREFACES
– Requires detailed knowledge of connections to create module
– Difficult to change connections if design changes
– Port declarations must be duplicated in many modules
SystemVerilog adds an interface block
– Connections between models a bundled together
– Connection definitions are independent from modules
– Interfaces can contain declarations and protocol checking
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 14
CUCEK
Interfaces group the modules ports together
May contain declarations of variables, tasks and functions
The declarations are common to all the modules using the interface
Can also contain assertions for proper use, and procedures for modeling
Interfaces – the benefits
rovide separation of communication from the functionality of the modules
Reduce duplication of connections between module ports
Enable abstraction refinement
Convenience for designing
Easier for reuse
Can be represented graphically
Verilog has hardware-centric net data types
Abstract Data Types
– Intended to represent real connections in a chip or system
– Models detailed hardware behavior using 4-state logic, strength
levels and wired logic resolution
– Can reduce simulation performance
– Most hardware models only need abstract 2-state logic
SystemVerilog adds abstract data types
– 2-state types: int, shortint, longint, char, byte, bit
– 4-state type: logic
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 15
CUCEK
– Special types: void, shortreal
– Allows modeling at a C-language level of abstraction
–Efficient data types for simulation performance
Verilog does not have enumerated types
Enumerated Types
– All signals must be declared
– All signals must be initialized to a value
SystemVerilog adds enumerated types, using enum, as in C
– Optionally, the data type of the enumerated types can be declared
– The default data type is int
– Optionally, the values of enumerated names can be specified
– The default initial value is 0
– Subsequent names are incremented from the previous value
exa:- enum {WAIT ,LOAD ,READY} states;
contains a variable length array of ASCII characters. Each time a value is assigned to the string, the length of the array is automatically adjusted.
String data type
Operations:
• standard Verilog operators
len(), putc(), getc(), toupper(), tolower(), compare(), icompare(), substr(), atoi(), atohex(), atooct(), atobin(), atoreal(), itoa(), hextoa(), octtoa(), bintoa(), realtoa()
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 16
CUCEK
Verilog does not have user-defined data types
User-defined Types
SystemVerilog adds user-defined types
– Uses the typedef keyword, as in C
typedef int unsigned uint;
uint a, b; //two unsigned integers
– typedef enum {FALSE=1’b0, TRUE} boolean;
boolean ready; //signal “ready” can be FALSE or TRUE
SystemVerilog adds structures to Verilog
Structures
• A collection of objects that can be different data types
• Can be used to bundle several variables into one object
• Can assign to individual signals within the structure
• Can assign to the structure as a whole
• Can pass structures through ports and to tasks or function
struct { real r0, r1; int i0, i1; bit [15:0] opcode; } instruction_word; ... instruction_word.opcode = 16’hF01E;
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 17
CUCEK
Verilog does not have increment and decrement operators.
New Operators
for (i = 0; i <= 255; i=i+1)
SystemVerilog adds:
++ and -- increment and decrement operators
+=, -=, *=, /=, %=, &=, ^=, |=, <<=, >>=, <<<=, >>>= assignment operators
for (i = 0; i <= 255; i++)
Always block issues in VERILOG
Incomplete sensitivity list: simulation – synthesis mismatch
Simulators will add latch
Synthesis will ignore the sen. list and put only comb. Logic
Missing ‘else’ clause: implies adding latch during synthesis
New ‘always’ constructs in SystemVerilog
always_ff – to model a flip-flop
always_comb – for comb. Logic
always_latch – to model latch-based logic
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 18
CUCEK
Always_comb
The mux example with always_comb directive:
always_comb
if(select)
out = i1;
else
out = i2;
Here all the tools will report errors:
Always_comb
if(select1)
out = i1;
else if(select2)
out = i2;
OOP
Are used for testbenches
Enable convenient extensions to the system
Reusability
Generalizations and additions
Abstraction, encapsulation, clustering
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 19
CUCEK
OOP - Points for Considering
Schematic view is only for design
Testbenches should also be handled
Waveform: should handle transactions instead of bit level
Behavioral view has statements and transitions in the RTL level
Should have views of GFSM’s like views
Can also have test benches views, i.e constraints
SystemVerilog adds three major enhancements to
Verilog Hierarchy Enhancements
representing design hierarchy
• A global name space
– Can contain declarations, tasks, functions and statements
– Any module can reference global declarations
– Avoids declaring the same information in multiple modules
• Nested module declarations
– Nested modules are only visible to their parent module
– Protects hierarchy within Intellectual Property models
• Automatic netlist connections
– New .name and .* automatically connect nets and ports that have the same name
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 20
CUCEK
• Default Port Direction : Any port is seen as input, unless declared as other types. Following are port types
Functions
Function declration can be as in verilog 1995/2001 or can be declared as in C or C++. In SystemVerilog following rules hold good for any Function declaration.
o input : copy value in at beginning o output : copy value out at end o inout : copy in at beginning and out at end o ref : pass reference
• Default Data TYpe : Unless declared, data types of ports are of logic type. • begin..end : There is no need to have begin, end, when more then one
statement is used. • return : A function can be terminated before enfunction, by usage of return
statement. • Variables : Systemverilog allows to have local static, or local dynamic
variables. • life time : SystemVerilog allows a function to static or automatic. • Wire : Wire data type can not be used in port list; • void : SystemVerilog allows functions to be declared as type void.
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 21
CUCEK
Allow the loop control variable to be declared as part of the for loop, and allows the loop to contain multiple initial and step assignments.
Enhanced for loops
• for (int i=1, shortint count=0; i*count < 125; i++, count+=3) Bottom testing loops.
• adds a do-while loop, which tests the loop condition at the end of executing code in the loop.
Jump statements. • adds the C "break" and "continue" keywords, which do not require
the use of block names, and a "return" keyword, which can be used to exit a task or function at any point.
Final blocks. • execute at the very end of simulation, • can be used in verification to print simulation results, such as code
coverage reports
• break : out of loop as in C
Jump statements
SystemVerilog adds the C jump statements break, continue and return.
• continue : skip to end of loop (move to next loop value) as in C • return expression : exit from a function • return : exit from a task or void function
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 22
CUCEK
• Test bench program blocks • Assertions • Clocking domains • Constrained random values • Mailbox process synchronization • Semaphore process synchronization • Event data type enhancements • Dynamic process control • References (safe pointers)
SystemVerilog 3.1 Features
SystemVerilog 3.1 enhances Verilog verification constructs
• Test bench program blocks • Assertions • Clocking domains • Constrained random values • Mailbox process synchronization • Semaphore process synchronization • Event data type enhancements • Dynamic process control • References (safe pointers)
SystemVerilog 3.1Is Based on Proven Technology
• Most features in SystemVerilog 3.1 are from four sources:
– The Synopsys VERA-Lite Hardware Verification Language
• Powerful constructs for modeling test benches
– The Synopsys VCS DirectC Application Programming Interface (API)
• Allows Verilog code to directly call C functions (no PLI needed)
• Allows C functions to directly call Verilog tasks and functions
– The IBM “Sugar” assertion technology
• Allows design and verification engineers to add checks to models
– The Synopsys Assertion Application Programming Interface (API)
• Allows PLI applications to access and control assertions
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 23
CUCEK
Declared between the keywords "program" and "endprogram."
Test Bench Blocks
• Verilog uses hardware modeling constructs to model the verification test bench
– No special semantics avoid race condition with the design
• SystemVerilog adds a special “program block” for testing
– Events in a program block execute in a “verification phase”
• Synchronized to hardware simulation events to avoid races
Contains a single initial block.
Executes events in a “reactive phase” of the current simulation time, appropriately synchronized to hardware simulation events.
Can use a special "$exit" system task that will wait to exit simulation until after all concurrent program blocks have completed execution (unlike "$finish," which exits simulation immediately).
program test (input clk, input [15:0] addr, inout [7:0] data); @(negedge clk) data = 8’hC4; address = 16’h0004; @(posedge clk) verify_results; task verify_results; ... endtask endprogram
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 24
CUCEK
Object Oriented Classes
• SystemVerilog adds “classes” to the Verilog language – Allows Object Oriented programming techniques
• Can be used in the test bench
• Can be used in hardware models
– Classes can contain
• Data declarations, referred to as the object’s “properties”
• Tasks and functions, referred to as the object’s “methods”
– Classes can have “inheritance” similar to C++
Have data members, methods
Are accessed via handles (references)
Generic classes (parameterization)
Single inheritance with polymorphysm
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 25
CUCEK
class Packet ; bit [3:0] command; bit [39:0] address; bit [4:0] master_id; integer time_requested; integer time_issued; integer status; task clean(); command = 4’h0; address = 40’h0; master_id = 5’b0; endtask task issue_request( int delay ); ... // send request to bus endtask endclass
Clocking domains allow the testbench to be defined using a cycle-based methodology, rather than the traditional event-based methodology
Clocking domain
A clocking domain can define detailed skew information
avoiding race conditions with the design
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 26
CUCEK
Direct C Language Interface
• Verilog uses the Programming Language Interface (PLI) to allow Verilog code to call C language code
– Powerful capabilities such as traversing hierarchy, controlling simulation, modifying delays and synchronizing to simulation time
– Difficult to learn
– Too complex of an interface for many types of applications
• SystemVerilog adds the ability for:
– Verilog code to directly call C functions
– C functions to directly call Verilog tasks and functions
– No PLI is needed for these direct function calls
• Can do many things more easily than the PLI
• Ideal for accessing C libraries, interfacing to C bus-functional models
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 27
CUCEK
SystemVerilog has been adopted by 100's of semiconductor design companies and supported by more than 75 EDA, IP and training solutions worldwide.
VENDOR’S INTEREST
semiconductor design companies such as
INTEL
AMD
MOTOROLA
TEXAS Instruments
National Semiconductor
Segates
Trancends
Kingston
EDA companies Cadence Mentor Synopsis Vera
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 28
CUCEK
In FPGA design
APPLICATION
In ASIC design Gate level design RTL synthesis 3D IC fabrication Systolic Architecture Higher Level Design, simulation, synthesis, Test…
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 29
CUCEK
Extensive enhancements to the IEEE 1364 Verilog-2001 standard.
Conclusion
--SystemVerilog combines an enhanced Hardware Description
Language and an advanced Hardware Verification Language into
one unified language!
– SystemVerilog 3.0 enhances Verilog for modeling hardware
– SystemVerilog 3.1 enhances Verilog for design verification
More abstraction
: modeling hardware at the RTL and system level
Improved productivity, readability, and reusability of Verilog based code
Verification
Enhanced IP protection
Verilog 1995 version has been in market for a very long time. IEEE extended the features of Verilog 1995 and released it as Verilog 2001. But this was no good for verification engineers, so verifcation engineers had to use languages like "e", VERA, Testbuider. It was rather painfull to have two language, one for design and other for verification. SystemVerilog combines the Verification capabilties of HVL (Hardware Verification Language) with ease of Verilog to provide a single platform for both design and verification.
SYSTEM VERILOG SEMINAR REPORT 2009
Department of ECE Page 30
CUCEK
SYSTEM VERILOG REFERENCE MANUAL.
REFERENCES
SYSTEM VERILOG PRIMER
STUART SUTHERLAND PAPER
WWW.SYNOPSIS.COM.
WWW.ACCELLERA.COM