Resources
Resources
Assertion-Based Design (Information Technology: Transmission Processing & Storage)
https://www.amazon.com/
Creating Assertion-Based IP (Integrated Circuits and Systems)
https://www.amazon.com/
Assertion-Based Design (Information Technology: Transmission Processing & Storage)
https://www.amazon.com/
https://www.amazon.com/
Applied Formal Verification: For Digital Circuit Design (Electronic Engineering)
https://www.amazon.com/
A Practical Guide to Adopting the Universal Verification Methodology (Uvm) Second Edition
https://www.amazon.com/
Comprehensive Functional Verification: The Complete Industry Cycle (Systems on Silicon)
https://www.amazon.com/
https://www.amazon.com/
Doulos UVM Golden Reference Guide
https://www.amazon.com/
Mixed-Signal Methodology Guide
https://www.amazon.com/
Principles of Functional Verification
https://www.amazon.com/
Taxonomies for the Development and Verification of Digital Systems
https://www.amazon.com/
TLM-Driven Design and Verification Methodology
https://www.amazon.com/
Verification Methodology Manual for Low Power
https://www.amazon.com/
Verification Methodology Manual for SystemVerilog
https://www.amazon.com/
https://www.amazon.com/
Timing Verification of Application-Specific Integrated Circuits (ASICs)
https://www.amazon.com/
Verilog and SystemVerilog Gotchas: 101 Common Coding Errors and How to Avoid Them
https://www.amazon.com/
SystemVerilog for Verification: A Guide to Learning the Testbench Language Features
https://www.amazon.com/
Advanced FPGA Design: Architecture, Implementation, and Optimization
https://www.amazon.com/
The MicroZed Chronicles – Using the Zynq 101: Complete First Year
https://www.amazon.com/
The MicroZed Chronicles – Using the Zynq 101: Second Year
https://www.amazon.com/
High-Level Synthesis Blue Book
https://www.amazon.com/
High-Level Synthesis: from Algorithm to Digital Circuit
https://www.amazon.com/
Embedded Systems Development: From Functional Models to Implementations
https://www.amazon.com/
Theory of Modeling and Simulation, Second Edition
https://www.amazon.com/
Towards a Design Flow for Reversible Logic
https://www.amazon.com/
Universal Serial Bus System Architecture (PC System Architecture Series)
https://www.amazon.com/
ARM System-on-Chip Architecture (2nd Edition)
https://www.amazon.com/
Correct-by-Construction Approaches for SoC Design
https://www.amazon.com/
Networks on Chips: Technology and Tools (Systems on Silicon)
https://www.amazon.com/
On-Chip Communication Architectures: System on Chip Interconnect (Systems on Silicon)
https://www.amazon.com/
https://www.amazon.com/
Why Programs Fail: A Guide to Systematic Debugging
https://www.amazon.com/
The C++ Programming Language: Special Edition (3rd Edition)
https://www.amazon.com/
Programming Language Pragmatics, Third Edition
https://www.amazon.com/
Refactoring: Improving the Design of Existing Code
https://www.amazon.com/
The Pragmatic Programmer: From Journeyman to Master
https://www.amazon.com/
Design Patterns: Elements of Reusable Object-Oriented Software
https://www.amazon.com/
https://www.amazon.com/
https://www.amazon.com/
FPGAs!? Now What? – Learning FPGA Design with the XULA Board
https://www.amazon.com/
FPGAs for Dummies – 2nd Intel Special Edition
https://www.amazon.com/
Introducing the Spartan 3E FPGA and VHDL
https://www.amazon.com/
This paper is based on an article submitted to DVCon EU 2022 entitled How creativity kills reuse – A modern take on UVM-SV TB architectures. The subject of the former paper is an architecture that allows the user to define a fully modular testbench (TB) that does not have hard coded constraints, components, or tests. The motivation of developing such a testbench is to allow external control over the contents of an UVM-SV environment, as well as over the control variables and randomization constraints of the virtual/higher layer of sequences. One of the biggest advantages of such an architecture is the possibility to separate the stimuli generation from the SystemVerilog (SV) environment, opening the door to outside intelligent systems that can process data and improve the efficiency of stimuli generation. In this paper, such a system is presented, where data is gathered from simulation results and used to automatically adjust the input stimuli, in conjunction with other external variables.
The purpose of this paper is to set the groundwork and guidelines for a revised UVM/SV architecture and way of working that would tick the following boxes:
- Provide a general TB architecture that has a fixed structure and can be adapted to any verification requirements, no matter the scale, nature or complexity of the verified DUT
- Enforce the reusability of the TB by constraining the usage of user defined types to allow scaling down as well as scaling up the number of verification components via the factory (string-based definitions instead of hard types)
- Decoupling the stimulus generation from the environment and using the test as a translation layer for run defined stimulus (modular sequences and adaptable constraints settled at run-time)
Automate the process of constraint adjustments, sequence instantiation and environment scaling
Functional verification using co-emulation has seen a growing trend due to its main advantage: testbench acceleration. Co-emulation requires two main things: (1) a connection between the host machine running the testbench and the hardware platform where the design is synthesized, and (2) a software component for interacting with the design. Most currently available solutions for achieving a complete co-emulation environment are proprietary.
This paper describes an Open-source Framework for Co-emulation (OFC) used for communication between a UVM-SystemVerilog testbench and a design emulated on the FPGA logic of a PYNQ board. The OFC framework is split into two main components: a TCP socket-based client-server connection and a Python component that interacts with the FPGA using the API provided by Xilinx for the PYNQ board. Owing to its modular implementation, the two components can be used either together or separately, depending on the user’s needs.
AMIQ Consulting developed the FC4SC library to complement existing C++ and SystemC libraries with the coverage collection that at the center of any modeling and verification project. Functional coverage lies at the core of semiconductor functional verification as the primary metric to assess quality and track the progress of the entire verification process. FC4SC provides mechanisms for functional coverage definition, collection, and reporting. It can be used in any application compliant with the C++ standard, starting with C++11, including SystemC models.
The primary use for the library is to measure the level of exercise of C++/SystemC verification models or C++ applications, checking which features were tested and which parameters were used during the test runs. Verification engineers can augment an existing C++/SystemC project with functional coverage to assess the quality and diversity of test suites. With this library, SystemC/C++ projects have an accurate way to track level of feature exercise and, therefore, the overall verification progress.
The FC4SC library is designed to interoperate with other tools and technologies, providing an application programming interface (API) that closely resembles functional coverage definition and usage defined by the IEEE 1800-2017 SystemVerilog standard. The collected data is saved in the Accellera Unified Coverage Interoperability Standard (UCIS) format for future interoperability with other coverage tools. Users can generate reports showing coverage holes, partially covered coverage bins, and other coverage analysis metrics.
Functional verification using co-emulation has seen a growing trend due to its main advantage: testbench acceleration. Co-emulation requires two main things: (1) a connection between the host machine running the testbench and the hardware platform where the design is synthesized, and (2) a software component for interacting with the design. Most currently available solutions for achieving a complete co-emulation environment are proprietary.
This paper describes an Open-source Framework for Co-emulation (OFC) used for communication between a UVM-SystemVerilog testbench and a design emulated on the FPGA logic of a PYNQ board. The OFC framework is split into two main components: a TCP socket-based client-server connection and a Python component that interacts with the FPGA using the API provided by Xilinx for the PYNQ board. Owing to its modular implementation, the two components can be used either together or separately, depending on the user’s needs.
6.1 Portable Stimulus Driven SystemVerilog/UVM Verification Environment for the Verification of a High-capacity Ethernet Communication Endpoint
The scope of this paper is to present the steps taken and the challenges faced when using Portable Stimulus(PSS) as an abstraction layer on top of a SystemVerilog/UVM verification environment. The goal is the verification of a highly configurable, high-speed, communication endpoint, covering complex network scenarios and system-level corner cases. PSS is used in conjunction with SystemVerilog/UVM to increase verification efficiency by avoiding “scenario flooding” and keep a tight control of the verification space. All stimuli are defined in the test-bench and they are used to construct directed/random scenarios by utilizing a PSS generation model. The flow of the project in this case requires the SV/UVM VE to keep up with the guidelines for reusability while having an architecture that is compliant with the PSS mechanics of scenario generation. The paper addresses the possible issues and good practices discovered while implementing this verification strategy.
Functional Coverage for SystemC(FC4SC) is a C++11 library that provides support for functional coverage collection by SystemC/C++ applications:
- SystemVerilog-like functional coverage constructs
- Functional coverage inspection API
- UCIS database support
- Coverage databse merge utilities
- HTML/JavaScript coverage report
Yet Another Memory Manager (YAMM) is a SystemVerilog library that provides support for memory based operations:
- Buffers can be allocated following 6 allocation modes with any granularity or address alignment
- Buffers can be inserted by user (non-overlapping)
- Buffers can be deallocated either by address or by handle
- Buffers can be searched for in the memory space by address or by handle
- Buffers support payload, which can be assigned by the user, randomly generated, read and compared.
- Implements a fast buffer search algorithm
Beside these features YAMM provides debug facilities (e.g. memory map dump, usage statistics) and it is easy to integrate it with existing verification environments.
Yet Another Memory Manager (YAMM) is a SystemVerilog library that provides support for memory based operations:
- Buffers can be allocated following 6 allocation modes with any granularity or address alignment
- Buffers can be inserted by user (non-overlapping)
- Buffers can be deallocated either by address or by handle
- Buffers can be searched for in the memory space by address or by handle
- Buffers support payload, which can be assigned by the user, randomly generated, read and compared.
- Implements a fast buffer search algorithm
Beside these features YAMM provides debug facilities (e.g. memory map dump, usage statistics) and it is easy to integrate it with existing verification environments.
Yet Another Memory Manager (YAMM) is a SystemVerilog library that provides support for memory based operations:
- Buffers can be allocated following 6 allocation modes with any granularity or address alignment
- Buffers can be inserted by user (non-overlapping)
- Buffers can be deallocated either by address or by handle
- Buffers can be searched for in the memory space by address or by handle
- Buffers support payload, which can be assigned by the user, randomly generated, read and compared.
- Implements a fast buffer search algorithm
Beside these features YAMM provides debug facilities (e.g. memory map dump, usage statistics) and it is easy to integrate it with existing verification environments.
SystemVerilog Assertions(SVA) play a central role in functional verification of protocols, encompassing feature checking and coverage. In order to benefit from assertion advantages (fast, synthesizable, nonintrusive, coverable), we must verify that they pass or fail as described by the protocol specification. In turn this requires to implement the sequences of stimuli that properly trigger the assertion (making it pass or fail) and checks to ensure its correct behavior under the given conditions. We developed the SVAUnit framework with three objectives in mind:
- decouple SVA test logic from SVA definition
- simplify the creation of stimuli/checkers that validate the SVA
- simplify test and stimuli maintenance
SVAUnit is a simulator independent, UVM compliant package that combines the unit testing paradigm of the software world with the powerful feature of assertions from SystemVerilog.
SystemVerilog Assertions(SVA) play a central role in functional verification of protocols, encompassing feature checking and coverage. In order to benefit from assertion advantages (fast, synthesizable, nonintrusive, coverable), we must verify that they pass or fail as described by the protocol specification. In turn this requires to implement the sequences of stimuli that properly trigger the assertion (making it pass or fail) and checks to ensure its correct behavior under the given conditions. We developed the SVAUnit framework with three objectives in mind:
- decouple SVA test logic from SVA definition
- simplify the creation of stimuli/checkers that validate the SVA
- simplify test and stimuli maintenance
SVAUnit is a simulator independent, UVM compliant package that combines the unit testing paradigm of the software world with the powerful feature of assertions from SystemVerilog.
SystemVerilog Assertions(SVA) play a central role in functional verification of protocols, encompassing feature checking and coverage. In order to benefit from assertion advantages (fast, synthesizable, nonintrusive, coverable), we must verify that they pass or fail as described by the protocol specification. In turn this requires to implement the sequences of stimuli that properly trigger the assertion (making it pass or fail) and checks to ensure its correct behavior under the given conditions. We developed the SVAUnit framework with three objectives in mind:
- decouple SVA test logic from SVA definition
- simplify the creation of stimuli/checkers that validate the SVA
- simplify test and stimuli maintenance
SVAUnit is a simulator independent, UVM compliant package that combines the unit testing paradigm of the software world with the powerful feature of assertions from SystemVerilog.
SystemVerilog Assertions(SVA) play a central role in functional verification of protocols, encompassing feature checking and coverage. In order to benefit from assertion advantages (fast, synthesizable, nonintrusive, coverable), we must verify that they pass or fail as described by the protocol specification. In turn this requires to implement the sequences of stimuli that properly trigger the assertion (making it pass or fail) and checks to ensure its correct behavior under the given conditions. We developed the SVAUnit framework with three objectives in mind:
- decouple SVA test logic from SVA definition
- simplify the creation of stimuli/checkers that validate the SVA
- simplify test and stimuli maintenance
SVAUnit is a simulator independent, UVM compliant package that combines the unit testing paradigm of the software world with the powerful feature of assertions from SystemVerilog.
Verification of high computational algorithmic RTL (e.g. digital signal processing) requires complex mathematical models that are hard to implement and slow to run in any of the existing hardware verification languages. Using numerical computing languages (e.g. Octave, Matlab) to code these models will dramatically speed up the verification sign-off by reuse of mathematical functions (e.g. predefined DSP functions) that are already verified. This also has a low risk of algorithm implementation bugs and guarantees optimal implementation for maximum simulation performance.
This paper illustrates typical usage of external mathematical models inside the verification environment using SystemVerilog as the verification language and Octave, an open source sibling of Matlab, as the numerical modeling language.
We do pre-silicon verification in multiple iterations, each iteration including at least a regression. Regressions consume a great deal of HW resources (e.g. CPU time) and SW resources (e.g. licenses) and… a lot of human effort. This is what usually happens when we run a regression: we aim to reduce the time spent in regression analysis, especially when we run regressions at a fast pace, for example overnight. We want to see the results in a simple, easy to read report, as soon as possible. We are eager to start debugging issues immediately, instead of aggregating and organizing those tons of information resulting from running a regression. We expect everyone in the team to keep up to date on the regression status with virtually no effort. And in the long run, we want to have a history of regression’s progress.
This poster shows a different way of dealing with these challenges using practical regression automation scripts. The scripts can help your team to save a lot of time and deal in an effective way with the regression results.
If you want to cover a bus activity you can either use bit toggling or define coverage ranges as power-of-2 intervals. As bit toggling is not very relevant (can be covered very quickly in one transition from 0 to MAX_VALUE) the second option is preferred. But using power-of-2 coverage creates another problem: coverage intervals are uneven and covering the smaller bins takes a lot of time. In large projects it can take weeks of regressions time to fill all of them.
This poster illustrates how the stimuli generation can be tweaked so that the smaller bins are hit just as often as the larger ones.
Functional verification using co-emulation has seen a growing trend due to its main advantage: testbench acceleration. Co-emulation requires two main things: (1) a connection between the host machine running the testbench and the hardware platform where the design is synthesized, and (2) a software component for interacting with the design. Most currently available solutions for achieving a complete co-emulation environment are proprietary.
This paper describes an Open-source Framework for Co-emulation (OFC) used for communication between a UVM-SystemVerilog testbench and a design emulated on the FPGA logic of a PYNQ board. The OFC framework is split into two main components: a TCP socket-based client-server connection and a Python component that interacts with the FPGA using the API provided by Xilinx for the PYNQ board. Owing to its modular implementation, the two components can be used either together or separately, depending on the user’s needs.
AMIQ Consulting developed the FC4SC library to complement existing C++ and SystemC libraries with the coverage collection that at the center of any modeling and verification project. Functional coverage lies at the core of semiconductor functional verification as the primary metric to assess quality and track the progress of the entire verification process. FC4SC provides mechanisms for functional coverage definition, collection, and reporting. It can be used in any application compliant with the C++ standard, starting with C++11, including SystemC models.
The primary use for the library is to measure the level of exercise of C++/SystemC verification models or C++ applications, checking which features were tested and which parameters were used during the test runs. Verification engineers can augment an existing C++/SystemC project with functional coverage to assess the quality and diversity of test suites. With this library, SystemC/C++ projects have an accurate way to track level of feature exercise and, therefore, the overall verification progress.
The FC4SC library is designed to interoperate with other tools and technologies, providing an application programming interface (API) that closely resembles functional coverage definition and usage defined by the IEEE 1800-2017 SystemVerilog standard. The collected data is saved in the Accellera Unified Coverage Interoperability Standard (UCIS) format for future interoperability with other coverage tools. Users can generate reports showing coverage holes, partially covered coverage bins, and other coverage analysis metrics.
Functional verification using co-emulation has seen a growing trend due to its main advantage: testbench acceleration. Co-emulation requires two main things: (1) a connection between the host machine running the testbench and the hardware platform where the design is synthesized, and (2) a software component for interacting with the design. Most currently available solutions for achieving a complete co-emulation environment are proprietary.
This paper describes an Open-source Framework for Co-emulation (OFC) used for communication between a UVM-SystemVerilog testbench and a design emulated on the FPGA logic of a PYNQ board. The OFC framework is split into two main components: a TCP socket-based client-server connection and a Python component that interacts with the FPGA using the API provided by Xilinx for the PYNQ board. Owing to its modular implementation, the two components can be used either together or separately, depending on the user’s needs.
6.1 Portable Stimulus Driven SystemVerilog/UVM Verification Environment for the Verification of a High-capacity Ethernet Communication Endpoint
The scope of this paper is to present the steps taken and the challenges faced when using Portable Stimulus(PSS) as an abstraction layer on top of a SystemVerilog/UVM verification environment. The goal is the verification of a highly configurable, high-speed, communication endpoint, covering complex network scenarios and system-level corner cases. PSS is used in conjunction with SystemVerilog/UVM to increase verification efficiency by avoiding “scenario flooding” and keep a tight control of the verification space. All stimuli are defined in the test-bench and they are used to construct directed/random scenarios by utilizing a PSS generation model. The flow of the project in this case requires the SV/UVM VE to keep up with the guidelines for reusability while having an architecture that is compliant with the PSS mechanics of scenario generation. The paper addresses the possible issues and good practices discovered while implementing this verification strategy.
Functional Coverage for SystemC(FC4SC) is a C++11 library that provides support for functional coverage collection by SystemC/C++ applications:
- SystemVerilog-like functional coverage constructs
- Functional coverage inspection API
- UCIS database support
- Coverage databse merge utilities
- HTML/JavaScript coverage report
Yet Another Memory Manager (YAMM) is a SystemVerilog library that provides support for memory based operations:
- Buffers can be allocated following 6 allocation modes with any granularity or address alignment
- Buffers can be inserted by user (non-overlapping)
- Buffers can be deallocated either by address or by handle
- Buffers can be searched for in the memory space by address or by handle
- Buffers support payload, which can be assigned by the user, randomly generated, read and compared.
- Implements a fast buffer search algorithm
Beside these features YAMM provides debug facilities (e.g. memory map dump, usage statistics) and it is easy to integrate it with existing verification environments.
Yet Another Memory Manager (YAMM) is a SystemVerilog library that provides support for memory based operations:
- Buffers can be allocated following 6 allocation modes with any granularity or address alignment
- Buffers can be inserted by user (non-overlapping)
- Buffers can be deallocated either by address or by handle
- Buffers can be searched for in the memory space by address or by handle
- Buffers support payload, which can be assigned by the user, randomly generated, read and compared.
- Implements a fast buffer search algorithm
Beside these features YAMM provides debug facilities (e.g. memory map dump, usage statistics) and it is easy to integrate it with existing verification environments.
Yet Another Memory Manager (YAMM) is a SystemVerilog library that provides support for memory based operations:
- Buffers can be allocated following 6 allocation modes with any granularity or address alignment
- Buffers can be inserted by user (non-overlapping)
- Buffers can be deallocated either by address or by handle
- Buffers can be searched for in the memory space by address or by handle
- Buffers support payload, which can be assigned by the user, randomly generated, read and compared.
- Implements a fast buffer search algorithm
Beside these features YAMM provides debug facilities (e.g. memory map dump, usage statistics) and it is easy to integrate it with existing verification environments.
SystemVerilog Assertions(SVA) play a central role in functional verification of protocols, encompassing feature checking and coverage. In order to benefit from assertion advantages (fast, synthesizable, nonintrusive, coverable), we must verify that they pass or fail as described by the protocol specification. In turn this requires to implement the sequences of stimuli that properly trigger the assertion (making it pass or fail) and checks to ensure its correct behavior under the given conditions. We developed the SVAUnit framework with three objectives in mind:
- decouple SVA test logic from SVA definition
- simplify the creation of stimuli/checkers that validate the SVA
- simplify test and stimuli maintenance
SVAUnit is a simulator independent, UVM compliant package that combines the unit testing paradigm of the software world with the powerful feature of assertions from SystemVerilog.
SystemVerilog Assertions(SVA) play a central role in functional verification of protocols, encompassing feature checking and coverage. In order to benefit from assertion advantages (fast, synthesizable, nonintrusive, coverable), we must verify that they pass or fail as described by the protocol specification. In turn this requires to implement the sequences of stimuli that properly trigger the assertion (making it pass or fail) and checks to ensure its correct behavior under the given conditions. We developed the SVAUnit framework with three objectives in mind:
- decouple SVA test logic from SVA definition
- simplify the creation of stimuli/checkers that validate the SVA
- simplify test and stimuli maintenance
SVAUnit is a simulator independent, UVM compliant package that combines the unit testing paradigm of the software world with the powerful feature of assertions from SystemVerilog.
SystemVerilog Assertions(SVA) play a central role in functional verification of protocols, encompassing feature checking and coverage. In order to benefit from assertion advantages (fast, synthesizable, nonintrusive, coverable), we must verify that they pass or fail as described by the protocol specification. In turn this requires to implement the sequences of stimuli that properly trigger the assertion (making it pass or fail) and checks to ensure its correct behavior under the given conditions. We developed the SVAUnit framework with three objectives in mind:
- decouple SVA test logic from SVA definition
- simplify the creation of stimuli/checkers that validate the SVA
- simplify test and stimuli maintenance
SVAUnit is a simulator independent, UVM compliant package that combines the unit testing paradigm of the software world with the powerful feature of assertions from SystemVerilog.
SystemVerilog Assertions(SVA) play a central role in functional verification of protocols, encompassing feature checking and coverage. In order to benefit from assertion advantages (fast, synthesizable, nonintrusive, coverable), we must verify that they pass or fail as described by the protocol specification. In turn this requires to implement the sequences of stimuli that properly trigger the assertion (making it pass or fail) and checks to ensure its correct behavior under the given conditions. We developed the SVAUnit framework with three objectives in mind:
- decouple SVA test logic from SVA definition
- simplify the creation of stimuli/checkers that validate the SVA
- simplify test and stimuli maintenance
SVAUnit is a simulator independent, UVM compliant package that combines the unit testing paradigm of the software world with the powerful feature of assertions from SystemVerilog.
Verification of high computational algorithmic RTL (e.g. digital signal processing) requires complex mathematical models that are hard to implement and slow to run in any of the existing hardware verification languages. Using numerical computing languages (e.g. Octave, Matlab) to code these models will dramatically speed up the verification sign-off by reuse of mathematical functions (e.g. predefined DSP functions) that are already verified. This also has a low risk of algorithm implementation bugs and guarantees optimal implementation for maximum simulation performance.
This paper illustrates typical usage of external mathematical models inside the verification environment using SystemVerilog as the verification language and Octave, an open source sibling of Matlab, as the numerical modeling language.
We do pre-silicon verification in multiple iterations, each iteration including at least a regression. Regressions consume a great deal of HW resources (e.g. CPU time) and SW resources (e.g. licenses) and… a lot of human effort. This is what usually happens when we run a regression: we aim to reduce the time spent in regression analysis, especially when we run regressions at a fast pace, for example overnight. We want to see the results in a simple, easy to read report, as soon as possible. We are eager to start debugging issues immediately, instead of aggregating and organizing those tons of information resulting from running a regression. We expect everyone in the team to keep up to date on the regression status with virtually no effort. And in the long run, we want to have a history of regression’s progress.
This poster shows a different way of dealing with these challenges using practical regression automation scripts. The scripts can help your team to save a lot of time and deal in an effective way with the regression results.
If you want to cover a bus activity you can either use bit toggling or define coverage ranges as power-of-2 intervals. As bit toggling is not very relevant (can be covered very quickly in one transition from 0 to MAX_VALUE) the second option is preferred. But using power-of-2 coverage creates another problem: coverage intervals are uneven and covering the smaller bins takes a lot of time. In large projects it can take weeks of regressions time to fill all of them.
This poster illustrates how the stimuli generation can be tweaked so that the smaller bins are hit just as often as the larger ones.
Table of Contents
Data Types
Integer data types
Type | Description |
---|---|
bit | 2-state data type, user-defined vector size representing unsigned data |
byte | 8 bit 2-state integer representing signed data or ASCII character |
shortint | 16 bit 2-state integer representing signed data |
int | 32 bit 2-state integer representing signed data |
longint | 64 bit 2-state integer representing signed data |
logic | 4-state data type, user-defined vector size, unsigned data |
reg | 4-state data type, user-defined vector size, unsigned data |
wire | Used to connect different elements in a design. They can be read or assigned, but no values can be stored in them. |
integer | 32 bit 4-state integer representing signed data |
time | 64 bit 4-state integer representing signed data |
Real data types
Type | Description |
shortreal | 32 bit, single-precision, floating-point number |
real | 64 bit, single-precision, floating-point number |
realtime | 64 bit, single-precision, floating-point number |
Enum data types
Declares a user-defined enumerated type having a set of explicitly named values. Syntax:
enum data_type {item[0], item[1], ...} enum_type_name;
Defaults | Description |
data_type | If not specified data type defaults to int.
Example:
|
item[0] value | If not specified the first item in an enumerated list will be represented as 0 |
item[n] value | If not specified the n-th item in an enumerated list will be represented as item[n-1] + 1 |
Method | Description |
first() | Returns the first value of an enumeration |
last() | Returns the last value of an enumeration |
next(N) | Return the N-th next value, wrapping to the beginning if needed. Default N = 1. |
prev(N) | Return the N-th previous value, wrapping to the end if needed. Default N = 1. |
num() | Returns the number of values in the enum |
Struct data types
Type | Description |
Unpacked (default) | Syntax:
Access to a certain field: <struct_name>.<field_name> |
Packed | Syntax:
Members of a packed structure can be accessed either by their name, or by indexing a vector. By default the first field will be the leftmost item in the vector: Example:
In this case my_struct[0] is my_struct.data[0] |
Dynamic array
A dynamic array is an unpacked array whose size can be set or changed at runtime. Syntax:
type array_name[];
array_name = new[expression1](expression2);
expression2 is an optional initialization of the array
Method | Description |
new[expression] | Constructor that sets the size of the dynamic array and initializes its elements
Example:
|
size() | Returns the current size or 0 if the array is not created or if it was deleted. Example:
|
delete() | Empties the array, resulting in a zero-sized array
Example:
|
Queue data type
Syntax:
<type> my_queue[$:max_size]; //where max_size is optional
Example:
int q_int[$];
my_class my_q[$:5]; // accepts maximum 6 elements
Method | Description |
size() | Returns current size of the queue |
insert(i,d) | Inserts item d at index i |
delete(i) | Deletes item at index i, if index is omitted, deletes queue |
pop_front() | Reads and removes the item from the front of the queue |
pop_back() | Reads and removes the item from the back of the queue |
push_front(d) | Adds item d to front of the queue |
push_back(d) | Adds item d to back of the queue |
Casting
Static Cast
In a static cast, if the expression is assignment compatible with the casting type, then the cast shall return the value of a variable of the casting type. Syntax:
casting_type‘(expression)
Example 1:
shortint a;
int b;
b = int’(a);
Example 2:
logic[7:0] register;
register = signed’(4’b1100) // register = -4
Example 3:
shortint a;
int b;
b = a; // implicit cast
Dynamic Cast
Used to assign values to variables that might not ordinarily be valid because of differing data types. Syntax:
function int $cast(destination, source)
task $cast(destination, source)
If the assignment is invalid, a task will generate a runtime error, while the function will return 0.
typedef enum(idle,busy,pause,done) state;
state current_state;
if(!$cast(current_state,6)
$display(“Error in cast”);
Classes
Class Declaration Syntax:
class my_class;
constructor
local/static/protected items
Methods/method prototypes
endclass
Class Instance Syntax:
my_class obj; // declare an object of class my_class
Obj = new(); // initialize variable to a new allocated object of class my_class
Relevant keywords
Keyword | Description |
static | A static class field shares its value with all instances of the class A static method can only access static properties, but it can be called even when no class instances exist by using class name and the scope resolution operator. Example:
|
this | The this keyword gives unambiguous access to members of the current class instance
Example:
|
super | The super keyword gives unambiguous access to members of the parent class of the calling object.
Example:
|
virtual | A virtual class is an abstract class which can only be inherited, but not instantiated. |
const | Class properties can be made read-only by using a const declaration.
Example:
|
Encapsulation
Keyword | Description |
local | Used to specify that class members are only visible within the class where they were declared.
|
protected | Used to specify that class members are only visible within the class where they were declared and any subclasses.
|
Inheritance
Keyword | Description |
extends | It is used to create a new class that inherits the members of a base class.
|
Polymorphism
Keyword | Description |
virtual | Virtual (class method) is used to define basic polymorphic constructs. A virtual method is used to override a method in all of its base classes.
|
Parameterized classes
Class implementation can be customized by using class parameters. Example:
class vector#(int size = 1)
bit [size -1 : 0] a;
endclass
class stack#(type T = int)
local T items[];
...
endclass
Instantiation:
vector#(10) a = new();
stack#(real) b = new();
Interface class
The interface class is a class that can be viewed as having a common set of behaviours. An interface class shall contain only pure virtual methods, type declarations and parameter declaration, all other blocks and declarations shall not be allowed.
Syntax:
interface class class_name [extends interface_class_type]
// pure virtual methods
// parameters
// type declarations
endclass
A class may implement one or more interface classes.
Example:
interface class set_data#(type SET_TYPE = logic)
pure virtual function void set(SET_TYPE a);
endclass
interface class get_data#(type GET_TYPE = logic)
pure virtual function void get();
endclass
class my_queue#(type T =logic, DEPTH = 1);
T q[$:DEPTH - 1]
virtual void function delete_queue();
q.delete();
endfunction
enclass
class fifo (type T = logic, DEPTH = 1)
extends my_queue#(T, DEPTH)
implements set_data#(T), get_data#(T);
virtual function void set(T a);
q.push_back(a);
endfunction
virtual function void get();
q.pop_front();
endfunction
endclass
Copy-Constructor
The copy constructor is a constructor which creates an object by initializing it with an object of the same class, which has been created previously. Example:
class my_class;
int x,y;
function new();
// simple constructor
endfunction
function new(my_class obj);
this.x = obj.x;
this.y = obj.y;
endfunction
endclass
Operators
Symbol | Description |
= | Binary assignment operator |
+= -= /= *= | Binary arithmetic assignment operator |
%= | Binary arithmetic modulus assignment operator |
&= |= ^= | Binary bitwise assignment operator |
>>= <<= | Binary logical shift assignment operator |
>>>= <<<= | Binary arithmetic shift assignment operator |
+ – * / ** | Binary arithmetic operators |
% | Binary arithmetic modulus operators |
& | ^ | Binary bitwise operators |
>> << | Binary shift operators |
! | Unary logical negation operator |
~ & ~& | ~|
^ ~^ |
Unary logical reduction operator
Example: &y will return the result of an AND operation between all the bits of y |
&& || | Binary logical operations |
< > <= >= | Binary relational operation |
== != | Binary logical equality operators |
=== !== |
Binary case equality operators.
Unlike logical equality operator, this operators can identify x and z. |
++ — | Unary increment/decrement operation |
Package
package my_pacakge;
//classes
//variables
//functions
//structs
//etc..
endpackage
Wildcard import – Imports all symbols within the package
import my_package::*;
Explicit import – Imports only the mentioned symbol from the package
import my_package::my_symbol;
Processes
Parallel processes:
fork
begin
//Task 1
end
begin
//Task 2
end
begin
//Task n
end
join_keyword
join_keyword | Description |
join | The fork completes when all tasks complete |
join_any | The fork completes when the first task is completed |
join_none | The fork completes immediately |
Verification Features
Randomizations
Declaration | Description |
rand | Used in class declaration to specify that a class property is a random variable with an uniform distribution
|
randc | Used in class declaration to specify that a class property is a random variable with an cyclic distribution
X can take on values in rage of 0 to 3. Randomize will compute an initial random permutation of the range values and return them in order on successive calls. Initial permutation 0,2,1,3 next permutation 2,3,0,1 The values will be generated in the following order 0,2,1,3,2,3,0,1. |
Function | Description |
std::randomize() | It is a built-in function used to randomize local variables or class properties
The randomize function will return 1 if the randomization was successful or 0 otherwise. |
randomize(class method) | Built-in method used to randomize all properties declared with rand and randc. The properties that are not declared rand or randc can still be randomized if they are passed as arguments.
Cannot be overridden!
|
pre_randomize() | Built-in method that is called by the randomize() method before the objects are randomized.
|
post_randomize() | Built-in method that is called by the randomize() method after the objects are randomized.
|
Constraint
Used in class-based randomization, restricting values to specific ranges.
Syntax:
constraint name_c {<constraint_item>;}
class my_class;
rand int random_value;
constraint random_value_c{
random_value >= 0;
random_value <= 15;
}
endclass
Constraint item | Description |
solve..before… | Defines the order of generation for multiple values
Syntax:
Example without solve…before…:
In this case we have three possible combinations (set,reset) = {(0,0);(0,1);(1,0)} each having a 33% chance of occurring. Example with solve…before…:
In this case set is solved first, so (set,reset) = (1,0) has a 50% chance of occurring, instead of 33%. |
foreach | Used to specify constraints over the elements of an array
|
soft | Designates a constraint that is to be satisfied unless contradicted by another constraint with an higher priority.
|
Keyword | Description |
inside | Comparison operator which is true if an expression is contained within a specific list
|
dist | Used to define weighted distributions
Syntax:
The operator is one of the following
Example:
|
with | Used to specify in-line constraints for randomization.
Syntax:
|
Operators and methods | Description |
-> | Implication operator used for conditional constraints. It is similar to the if construct.
Syntax:
Similar to:
|
constraint_mode() task | Used to enable and disable class constraints.
Syntax:
|
constraint_mode() function | Returns the current status of a constraint
Syntax:
|
Functional Coverage
Covergroups
Defines probes that sample relevant information from functional coverage and defines how coverage results will be reported.
covergroup name_cg <coverage event>
//coverpoints
//cross
endgroup
<coverage event> could be:
- @(block_event) example: @(posedge clk)
- with function sample([port_list])
Initialization code:
name_cg = new();
name_cg.set_inst_name(“my_name”);
Coverpoints
Identifies a variable that will be tracked for coverage
Syntax:
coverpoint variable [iff (boolead_expresion)]
{ /* bins */ }
If no bins are defined , the coverpoint creates an automatic bin for every value of the variable.
covergroup my_cg with function sample(bit[31:0] addr)
coverpoint addr iff(rst_n);
{
bins null_addr = {0};
bins valid_addr = {[2:20]};
}
endgroup
Cross
Correlates bins from two or more coverpoints so that an inter-variable value relationship can be explored.
Syntax:
cross expression1 , expression2, … expression n [iff (boolean expression)];
// or
cross expression1 , expression2, … expression n [iff (boolean expression)]
{ /* user defined cross coverage bins; */ }
covergroup my_cg with function sample(bit signal1,bit signal2)
coverpoint signal1;
coverpoint signal2;
cross signal1, signal2;
endgroup
Transitions
Type | Description |
Sequence | A transition from valueA to valueB is defined as such: valueA => valueB 0 => 1 |
Set | Syntax:
|
Consecutive repetitions [*n] | Syntax:
|
Range of repetitions [*n:m] | Syntax:
Example:
|
Goto repetition[->n] | Syntax:
Examples:
Where … is any transition that does not contain the value 1
Notice that the last transition happens immediately after the second 1 to 1 transition. |
Nonconsecutive repetition[=n] | Syntax:
Example:
Where … is any transition that does not contain the value 1
Notice that the transition following the nonconsecutive repetition may occur after any number of transition as long as the value 1 doesn’t occur again. |
Bins
Type of bins | Description |
bins | Allows explicit named coverage bins to be defined and a range of values to be tracked for each bins.
|
wildcard bins | Allows x,z and ? as wildcard values in bins definition
|
illegal_bins | Identifies that a certain range of values are illegal. |
ignore_bins | Identifies that a certain range of values are excluded from coverage. |
default | Default bins are used for all values not covered in other bin ranges. Default bins are not tracked in cross-coverage.
|
Assertions
Type | Description |
Immediate assertions | Syntax:
|
Concurrent assertions | Are SVA directives used to verify that a property holds. Syntax:
|
Cover | Is SVA directive used to verify that a property occurs during simulation. Syntax:
|
SVA Syntax
Sequences
Sequence Type | Description |
Temporal delay ## with integer |
|
Temporal delay ## with range |
|
Consecutive repetition [*m] or range [*n:m] | Where n,m re natural numbers, m>n>=1. The $ sign can be used to represent infinity
|
Non-consecutive repetition [=n], [=n:m] | Example 1:
This is a shortcut for the following sequence
Example 2:
|
Goto non-consecutive repetition [->n], [->n:m] | Example 1:
The difference between the two non-consecutive repetition is that the pattern
Observe that signal_1 is matched before returning to the LOW state. Example 2:
|
Properties
Operator | Description |
Overlapping sequence implication operator |-> | Syntax:
sequence_2 will start in the same clock cycle in which sequence_1 will end Example:
|
Non-overlapping sequence implication operator |=> | Syntax:
sequence_2 will start one clock cycle after sequence_1 has ended
Observation! |
System functions
Function | Description |
$onehot(signal) | Returns true if only one bit of the signal HIGH |
$onehot0(signal) | Returns true if only one bit of the signal is LOW |
$isunknown(signal) | Returns true if at most one bit of the signal is X or Z |
$rose(signal) | Returns true if the signal has changed value to 1 in the current evaluation cycle |
$fell(signal) | Returns true if the signal has changed value to 0 in the current evaluation cycle |
$stable(signal) | Returns true if the signal has the same value as it had in the previous evaluation cycle |
#past(signal, number_of_cc) | Returns the value of the signal at a previous evaluation cycle specified through the number_of_cc argument |
Design and Verification Blocks
Block | Description |
Module | Syntax:
|
Interface | Syntax:
An interface can have different views by defining modports.
Module declaration:
|
Virtual Interface | A virtual interface is a variable that represents an interface instance, providing a mechanism of separating abstract models from the actual RTL implementation. Syntax:
|
Table of Contents
SystemVerilog Assertions
Type | Description |
Immediate assertions | Syntax:
|
Concurrent assertions | Are SVA directives used to verify that a property holds. Syntax:
|
Cover | Is a SVA directive used to verify that a property occurs during simulation. Syntax:
|
SVA Syntax
Property
Declaration:
property my_property[(port0, port1, ...)];
//assertion variable declarations
// property_statement
endproperty
Operator | Description |
Overlapping sequence implication operator |-> | Syntax:
sequence2 will start in the same clock cycle in which sequence1 will end
|
Non-overlapping sequence implication operator |=> | Syntax:
sequence2 will start one clock cycle after sequence1 has ended
|
not | Syntax:
|
and | Syntax:
|
or | Syntax:
|
until | Syntax:
|
until_with | Syntax:
my_property evaluates to true if property1 evaluates to true for every clock cycle beginning with the starting point, and finishing the same cycle when property2 starts to evaluate to true. Example:
|
disable iff | Syntax:
Causes the assertion checking to be terminated if the boolean condition is evaluated to TRUE.
|
Sequences
Declaration:
sequence my_sequence [(port0, port1, ...)]
//assertion variable declarations
//sequence expressions
endsequence
Operator | Description |
Temporal delay ## with integer |
|
Temporal delay ## with range |
Delay = 0 |
Consecutive repetition [*m] or range [*n:m], [*],[+] | Where n,m are natural numbers, m>n>=1. The $ sign can be used to represent infinity. Example:
The length of signal1 is 1 clock cycle Abbreviations:
|
Non-consecutive repetition [=n], [=n:m] | Example 1:
This is a shortcut for the following sequence
Example 2:
|
Goto non-consecutive repetition [->n], [->n:m] | Example 1:
The difference between the two non-consecutive repetition is that the pattern matching is finished after the last active pulse.
Observe that signal1 is matched before returning to the LOW state Example 2:
|
and | Syntax:
Example:
The evaluation starts at the same clock time (if each sequence has it’s own clock, then the AND starts at the first clocking event of each sequence), but it is not necessary to finish at the same time. The and sequence fails to match when any of the sequences fail to match. |
or | Syntax:
Example:
The result of OR-ing two sequence is a match when at least one of the two sequences is a match. |
intersect | It is similar to the and operator, except that the the two sequences must end at the same time. Syntax:
Example:
|
within | Syntax:
Example:
A match must satisfy the following conditions:
|
throughout | The throughout operator specifies that a signal must hold throughout a sequence. Syntax: signal throughout seq Example:
|
Method | Description |
first_match | Used to specify that only the first sequence match is considered from a range of possible matches, the rest being discarded. Syntax:
Example:
my_seq generates an infinite number of threads and an infinite number of matches. To prevent unexpected errors the first_match method is used to ensure that only the first of multiple matches is considered. Implicit first_match:
Example: Possible match2
The first match of a consequent causes the property to hold and to successfully complete the Required first match:
Each thread generated by an antecedent must match to cause the property to hold. If a thread Successful assertion with first_match |
triggered | Used to test if the end point of a sequence was reached. An end point is a boolean expression that represents the evaluation of a thread at its last clock cycle. Syntax:
Example:
|
Variables
Declaration of a sequence:
sequence my_sequence[(Formal arguments)]
//Assertion Variable Declaration
endsequence
Types | Description | ||||||||||||
Legal Types | Legal local variable types
|
||||||||||||
llegal types | Illegal local variable types
|
||||||||||||
Initialization | Rules:
Fa_signal will be initialized first with the preponed value of signal1, then avd_signal will be initialized. Initialization of Formal Arguments:
|
||||||||||||
Assignments | Local variables can be assigned within the sequence matched item list, each variable being separated from each other by using comma in the parentheses. The variables are assigned in order of appearance. Non-local variables cannot be directly assigned in a sequence, it is necessary to assigned them through function calls. Example:
Assignments can be used in repetitions:
|
||||||||||||
User-defined repetitions | Local variables cannot be used in temporal ranges, but they can be used as counters for user-defined repetitions or delays. Illegal use of local variables
Legal use of local variables
|
||||||||||||
Passing and binding Local Variables to instance of a subsequence | Method 1: Using an untyped formal argument
my_seq is equivalent to:
Method 2: Using a typed formal argument
In this case the end point of binded_seq(s) must occur 1 clock cycle after signal2 was asserted. The starting point of binded_seq(s) is before signal2 is asserted. |
||||||||||||
Using and, or, intersect with local variables | Using local variables on parallel “or” Threads. The or operand generates two concurrent threads, each thread having separate copies of the local variables. If a local variable is set on one thread, the other thread wouldn’t be able to access it. Using local variables on parallel “and”/”intersect” Threads. The and/intersect operands generate two concurrent threads, each having separate copies of the local variables. At the end of the evaluations, the two threads are merged into one. This will create problems when a local variable is assigned in both threads, and later used after the threads are merged.
Example:
In this case we have an illegal assignment of signal_cp in both threads.
|
System functions
Function | Description |
$onehot(signal) | Returns true if only one bit of the signal HIGH |
$onehot0(signal) | Returns true if only one bit of the signal is LOW |
$isunknown(signal) | Returns true if at most one bit of the signal is X or Z |
$rose(signal) | Returns true if the signal has changed value to 1 in the current evaluation cycle |
$fell(signal) | Returns true if the signal has changed value to 0 in the current evaluation cycle |
$stable(signal) | Returns true if the signal has the same value as it had in the previous evaluation cycle |
$past(signal, number_of_cc) | Returns the value of the signal at a previous evaluation cycle specified through the number_of_cc argument |
Recommended Articles – December 2022
AMIQ is a constant presence at DVCon Europe conference (both AMIQ Consulting and AMIQ EDA). If you haven’t been able to attend the conference or you’ve missed one presentation which was of interest for you, go ahead and read the highlights from our perspective. The highlights article is a joined effort of my colleagues and gives you the pulse from our verification community: Highlights of DVCon EU 2022
In design and verification we often use these two terms: latency and throughput. Here is a short article from Cadence to clarify on their meaning: Understanding Latency versus Throughput
Verifying status registers in an RTL design might get tricky. You normally need to consider a so called grey area/zone verification, where the expected value is not always the last update one. Cristian Slav, has detailed for e-language on how to use the built in features of vr_ad register model in order to achieve this kind of verification. Read more in his article: The Hidden Feature of vr_ad: Gray Zone Comparison
For those of you using GIT, here is a short article explaining why you should use the git rebase command: Git Rebase Explained
This is the last recommended article for 2022. Change and unrest seems to define the current world. I challenge you to find the source of peace so that it may settle inside you and from there to radiate to the people around you and to the whole world. The world can rest and find peace only if every one of us, starting with myself becomes thankful, joyful, humble, faithful, merciful, forgiving, caring and loving.
I wish you a Merry Christmas and a Happy New Year. Enjoy your holidays.
See you in 2023!
Recommended Articles – September 2022
Cristian / CFSVision has enhanced the standard UVM messaging with a new `uvm_infos macro that accepts multiple message tags. `uvm_infos enhances the fine tuning of message streams, which in turn increases the debug focus while shortening the debug time.
Our industry relies on commercial EDA tool chains to get from idea to physical implementation. The Ultimate Guide to Open Source EDA Tools presents an Open Source alternative that covers the full path from design to implementation.
Recommended Articles – August 2022
Hey, it’s summer and internships are underway. VerilogPro’s posts on Verilog and SystemVerilog might come at hand when you explain various concepts to newbies. His latest post addresses the concept of module (we are a bit late with this one).
We also found a contribution of Lucas Klemmer/Institute for Complex Systems to the OpenSource EDA community: Waveform Analysis Language. WAL provides an interactive command line that allows one to search for signal patterns or do post-simulation processing of waves. One can define the pattern-search function using a LISP-like syntax and apply it on a set of signals. For more information and references I encourage you to read the DAC’22 paper or inspect WAL’s GitHub repo.
Recommended Articles – July 2022
Elihai Maicas describes how to use SystemVerilog command line to control the value of a SystemVerilog class field and how to enable or disable SystemVerilog constraints. The two LinkedIn posts are a must read for any engineer that wants to add extra-flexibility to the verification environment control. The first post presents how to add hierarchy to an uvm_object class and the second one uses the implementation from the first post in order to turn on/off a constraint-block from the command-line.
Coaching the next generation of [verification] engineers requires to build work relationships based on trust, communication and shared values. Setting internship expectations is the first thing we do for the internship to start off on the right foot.
One of the most important component within a verification environment is the scoreboard. Debugging scoreboards can be very difficult and the worst type of errors are those involving race conditions. Here is a complete and interesting approach on how to avoid race conditions when dealing with data coming from parallel threads. Of course, this is not the only solution/way of dealing with race conditions. But it is the first one which provides so many levels of details, openly in the web.
Recommended Articles – June 2022
FIFOs are among the most commonly used design components inside an RTL. Verifying a FIFO requires using the same approach almost all the time. We can see a pattern in how we verify its functionality. Ovidiu, one of my colleagues, has compiled a list of the most common functional coverage aspects we need to think of when dealing with FIFOs: Functional Coverage Patterns – FIFO
Working with registers in e-language requires several steps you need to do. Here is a summary of these steps in order to setup vr_ad (the e-language register model): How to Startup vr_ad e Library
Recommended Articles – May 2022
This year the DVClub conference approached an interesting topic: Alternative Test Bench Architectures. For sure every company has its own way of building test bench architectures. Infineon has presented an architecture in which the Generation is decoupled from the Simulation phase for an IP test. The video presentation can be viewed over here. This architecture has been detailed even further in the second presentation called: ADAS IP Case Study: De-Coupled Generation and Simulation for Functional Verification
The SystemVerilog language has some pitfalls and not all of us are aware of them. I’ve encountered one particular pitfall in multiple projects. Thus, I’ve decided to raise the awareness of our community by sharing it in the following article: Gotcha: Calling Virtual Functions From SystemVerilog Class Constructor new() Method
Recommended Articles – April 2022
After a 4 years pause, Jason Yu, from Intel, wrote a new article on his website Verilog Pro. It is more of a tutorial, about the always block from Verilog/SystemVerilog. I like his writing style and it worth reading. As he puts it in words: ” I have a new goal to create a series of articles to help new engineers transition from “textbook knowledge” to real world knowledge needed to become a digital design engineer“.
Extending a method in e-language is straightforward due to the following constructs: is also, is first, is only. But in certain situations things get a bit unclear. Cristian Slav, posted on his blog an article about how does the return statement work when dealing with method extensions.
A new entry on our list: Michael Green has a blog about verification. My colleagues have spotted this article about the history of constrained random verification and why do we do it in this way. It is a nice introduction for someone who is in the learning stages of verification methodologies.
Recommended Articles – March 2022
Initially announced as a face-to-face conference, DVCon US 2022 was held virtually, for one more year in a row. For us in AMIQ, a company based in Romania – Europe, having DVCon US as a virtual conference is an advantage. We were able to attend most, if not all, of the interesting presentations from the conference. My colleague, Andrei Vintila, along with several others, have put together another highlight for this year’s content. If you missed the conference, don’t miss its highlights.
Cristian Slav, has shared another interesting topic with us. How to use UVM callbacks to update values of the configuration fields. Have a look at it, maybe you’ll find it useful in one of your current or future projects.
Recommended Articles – December 2021
Here we are, at the end of 2021. It was another challenging year. During 2021 as well as 2020, working from home was probably the established norm among our industry. Some of you, have probably started a back-to-the-office process, where the real, face to face interaction is one of the most important part. Even so, working from home or from the office, I’m sure that my industry peers are still setting the standards high in order to architect, design, verify and deliver new and innovative technologies for the benefit of every human.
Now, it’s time for a rest. Balance your work. Take a step back, relax and recharge your batteries. Reflect on the past events, envision the future events, think about the real meaning of life, celebrate with your family, appreciate your friends, forgive the wrongdoers, be humble, pray if you are a believer, nourish your feelings with a positive vibe, forget about work, be grateful for what you have, help the others. If not now, then when?
I wish you a Merry Christmas, enjoy the winter holidays and see you in 2022!
Recommended Articles – November 2021
Similar to 2020, DVCon Europe 2021 conference was set to be online in a virtual environment. AMIQ attended the conference from the viewer seat. My colleague, Ionut Ciocîrlan, orchestrated a nice article about the technical content of the conference. This article is a joint effort of several colleagues. Here are the Highlights of DVCon EU 2021.
DVClub Europe 2021, is another verification related conference. It is organized every year by Mike Bartley from TVS. This time the main focus of the conference was machine learning and artificial intelligence and their usage in EDA tools. The content of the conference was a mix of technical and marketing information. You can check out the slides/videos on TVS website. Cadence, Siemens and Brekker were the companies to showcase their ML and AI EDA capable tools.
From this conference I found out that Verifyter with their PinDown tool was acquired by Cadence and OneSpin was acquired by Siemens.
Recommended Articles – October 2021
This year in June, Tom Fitzpatrick has addressed an interesting and actual topic in a discussion with 5 experienced engineers: Remote Work, Remote Chip Design: Building Chips During a Pandemic. While listening to the industry mates, I found it very easy to relate to their own experience from this pandemic period. Working from home is not something new in our industry, but the scale of it. New challenges appear, collaboration is now different, the synergy of technology and social side of our work is observed and sometimes redefined. I’m sure you will find the discussion very interesting.
ESD Alliance and Accellera looked beyond the pandemic as companies start bringing employees back to the office. A panel of experts explored an executive view and strategies of how the transition from remote work back to the office will unfold: The executive view – returning to the office
Recommended Articles – September 2021
Steven Leibson, from Electric Journal, has compiled a top view list regarding what should make you choose or not choose one of these two hardware paradigms: FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit). The comments thread is interesting also, since industry mates share their experience and oppinion regarding the FPGA vs ASIC topic. Read the article and enjoy the comments over here:
Building chips 11 Reasons You Should NOT use an FPGA for a Design, and Four Reasons You Should
Cristian Slav, from CFSVision, shows one way of avoiding class overrides, but still be able to access protected fields/methods of a class. Sounds strange, but you may decide for yourself if you need that and if it helps or not: How to Access a Protected Property or Method in SystemVerilog
Recommended Articles – August 2021
Iuliana Leuștean from Amiq describes how to upscale images using machine learning and what to expect in terms of performance and image quality when comparing it with classic interpolation algorithms. She managed to get great results by using high-level synthesis on FPGA. Read more in the full article.
Recommended Articles – May 2021
Specman/e-language community has had the opportunity to share ideas and ask questions about the most interesting feature of the language: macros. Here is an article which centralizes this Q&A session. Those having a Cadence support account can also watch the video presentation over here.
Recommended Articles – April 2021
My colleague Mihai-Corneliu Cristescu is researching ways to enhance functional verification using intelligent automation. He did a thorough review and analyzed Machine Learning Techniques for Improving the Performance Metrics of Functional Verification. He wrapped up and published his conclusions in the Romanian Journal of Information Science and Technology. You can see a written summary over here and read the details over here.
Using Python in verification is not a brand new thing, but for sure it did not reach the mainstream attention of the verification community. I admire that DVClub Europe 2021 conference invited the community to discuss this topic. I invite you to go through the slides and watch the video recordings on the TVS website. I would also like to list the highlights of the conference: PyUVM – Using Python in Verification, Constrained Random Stimulus Generation in Python, Coverage in Python – pros and cons, Why you shouldn’t use Python in Verification and Processor Verification in Python,
Recommended Articles – March 2021
My colleagues Ioana Catalina Cristea and Dragos Dospinescu have created a novel approach in co-emulation, validated with leading FPGA platform. It is called OFC (Open-source Framework for Co-emulation). They have put a significant effort in getting this framework out there to the public and this effort was rewarded by receiving the third place Stuart Sutherland best paper award at the DVCon US 2021. You can view the video presentation over here, see a written summary over here, read the details over here and browse the code over here.
If you ever wonder what happened during DVCon US 2021, Ionut Ciocirlan has summarized a lot of the technical presentations under Highlights of DVCon US 2021. Don’t miss it, maybe you can find interesting presentations.
Recommended Articles – February 2021
AMIQ is going to participate at DVCon US 2021. Here is the announcement of our presentation.
Last year, Tudor Timisescu from the Verification Gentleman published an article about Formal Verification. More exact it is A Comparison of Formal and Simulation for a Simple, Yet Non-Trivial Design – Part 1. In this part 1 he describes an imaginary design and builds assertions and properties out of it, for the scope of using formal verification concepts.
Even if the following is a presentation from 2019 DVCon conference, it is still valuable for people using UVM. Cliff Cummings, has a great experience with SystemVerilog and UVM. He is one of the people who worked on the Verilog and SystemVerilog standards. In these 2 videos posted on the Accellera website, he presents in a simple yet comprehensive way, how certain UVM mechanisms (e.g. messaging, transactions, sequences, analysis ports) are working or are intended to work. I highly recommend you view both presentations: Gain Valuable Insight into — and Make the Most Out of — the Changes and Features that Are Part of the New IEEE 1800.2 Standard for UVM
Last year, Chris Spear and Rich Edelman, wrote several UVM coding guidelines on how to offer clarity in a complex world.
Yoav from Foretellix, continues his quest to understand and define ADAS (Advanced Driver-Assistance Systems) and AV (Autonomous Vehicle) related topics. This time he is looking on how to estimate the residual risk of ADAS / AV: part1 and part2
Recommended Articles – January 2021
We’ve been thinking that good technical articles are always valuable and sometimes you want to see them all in one place. AMIQ brings forward another technical resource for any verification engineer. All our recommended articles since 2014, are now merged together and you can view them in the resource page which we call recommended articles aggregator.
Recommended Articles – December 2020
Specman and e-language abound in features, some of them are well known some others less known. In my last article, I focus on a less known feature which can be called as string templates
We come closer to ending a tumultuous 2020. Literally, the entire world has been challenged to rethink its priorities and values, given the pandemic situation. I hope and pray for a wiser, happier, and fearless 2021. I wish you all a Merry Christmas and a Happy New Year!
Enjoy the Holidays!
Recommended Articles – November 2020
AMIQ has published a new set of verification resources. Cheatsheets for SystemVerilog and for SystemVerilog Assertions. When in need, every verification engineer now has a reference where to quickly search for basic information. SystemVerilog and SVA Cheatsheet
Manish, from Learn UVM Verification, continues his series on UVM RAL. This time he shows how to implement UVM RAL.
Recommended Articles – October 2020
AMIQ has released a new UVC that facilitates register accesses. It is called Register Agent: Register Agent: A UVC for Register Access.
Manish from Learn UVM Verification explains why we need a UVM Register Abstraction Layer: Why UVM RAL is needed?.
Cadence released a new feature that allows you to integrate Python code into e-language. They now provide a nice example for visualizing the vr_ad register accesses in the form of a heatmap. The Python code is OpenSource and you may use it in your e-Language project: Ouch that’s Hot! Register Access Heatmap.
Recommended Articles – September 2020
Did you know that you can match strings using regular expressions from within SystemVerilog code? UVM implements a function called uvm_re_match. My colleague, Florin Oancea, explains how to use it and what you should pay attention at: How to Match Strings in SystemVerilog Using Regular Expressions
In the August edition of the recommended articles I mentioned a challenge launched by Neil Johnson. The answers to this challenge are now posted by Dave Rich in his SystemVerilog Race Condition Challenge Responses article. It is a good reference on what NOT to do when writing RTL or TB code.
Recently, I learned about an emerging and impressive AI System called GPT-3. This GPT-3 (Generative Pre-trained Transformer 3) is an autoregressive language model that uses deep learning to produce human-like text. David Chalmers, an Australian philosopher, described GPT-3 as “one of the most interesting and important AI systems ever produced”.
GPT-3 was used to write the following article. Can you distinguish it from a human being? A robot wrote this entire article. Are you scared yet, human?.
But how is this GPT-3 system being verified? Yoav Hollander, already started to think about its verification: GPT-3 and verification.
A LinkedIn post from Yousef B. Bedoustani, pointed out how same hardware design problem approached with two different mentalities can lead to very different solutions: RTL vs. Software Mentality in FPGA/ASIC Design; Latency From 161 to 2 Clock Cycle!
The FOSSI foundation announced that you can now produce your own physical chips. For free. In the Open. The “open” part is guaranteed by the open source PDK (Process Design Kit) called Skywater PDK. The “free” part is guaranteed by Google and efabless.
They are providing completely free of cost chip manufacturing runs: one in November this year, and multiple more in 2021. All open source chip designs qualify, no further strings attached!
May your ASIC come true!
Recommended Articles – August 2020
Ioana Cristea from Amiq shows how to achieve a non blocking communication between the SystemVerilog simulator and an external component, like Python: Non-Blocking Socket Communication in SystemVerilog Using DPI-C.
Neil Johnson and Dave Rich have launched a challenge to the verification community. Discover and fix race conditions inside 10 SystemVerilog code snippets. Read more in SystemVerilog Race Condition Challenge
Recommended Articles – July 2020
Neil Johnson announced he will take a step back and pass the leadership of SVUnit project to Tudor Timisescu, aka Verification Gentleman. SVUnit is a consistent and valuable contribution to the verification community and I am happy it is not lost. That’s the OpenSource spirit at work!
Welcome back Manish! After four years of silence, LearnUvmVerification comes back with: What is UVM RAL?.
Chris Spear, from Mentor, is inviting us to explore what importing a SystemVerilog package means.
The Fossi Foundation promotes the opportunity of producing your own physical chips. For free. In the Open.
Recommended Articles – June 2020
SystemVerilog Multidimensional Arrays is a juicy topic for a blog post given they are feature reach. Here is a post that explains some of the features: SystemVerilog Multidimensional Arrays
A long-awaited feature comes into existence: adjusting verification environment behavior based on collected coverage items in real time at run time. Specman team facilitates this operation by means of coverage callbacks: Improving Tests Efficiency using Coverage Callback (part 2)
Recommended Articles – May 2020
Regressions can be an important resource consumer. Daniel Ciupitu, from AMIQ Consulting, provides a recipe for optimizing the disk usage when running regressions: How To Optimize Disk Space When Running Regressions
Elihai Maicas, from Intel, talks about RAL classes and how they affect performance. He offers a tip on how to deal with that. Read more in his Verification tip of the day
Chris Spear, from Mentor, reveals tips and tricks from his verification journey. The last one is about UVM Configuration DB and how to optimize its performance.
Analyzing coverage during test run time and making decisions based on the coverage level. How does that sound? Specman introduced a coverage callback mechanism for exactly that. This new feature touches similar area as our AMIQ CoverageLens application. Have a look at both and thrust your verification power.
Recommended Articles – April 2020
Out of this DVCon presentation Tudor got inspired and extended the solution of adding constraints into their own objects. Take a look at his new UVM journey: Favor Composition Over Inheritance – Even for Constraints
Elihai Maicas, from Intel, started a series of verification tips. Here is one of them on how to turn assertions off: Dynamically Turn-off a System-Verilog Assertion
Chris Spear, from Mentor, presents in an intuitive way what are parameterized classes and static properties of the SystemVerilog classes.
Recommended Articles – March 2020
In the CNN using HLS post my colleague, Sergiu Duda, provides the long awaited code for the How to Implement a Convolutional Neural Network Using High Level Synthesis article.
HLS using C synthesis has brought FPGA implementation of computational intensive tasks into mainstream. Hardware for Deep Learning: Know Your Options article proposes a new solution, called LeFlow, where the High Level Synthesis is done directly from the Python code. LeFlow aims to realize a seamless transition between training on a GPU cluster and the deployment on an FPGA.
Recommended Articles – December 2019
In early 2018, AMIQ released a new library called FC4SC (Functional Coverage for SystemC). The community responded in a positive manner and started to evaluate it and asked for improvements. Late this year, the library has been donated to Accellera in order to fill the functional coverage gap from the SystemC world. More on the reasoning behind the library and its future in this article: AMIQ Consulting Contributes C++ Coverage Library to Accellera
Adam Rose, from Verilab, wrote a paper in the form of enhancement proposals for the SystemVerilog language standard. He looked at Python and C++ and tried to borough concepts and apply them to SystemVerilog. In this new SystemVerilog language quest (anonymous classes, introspection, decoration), he described how code constructs like uvm_macros, uvm_factory, constraints and functions would morph into a different kind of code constructs and not only. I think the final paragraph summarizes the goal of the paper:
In many ways, these enhancements simply bring SystemVerilog up to date with recent
developments in programming languages. By using them, Verification engineers will be able
to enhance their productivity by writing more concise, modular and maintainable code.
This is the last article for 2019, thus, I take the chance to wish you a Merry Christmas and hope, we all contribute to a better, safer and peaceful new year. Happy New 2020!
Enjoy the holidays!
Recommended Articles – December 2018
Sergiu Duda from AMIQ has put a lot of effort into creating a high quality article on the non-trivial topics of High Level Synthesis and Deep Learning. The later, is not found in the everyday terminology of a verification engineer. Deep learning is just a flavour of a bigger part called Machine Learning which in its turn is part of the bigger, Artificial Intelligence.
I do think you will get more meaning out of this topic after spending your time on reading his article: How to Implement a Convolutional Neural Network Using High Level Synthesis
Since 2018 is coming to an end and we are days apart from Christmas, I take the chance and wish you a Merry Christmas and hope that the new year brings joy and happiness to all of us.
Enjoy the holiday time!
Recommended Articles – November 2018
New data arrived from the 2018 Wilson Research Group Functional Verification Study. This research is done every two years and it shows trends in our functional verification domain. If you are interested in the data you can read the set of articles that will follow on verification horizons. Here are the first ones: Prologue, Part 1 and Part 2.
Cristian continues his series on SystemC tutorial. This time he is talking about module hierarchy and connectivity.
Recommended Articles – October 2018
Cristian from CFSVision wrote a short tutorial on how to work with SystemVerilog queues.
Cadence published a new article in the series regarding SystemVerilog code optimizations. This time it tackles the subject of creating and managing dynamic objects.
AnySilicon published an article aiming to describe the stages of ASIC production. The big picture always helps to a better understanding of our domain.
Recommended Articles – September 2018
In case of e-language it is the aspect oriented-nature of the language itself that helps cutting down the compile and simulation rerun time. You can read more about dynamic load or just-in-time patching: Adding a Patch Just in Time!.
I always try to find ways of shortening the time it takes to wait for various actions like: compilation, simulation, debug, analyze. Such a time saving feature is e-language’s patching/extension capability due to its aspect oriented nature of the language. But Cadence made it to the next level, adding a patch on top of an existing compilation or restarting a previous simulation from a specific timepoint and loading a new piece of code on top of the previous simulation. Read more in:
Verification Academy has published a new version of the UVM 1800.2 Cookbook. You need to login if you want to download it.
Recommended Articles – August 2018
In his article about how to avoid FIFO overflows, Stefan promised a second solution. Here is part II of the article presenting the solution which makes use of uvm constructs.
Neil from AgileSOC continues to simplify the SVAUnit framework. He makes use of his new mocking framework in order to decouple the driver from the sequencer. In this way he is able to UnitTest the UVM drivers without the sequencer. Then he applies the same concept on the sequences. Another idea from his side is make use of the popular wavedrom application in order to generate test stimuli for UnitTesting. I personally like the idea of transforming waveforms into a piece of code.
Recommended Articles – July 2018
AMIQ Education Program saga continues…. This years’ summer school received more attention from the students according to Stefan’s feedback: Digital Circuits Simulation and Verification Summer School.
FIFOs are encountered in many digital designs and the verification of such designs comes with specific challenges, one of them being to protect the FIFOs against overflow. You can read more about it in: How To Protect FIFOs Against Overflow post. An alternative implementation will be given in a follow-up post.
AMIQ and Cadence have exhibited at DAC 2018 on the support they provide for the new Portable Stimulus Standard (PSS): AMIQ and Cadence demonstrate Accellera PSS v1.0 interoperability.
Neil Johnson has created a mocking framework for the SVUnit called SVMock. You can read more about it here: SVMock Version 0.1.
Recommended Articles – June 2018
We present to you the SystemVerilog and VHDL Grammars in HTML format. The grammars represent the BNF (Backus-Naur Form) notation in an HTML format, with hyperlinks, anchors and tooltips. You can also download them from the GitHub repository.
John Neil, from AgileSOC, continues his reflection on how verification engineers should think about their testbench code: AgileSOC: Balancing Verification Development With Delivery.
Cadence continues its series of SystemVerilog code optimization. They are provided as guidelines, which if thought before writing a single line of code, can help with simulation performance: Part II, Part III.
Here is a new way of controlling e-language generator. It is done by the help of the so called Range Generated Fields: Empowering Generation – Range Generated Fields (RGF).
In June the verification community had an opportunity to share ideas and solutions regarding verification, by means of Verification Futures 2018 conference. If you missed it, you can check out the presentation slides and videos over here: Verification Futures 2018.
Recommended Articles – May 2018
Here is an interesting article discussing if any FPGA implementation contains an internal tri-state bus or not: FPGA internal tri-state buses
I’m not a fan of long articles, but the subject of the following ones is of real interest for verification engineers. It is a transcript of a discussion between representatives of major EDA companies about EDA tools and their option of going to the cloud. Tools and the future of those tools might influence how we do verification in the future. You can read their discussion in a series of three articles from Brian Bailey-SemiEngineering: EDA in the cloud Part1, Part2, Part3.
A short introduction to the AMBA bus and the AXI protocol can be read on the AnySilicon website.
Every experienced verification engineer has been at least once through the scenario described by Mark Glasser in his last article: Debugging madness. The way we can deal with these kind of “brain stalls” is diverse. It might also help if we understand how the brain works and how learning process works. I strongly suggest to follow up a course about “