Tech Articles on Sigasi

Advanced Sigasi project settings for teams and agents

Fri, 24 Jul 2026 00:00:00 +0000

Sigasi recently introduced an enhanced method for configuring and managing Sigasi Visual HDL projects. This update is more than a convenience feature; it addresses a growing challenge in modern RTL development: maintaining deterministic control as codebases, teams, and now AI-generated RTL scale.

How to code resets in Verilog

Mon, 04 May 2026 00:00:00 +0000

In digital design, resets are used to bring a circuit into a predefined state after power-up. This article focuses on how to design resets for synchronous digital circuits in Verilog and SystemVerilog.

Verilog Assignments: blocking or non-blocking?

Mon, 27 Oct 2025 00:00:00 +0000

Verilog / SystemVerilog has two different assignment operators. One assignment operator is blocking, the other one non-blocking. In this article, we’ll discuss how they are different and when to use each of them. Note that we’re talking about assignments in procedures (always, initial etc.) only, and not about continuous assignments.

Sigasi Visual HDL Preview (2026.4)

Fri, 17 Oct 2025 00:00:00 +0000

For users who want early access to the features and bug fixes of upcoming Sigasi Visual HDL releases, we have set up an extra release channel called Sigasi Preview.

The Sigasi Preview release channel offers more frequent releases than the official releases. This page gives an introduction to the most important changes.

Setting up a VUnit project in VS Code

Thu, 09 Oct 2025 00:00:00 +0000

This article explains how to set up VUnit with the new Modular Project format. This method uses a scripted target to integrate VUnit’s compilation flow into Sigasi Visual HDL.

Getting started with verification in UVVM

Mon, 01 Sep 2025 00:00:00 +0000

Universal VHDL Verification Methodology (UVVM) is an open-source framework designed to streamline the creation of structured VHDL testbenches, facilitating the verification of FPGA and ASIC designs. It provides a comprehensive library of verification components and utilities to help design teams reduce the effort and complexity involved in writing testbenches. If you are familiar with UVM , UVVM is UVM’s VHDL counterpart.

Insights into FSM Design Practice

Thu, 31 Jul 2025 00:00:00 +0000

Introduction

This article starts with elaborating the necessity for rigor FSM design and its key objectives. It provides exemplary implementations of good practices. Finally, it goes over a step by step example of building an FSM with the help of Sigasi Visual HDL (SVH) on VS Code.

Signal Assignments in VHDL: with/select, when/else and case

Thu, 05 Jun 2025 00:00:00 +0000

VHDL provides several ways to assign values to a signal based on the value of another. Most of the time, there’s more than one valid approach, and each has its advantages depending on clarity, maintainability, and tool support. This guide covers three primary idioms: selected signal assignment (with/select), conditional signal assignment (when/else), and case statements inside processes.
VHDL-2008 introduced a 4th idiom: pattern matching in case statements. We’ll conclude with practical considerations for using the right construct.

Better call SAL

Wed, 07 Aug 2024 00:00:00 +0000

More than a year ago, we published a blog post discussing the effectiveness of using GitHub Copilot in combination with Sigasi (see original post). Since then, we’ve integrated our own AI tool, SAL (Sigasi AI layer), into Sigasi® Visual HDL™ (SVH™), making it a great time to revisit the topic. In this article, we used SAL in combination with various language models to evaluate its strengths and weaknesses.

Exploring GitHub Copilot

Mon, 04 Dec 2023 00:00:00 +0000

Two years ago, GitHub Copilot was released as an AI-powered coding assistant. Since then, it has been widely used by software developers. So far, it has delivered very good results with programming languages such as C++ or Python. We decided to run some experiments to see how it would perform with hardware description languages. Here is what we have found out.

ANSI and Non-ANSI Port Declarations in Verilog

Wed, 02 Aug 2023 00:00:00 +0000

In Verilog, module ports can be declared using one of two styles: ANSI or non-ANSI. This article covers the distinct syntaxes of these two styles, as well as further differences between them.

Using VUnit for Real

Wed, 26 Apr 2023 00:00:00 +0000

VUnit is an open-source unit testing framework for VHDL and SystemVerilog that helps write and execute tests. VUnit scans your projects for unit tests (aka test benches), runs them with your favorite simulator, and reports the results. This automation helps run tests (more) frequently and iterate faster.

Using VUnit in a GitLab CI Verification Environment

Wed, 14 Dec 2022 00:00:00 +0000

Introduction

Continuous Integration (CI) and Continuous Deployment (CD) are getting more and more important in today’s development processes, especially when working agile/lean by using DevOps principles. It helps to find errors earlier, makes designs more reliable, and in the end it takes pressure off the FPGA developers who too often have really long days and nights to meet deadlines.

VUnit: managing input files and compile order

Thu, 29 Sep 2022 00:00:00 +0000

Some time ago, while preparing for an earlier article on VUnit and UVM, a warning message in a VUnit run caught my attention.

 TXT
 
 
Compiling into lib: vhdl_adder_tb.sv passed
WARNING VCP2515 "Undefined module: vhdl_adder was used. Port connection rules will not be checked
 at such instantiations." ".../vhdl_adder_tb.sv" 20 6
Compiling into lib: vhdl_adder.vhd passed

The tests themselves were running nicely, but hey! VUnit compiles the testbench before the relevant design under test (DUT) and the compiler complains that the DUT is not available when compiling the testbench. Wasn’t VUnit supposed to figure out the compile order by itself?

VHDL 2019: Conditional Analysis

Tue, 02 Aug 2022 00:00:00 +0000

If you are writing universal, portable VHDL code, be it a design that targets multiple chip families, or a library that should work with multiple simulators, you may have noticed that it can be quite challenging to make things work everywhere. Different vendors provide their own macros and IPs, simulators provide their own utility libraries, tools support different VHDL attributes. Your code may be treated differently or even fail to compile if it uses language features that are not supported by one of the tools.

Running UVM tests in VUnit

Tue, 28 Jun 2022 00:00:00 +0000

VUnit and UVM are two increasingly popular standards in the field of HDL verification.

VUnit, as the name suggests, is primarily intended for unit testing. Compared to system tests, unit tests are typically small, and VUnit test are written by designers or verification engineers in the same HDL as the design. VUnit supports both VHDL and SystemVerilog for designs and testbenches.

Sigasi's Software Development Kit Part 2

Mon, 30 May 2022 00:00:00 +0000

In the previous installment of this blog, we talked about why you would want to integrate Sigasi’s SDK into your own product portfolio. To summarize our arguments:

The SDK allows you to offer an editing experience in your own product line that is similar to a full blown IDE.
Developing such capabilities from scratch would be prohibitively expensive.

So, hopefully by now you’re convinced you want to license our SDK … but now what? In this installment, we want to focus on some practical aspects of integrating our SDK. The goal is to make you aware of the (limited) additional work you might be confronted with.

7 reasons why you should try out our VS Code extension, number 4 will blow your mind 👀

Mon, 16 May 2022 00:00:00 +0000

Sigasi is always trying to innovate in the world of digital design. We have been developing and improving our Eclipse-based flagship product: Sigasi Visual HDL. This has improved the productivity of many digital designers around the world, making them focus on what’s really important: designing.

Sigasi's Software Development Kit Part 1

Mon, 25 Apr 2022 00:00:00 +0000

At Sigasi, we build tools to make you more productive. Specifically, we enhance your productivity during chip design with SystemVerilog and VHDL. This is why we create our end-user focussed Sigasi Visual HDL.

Build systems for HDL projects

Tue, 04 May 2021 00:00:00 +0000

Introduction

For a long time, software developers have enjoyed build systems to help them build their code. These build systems keep track of dependencies and call the appropriate tools to run the design flow or parts thereof. In this article, we try to give an overview of currently available build tools for VHDL and Verilog projects.

Case statements in VHDL and Verilog

Thu, 17 Dec 2020 00:00:00 +0000

In programming languages, case (or switch) statements are used as a conditional statement in which a selection is made based on different values of a particular variable or expression. A general discussion of these statements can be found here .

Actual? Formal? What do they mean?

Wed, 14 Oct 2020 00:00:00 +0000

In this article, we discuss the terms actual and formal. These terms show up in the Language Reference Manual of Verilog and VHDL, and they also show up in some of the error messages in Sigasi Visual HDL. Actuals and formals are short for actual and formal arguments of functions, procedures, entities, modules, etc.

Wildcards in sensitivity lists in VHDL and Verilog

Mon, 28 Sep 2020 00:00:00 +0000

In hardware description languages (HDL), sensitivity lists are used to indicate which events may trigger a VHDL process or Verilog always statement. These trigger events are usually transitions of signals that are inputs of the process or always statement.

How to code reset in a synchronous VHDL process

Tue, 11 Aug 2020 00:00:00 +0000

VHDL 2019: Usability and APIs

Thu, 18 Jun 2020 00:00:00 +0000

In this fourth and last article in our series about VHDL 2019, we discuss some smaller usability improvements. The new and improved APIs are also mentioned. You can read the third part here.

VHDL 2019: Enhanced generic types

Tue, 16 Jun 2020 00:00:00 +0000

This is the third article in our series about VHDL 2019. In this article the enhanced generic types are discussed. You can read the second part here.

Enhanced generic types

VHDL 2019 improves generic types and subprograms. In VHDL 2008 generic types were introduced, these generic types can be bound to any type. In addition to the generic type, a number of generic operations can be provided with the type. For example:

VHDL 2019: Interfaces

Thu, 11 Jun 2020 00:00:00 +0000

This is the second article in our series about VHDL 2019. In this article we look at the new ability to cleanly express interfaces. You can read the first part here.

What's new in VHDL 2019?

Tue, 09 Jun 2020 00:00:00 +0000

Introduction

This article is the first in a series of articles that are taken from the talk VHDL 2018: New and Noteworthy (slides ). This talk was given by our colleague Lieven Lemiengre at DVCON 2018. Since the new VHDL standard was approved and published in 2019, all references to 2018 from the talk have been replaced by 2019 in this series of articles.

Records in VHDL: Initialization and Constraining unconstrained fields

Tue, 31 Mar 2020 00:00:00 +0000

In VHDL, records help the designer organize data that belongs together. By using records, VHDL code will be easier to understand and maintain. This article highlights a couple of slightly more advanced aspects of record types in VHDL, namely how to use record constants, and how to use unconstrained data types as fields in records. We’ll see that, apart from some particular syntax, records are fairly easy to use after all.

Finite State Machine (FSM) encoding in VHDL: binary, one-hot, and others

Fri, 06 Mar 2020 00:00:00 +0000

State diagram in Sigasi Visual HDL Professional

In VHDL, Finite State Machines (FSMs) can be written in various ways. This article addresses the encoding of, and the data types used, for the state register. The encoding of the states of an FSM affects its performance in terms of speed, resource usage (registers, logic) and potentially power consumption. As we will see, enumerated datatypes are preferred for clarity and easy of maintenance.

Recovering Verilog and SystemVerilog Parser

Fri, 31 Jan 2020 00:00:00 +0000

When you’re writing HDL code, be it in SystemVerilog, Verilog or VHDL, your code is broken or incomplete most of the time. Any regular compiler stops on the first error it encounters and will often only show an obscure error message. At Sigasi, we are convinced productivity and happiness of HDL developers increase when they receive immediate feedback on broken code.

Prefix all signals in an instantiation

Fri, 11 Oct 2019 00:00:00 +0000

When you autocomplete an instantiation using the Sigasi Content Assist, wire or signal names in the port map get a default value that is equal to the port name. In many designs, this can be insufficient. You might need to give the wires/signals in the portmap a prefix so they match the actual wire/signal names in the design.

Should a default value count as a write?

Wed, 28 Aug 2019 00:00:00 +0000

An unexpected warning

Recently, one of our customers asked why Sigasi was giving a warning on his code. The warning told him a specific variable in a function was never written. The code in this function indeed only reads the variable. However, the variable was declared using a default assignment.

Register Description Language SystemRDL 2.0

Tue, 23 Apr 2019 00:00:00 +0000

Get the full Language Reference Manual, free of charge, at https://www.accellera.org/downloads/standards/systemrdl

Sigasi has created this browsable version of the grammar, hoping that it would be useful to you, but without any warranty whatsoever.

Exploring an open-source Risc-V core

Mon, 28 Jan 2019 00:00:00 +0000

This weekend I read that Western Digital published the SystemVerilog sources of their open-source Risc-V core on GitHub. Of course, I wanted to try how easy it was to import this project in Sigasi and test how well Sigasi handles this codebase.

Portable Test and Stimulus Standard Version 1.0

Wed, 27 Jun 2018 00:00:00 +0000

Get the full Language Reference Manual, free of charge, at http://www.accellera.org/downloads/standards/portable-stimulus

Sigasi has created this browsable version of the grammar, hoping that it would be useful to you, but without any warranty whatsoever.

Using the util package from Modelsim with VHDL 2008

Mon, 15 Jan 2018 00:00:00 +0000

The util package that comes with Modelsim in the mti_util.vhd file includes an enumerated type forcetype that is defined as:

 VHDL
 
type forcetype is (default, deposit, drive, freeze);

In VHDL 2008, default is a new keyword. This causes problems in VHDL 2008 projects that use the util package. Still, Sigasi Visual HDL allows to use the modelsim_lib.util package in VHDL 2008 projects.

Array size mismatches with generic port widths

Tue, 09 Jan 2018 00:00:00 +0000

Customer question

On a regular basis, we receive questions from customers about Incorrect array size warnings or errors.

Wallpapers for Fans of Sigasi Visual HDL

Thu, 30 Nov 2017 00:00:00 +0000

In case you want to do decorate your desktop with a Sigasi-themed wallpaper, here is good news for you!

We have two versions (light and dark) and three different resolutions, as well as a scalable svg:

VHDL IEEE 1076-2017 Grammar

Thu, 27 Jul 2017 00:00:00 +0000

Based on the VHDL 2017 Standard Draft

This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making this document available for use and adoption by public authorities and private users, the IEEE does not waive any rights in copyright to this document.

Property Specification Language (PSL) Grammar

Thu, 02 Feb 2017 00:00:00 +0000

IEEE Std 1850-2010

This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making this document available for use and adoption by public authorities and private users, the IEEE does not waive any rights in copyright to this document.

VHDL file encoding

Wed, 25 Jan 2017 00:00:00 +0000

Introduction

I have been using VHDL for almost two decades and never wondered how I should save my VHDL files. Because of my software engineering background, I always use UTF-8 as the default character or file encoding and never had any issues with it.

SystemVerilog IEEE 1800-2012 Grammar

Fri, 11 Nov 2016 00:00:00 +0000

Copyright The IEEE Standards publication(s) (“Document”) is approved by the IEEE Standards Association (“IEEE-SA”) Standards Board and is published in accordance with established IEEE-SA Standards Board bylaws and operations procedures.

VHDL IEEE 1076-2008 Grammar

Thu, 22 Sep 2016 00:00:00 +0000

VHDL Assert and Report

Mon, 02 Feb 2015 00:00:00 +0000

How can you check invariants in VHDL? How can you write information to the console? That is what the VHDL assert statement and report statement are for!

The basic syntax of a report statements in VHDL is:

Name shadowing in VHDL

Mon, 26 Jan 2015 00:00:00 +0000

Like many other languages, it is possible in VHDL to perform name scoping. This happens if you declare a new object in a nested scope that reuses the name of an object that was already declared. This is not an error in VHDL, but it can be confusing and it can cause errors. In general, I would advice against name scoping unless you have a very good reason. Even then, it would be best if you document (comment) your code so that everybody understands what is going on.

Use environment variables to set up External Compilers

Fri, 24 Oct 2014 00:00:00 +0000

Some teams have a setup where environment variables are automatically set by scripts, to reflect the paths of the correct version of simulators and synthesis tools. In cases like this, it is better to configure Sigasi External Compilers to use these environment variables instead of absolute paths to find the installation path of external compilers.

To "to" or to "downto"... Ranges in VHDL

Fri, 05 Sep 2014 00:00:00 +0000

Most VHDL designers write ‘something downto something’ in their code all the time. But what does this downto actually mean? And what is the difference with to?

The keywords downto and to specify the direction of ranges in VHDL. downto is descending (going down); to is ascending (going up).

How much time is spent on writing documentation versus developing RTL code?

Wed, 27 Nov 2013 00:00:00 +0000

Estimation of time for technical documentation and software development

Estimating software development schedules is a skill. The programmer who is going to do the work can figure out what steps they will need to take to implement that feature. And only the programmer can estimate how long each one will take. The nature of software development is that things which seem simple are often surprisingly complicated when we think about all the details. Attempting to estimate a feature before we’ve figured out how the feature is going to work, in detail, can’t possibly work, even if we multiply our best guess by three, because our “best guess” is based on very little in the way of facts. One of the most painful questions that developers are faced with is estimation and justification of time required for technical documentation development. Documentation developers need a methodology to provide a more or less precise and, most importantly, well-grounded estimation of documentation development time, already at the problem definition stage.

Why you need good documentation for your VHDL and Verilog code

Sun, 10 Nov 2013 00:00:00 +0000

In this blog series, guest blogger Smrita talks about the need for documentation for complex RTL designs.

In engineering, technical documentation refers to any type of documentation that describes handling, functionality and architecture of a technical product or a product under development or use. The intended recipient for product technical documentation is both the (proficient) end user as well as the administrator, service or maintenance technician. In contrast to a mere “cookbook” manual, technical documentation aims at providing enough information for a user to understand inner and outer dependencies of the product at hand. The technical documentation is intended to help the maintainers of the system (the people who need to keep the system running smoothly, fix problems, etc.) The maintainers are usually technical people, who need to know exactly how the system works .

"Use" and "Library" in VHDL

Mon, 09 Sep 2013 00:00:00 +0000

Beginning VHDL engineers, and advanced engineers too, can get confused about the exact scope of a use clause and a library clause in VHDL. They usually show up at the top of a file, which would make you think that they are visible in the entire file. Unfortunately, the truth is a bit more complex.

VHDL Physical Type is not Synthesizable, or is it? (part 2)

Mon, 15 Oct 2012 00:00:00 +0000

In a previous post, VHDL Physical Type is not Synthesizable, or is it?, I pointed out that VHDL synthesis tools can indeed synthesize VHDL physical types. In the example I gave, all computations with physical types were done at elaboration time, so that the synthesis tool does not really have to deal with physical types at all.

VHDL Physical Type is not Synthesizable, or is it?

Thu, 11 Oct 2012 00:00:00 +0000

Everybody who has been taught VHDL in college or in a company with senior colleagues has heard the following “wisdom”:

Pysical types are for simulation only. They cannot be synthesized. [commonly heard claim – debunked in this article]

Recovering VHDL Parser

Fri, 21 Sep 2012 00:00:00 +0000

It is useful to analyze code that is only partly finished, code that still has errors in it. Analyzing broken code helps people understand, improve and complete the code. In order to perform such an analysis, you need a parser that recovers after it encounters an error. In the world of hardware design, hardly any recovering parsers exist and engineers are left out in the cold. All but a few EDA tools fail miserably at parsing incorrect VHDL code.

Three mistakes, three error markers

Fri, 21 Sep 2012 00:00:00 +0000

Ideally, if you make three mistakes in VHDL, you want to see three error markers. Here is a small example.

A traditional VHDL compiler gives only one error message. You will have to fix this error and start the compiler again before you can find the next error. This takes extra time and you need all of your time you to work on complex design problems that you are dealing with.

Coding styles

Fri, 14 Sep 2012 00:00:00 +0000

There is a lot of debate about which Coding conventions are best. We know that many teams have their own coding conventions but often times they are not enforced. Let’s see why and how coding guidelines can help you.

Dead code

Wed, 05 Sep 2012 00:00:00 +0000

A hardware design project will often contain code that does nothing. Still, there might be a good reason to have this code. Here are some guidelines to determine if this dead code is useful or not:

Deprecated IEEE Libraries

Tue, 15 May 2012 00:00:00 +0000

What are deprecated IEEE libraries?

Don’t use ieee.std_logic_unsigned and similar libraries because they are not standardized. Instead, use ieee.numeric_std.all.

Clock edge detection

Mon, 09 Apr 2012 00:00:00 +0000

There are two largely accepted ways to detect clock edges, and many style books prescribe or prefer one over the other. Let’s investigate.

This article deals with edge detection in synthesizable code, not with behavioral code as found in testbenches and behavioral models.

Coding conventions

Fri, 06 Apr 2012 00:00:00 +0000

Style guides can be a religion. Like religion, style guides can help people make the right choices. But also, like religion, style guides can make people stick to unjustified dogma and block any constructive dialogue.

Advanced VHDL Configurations: Tying a component to an unrelated entity

Thu, 22 Mar 2012 00:00:00 +0000

Usually, people use VHDL configurations to select a given architecture for their component, or even to set generics that were not set in the instantiation. But you can also do more advanced stuff with configurations: you can tie a component to a completely unrelated entity. You can even re-wire the signals!

The scope of VHDL use clauses and VHDL library clauses

Wed, 14 Dec 2011 00:00:00 +0000

When I first learned VHDL, I bumped in to quite a few language quirks. Here is one thing that I learned the hard way: the scope of VHDL use clauses.

VHDL case statements can do without the "others"

Mon, 24 Oct 2011 00:00:00 +0000

I was talking to some engineering students the other day, as they were doing a VHDL lab. I noticed a VHDL case statement for state machine with named states (enumerated data type). All states were handled in their VHDL case statement, and still they put an others section in their code. I had a hard time explaining that this clause was useless. The students mumbled something about their professor eating them alive if they’d forget the others and problems with uninitialized stated and high-impedance state. As you might know, these concepts are related to the std_ulogic and std_logic type, but not to enumerated types.

Package and Package Body: in the same file or in separate files?

Fri, 22 Jul 2011 00:00:00 +0000

Some coding guidelines require that a package and its body should be in the same file. Other guidelines require two separate files, often with rules about the filenames. What is the reason for this?

List of known VHDL metacomment pragma's

Thu, 28 Apr 2011 00:00:00 +0000

Following up on a previous post, VHDL Pragmas, this is an incomplete list of supported VHDL pragmas, organized by vendor.

As an introduction, most pragmas have the following structure:

VHDL

-- trigger directive

where trigger is a keyword such as pragma or synthesis, and the directive is a special compiler directive. Many tools support several triggers, each with identical meaning.

VHDL Pragmas

Tue, 05 Apr 2011 00:00:00 +0000

In VHDL, some tools support so-called compiler directives. A compiler directive, or pragma is additional information that you give to the VHDL compiler (the simulator or synthesis tool). While your directive has no influence on the VHDL code itself, it changes the behavior. The IEEE, in their VHDL RTL standard, defines a pragma as A generic term used to deﬁne a construct with no predeﬁned language semantics that inﬂuences how a synthesis tool will synthesize VHDL code into an equivalent hardware representation.

WORK is not a VHDL Library

Wed, 09 Feb 2011 00:00:00 +0000

WORK is not the name of a VHDL library. This may surprise some (or even most) VHDL designers, even experienced engineers. Most of the time, nobody gets bothered by this. But occasionally, it can cause great confusion and waste of time.

VHDL Recursion and Useful Error Messages

Sun, 16 Jan 2011 00:00:00 +0000

If hardware designers are to be more productive, the tools need to be better. Instead of building more complex tools (think: ESL and the likes), the EDA vendors should keep an appropriate focus on basic usability. Because, as Richard Goering says, just because it doesn’t crash doesn’t mean “quality.”

On HDL language design and library design

Tue, 22 Sep 2009 00:00:00 +0000

Assertions and constrained random

Last week, I went to the closing symposium of the SoC Verification project, where I was invited to talk about the Code Review process for hardware designers.

Four (and a half) ways to write VHDL instantiations

Sun, 18 Jan 2009 00:00:00 +0000

Most hardware designers stick to their own way of typing VHDL instantiations. In this post, I list four styles that I’ve come across.

The most common way of writing an instantiation, is by declaring a component for the entity you want to instantiate. There are a few different places where you can write your component declaration.

Specman-e BNF Grammar

Fri, 19 Mar 2004 00:00:00 +0000

Up to date as of Fri Mar 19 2004.

module: statement_list
statement_list: statements
statements: statement
| statements ; statement
statement: package_statement
| struct_statement
| extend_struct_statement
| type_statement
| extend_type_statement
| routine_statement
| simulator_statement
| unit_statement
| sequence_statement
| method_type_statement
| c_export_statement
package_statement: package id
struct_statement: package_or_null struct id like_opt { struct_member_list }
like_opt: [ like id ]
extend_struct_statement: extend struct_type { struct_member_list }
type_statement: package_or_null type id : scalar_type
extend_type_statement: extend id : [ enum_item_list ]
routine_statement: package_or_null routine id ( parameter_list ) type_opt routine_name_opt
routine_name_opt: [ is c routine id ]
last_semi_opt: [ ; ]
c_export_statement: c export id c_export_opt
c_export_opt: [ . id ( ) ]
package_or_null: [ package ]
encap: [ package | private | protected ]
sequence_statement: package_or_null sequence id sequence_opt
sequence_opt: [ using seq_name_pair_list ]
seq_name_pair_list: seq_name_pair
| seq_name_pair_list , seq_name_pair
seq_name_pair: id = struct_type
method_type_statement: package_or_null method type id ( parameter_list ) opt_return opt_event
opt_return: [ : type ]
opt_event: [ @ event ]
struct_member_list: struct_members
struct_members: struct_member
| more_struct_members struct_member
struct_member: [ field_declaration | method_declaration | subtype_declaration | constraint_declaration | coverage_declaration | temporal_declaration | simulator_member | attribute | cvl_declaration ]
field_declaration: encap id field_type_specifier opt_instance
| encap field_property id field_type_specifier opt_instance
field_property: !
| %
| ! %
| % !
field_type_specifier: [ [ expr ] : list_type | : type ]
method_declaration: encap method_name ( parameter_list ) type_opt method_specifier action_block
| encap method_name ( parameter_list ) type_opt is empty
| encap method_name ( parameter_list ) type_opt is undefined
| encap method_name ( parameter_list ) type_opt is c routine id
| encap method_name ( parameter_list ) type_opt @ event method_specifier action_block
| encap method_name ( parameter_list ) type_opt @ event is empty
| encap method_name ( parameter_list ) type_opt @ event is undefined
| encap method_name ( parameter_list ) type_opt method_specifier foreign_opt dynamic c routine libname_opt
method_name: method_id
parameter_list: [ parameters ]
parameters: parameter
| parameters ,
parameter: id
| id : type
| id : * type
type_opt: [ : type ]
method_specifier: member_specifier
| is inline
| is inline only
foreign_opt: [ foreign ]
member_specifier: is
| is also
| is first
| is only
libname_opt: [ id : | id | id : id ]
subtype_declaration: encap when struct_subtype { struct_member_list }
constraint_declaration: keep constraint_spec
list_of_constraint_spec_or_null: [ list_of_constraint_spec last_semi_opt ]
list_of_constraint_spec: constraint_spec
| list_of_constraint_spec ; constraint_spec
constraint_spec: constraint_expr gen before subtypes ( field_list ) reset gen before subtypes ( )
field_list: id field_list , id
attribute: attribute id id = attribute_expr
attribute_expr: id
unit_statement: package_or_null unit id like_unit_opt { struct_member_list }
like_unit_opt: [ like id ]
opt_instance: [ is instance ]
cvl_declaration: cvl_method
| cvl_call
| cvl_callback
cvl_method: cvl method opt_async method_name ( parameter_list ) opt_event cvl_routine
cvl_call: cvl call opt_async method_name ( parameter_list ) opt_event cvl_routine
cvl_callback: cvl callback opt_async method_name ( parameter_list ) opt_event cvl_routine
opt_async: [ async ]
cvl_routine: [ is c routine target_struct ]
target_struct: id
| id . id
hdl_path: ' hdl_pathname'
simulator_statement: simulator_member
| simulator_restricted_member
simulator_member: verilog simulator id
| vhdl simulator id
| verilog task hdl_path ( vtask_parameter_list )
| verilog function hdl_path ( vfunc_parameters ) v_size_opt
| verilog variable hdl_path options_opt
| verilog code expr
| vhdl code { verilog_command_list last_semi_opt }
| vhdl procedure hdl_path options_opt
| vhdl function ' id ' options_opt
| vhdl driver hdl_path options_opt
| vhdl object hdl_path
simulator_restricted_member: verilog time verilog_timescale
| vhdl time vhdl_timescale
verilog_command_list: verilog_command
| verilog_command_list ; verilog_command
verilog_command: STRING_LITERAL
vtask_parameter_list: [ vtask_parameters ]
vtask_parameters: vtask_parameter
| vtask_parameters , vtask_parameter
vtask_parameter: id : expr vtask_parameter_options_opt
vtask_parameter_options_opt: [ : vtask_io ]
vtask_io: in
| id
| inout
vfunc_parameters: [ vfunc_parameter_list ]
vfunc_parameter_list: vfunc_parameter
| vfunc_parameter_list , vfunc_parameter
vfunc_parameter: id v_size_opt
v_size_opt: [ : expr ]
verilog_action: force hdl_path = force_rhs
| release hdl_path
force_rhs: expr
| verilog_literal
verilog_timescale: NUMERIC_LITERALid / NUMERIC_LITERALid
vhdl_timescale: NUMERIC_LITERALid
action_block: { action_list }
action_list: actions
actions: action
| actions ; action
action: e_action
e_action: [ var_action | assign_action | conditional_action | iterative_action | method_call_action | start_tcm_action | compute_action | return_action | try_action | check_action | gen_action | emit_action | time_consuming_action | print_action | verilog_action | debug_action | dut_error_action | do_seq_action | action_block ]
var_action: var id type_opt init_opt
| var id := expr
init_opt: [ = expr ]
conditional_action: break
| continue
| if_action
| case_action
if_action: if expr then_opt action_block else_part_opt
then_opt: [ then ]
else_part_opt: [ else action_block | else if_action ]
case_action: case { case_list }
| case binary_expr { case_list }
case_list: cases last_semi_opt
cases: case
| cases ; case
case: expr colon_opt action_block
| default
colon_opt: [ : ]
default: default colon_opt action_block
iterative_action: repeat do_opt action_block until expr
| while expr do_opt action_block
| for id from expr up_down binary_expr step_opt do_opt action_block
| for { action ; expr ; action } do_opt action_block
| for each iterated_type_opt itemname_opt indexname_opt in expr do_opt action_block
| for each iterated_type_opt itemname_opt indexname_opt in reverse expr do_opt action_block
| for each file itemname_opt matching expr do_opt action_block
| for each line itemname_opt in file expr do_opt action_block
up_down: to
| down to
iterated_type_opt: [ struct_type | enumerated_type ]
itemname_opt: [ ( id ) ]
indexname_opt: [ using index ( id ) ]
do_opt: [ do ]
step_opt: [ step expr ]
try_action: try action_block else_try_opt
else_try_opt: [ else action_block ]
check_action: check name_opt that_opt expr opt_block dut_error_opt
| assert expr else_error_opt
name_opt: [ < id > ]
that_opt: [ that ]
dut_error_opt: [ else dut_error ( argument_list ) opt_block ]
dut_error: dut error
| dut errorf
else_error_opt: [ else error ( exprs ) ]
method_call_action: method_invocation
| method_port_invocation
action_opt: action_block
| with_opt
expr_or_default: expr
| default
opt_config_param: [ , exprs ]
compute_action: compute expr
return_action: return expr_opt
assign_action: Ival_expr assign_operator expr
assign_operator: = +=
| -=
| *=
| /= %=
| <<=
| >>=
| &=
| ^=
| l=
| and=
| ** or=
| <=
| &&=
| ||=**
gen_action: gen reduced_gen_action_item itemname_opt keeping_opt
| gen qualified_id itemname_opt keeping_opt
keeping_opt: [ keeping { constraint_list } ]
print_action: print exprs options_opt
do_seq_action: do when_qualified_id itemname_opt keeping_opt
debug_action: message ( argument_list ) opt_block
| messagef ( argument_list ) opt_block
dut_error_action: dut error ( argument_list ) opt_block
| dut errorf ( argument_list ) opt_block
opt_block: [ action_block when qualified ]
id: id
| struct_qualifier when_qualified_id
qualified_id: path_id
| struct_qualifier qualified_id
path_id: id
| id [ expr ]
| me
| path_id . id
| path_id . id [ expr ]
| path_id . as_a ( type )
reduced_gen_action_item: . id
| . id [ expr ]
| reduced_gen_action_item . id
| reduced_gen_action_item . id [ expr ]
| reduced_gen_action_item . as_a ( type )
coverage_declaration: cover id opt_cov_field coverage_group_option
coverage_group_option: options_opt member_specifier { cover_item_list }
| is empty
| using also options opt_cover_item_list
cover_item_list: [ cover_items last_semi_opt ]
opt_cover_item_list: [ is also { cover_item_list } ]
cover_items: cover_item
| cover_items ; cover_item
cover_item: item id item_options_opt
| item id : type = expr options_opt
| transition id item_options_opt
| cross item_name_list item_options_opt
item_name_list: id
| item_name_list , id
opt_cov_field: [ ( expr ) ]
item_options_opt: [ using options | using also options ]
temporal_declaration: encap event id event_option
| on id opt_defer do_opt action_block
| encap expect_declaration
opt_defer: [ $ ]
event_option: [ is temporal_expr | is only temporal_expr ]
expect_declaration: expect id
| expect temporal_expr dut_error_opt
| expect id expect_specifier temporal_expr dut_error_opt
| assume id
| assume temporal_expr dut_error_opt
| assume id expect_specifier temporal_expr dut_error_opt
expect_specifier: is
| is only
emit_action: emit event
start_tcm_action: [ start method_invocation | start method_port_invocation ]
time_consuming_action: all of action_block
| first of action_block
| wait
| wait until_opt temporal_expr
| sync
| sync temporal_expr
| state machine expr until_state_opt { transition_list }
until_opt: [ until ]
until_state_opt: [ until id ]
transition_list: last_semi_opt
| transitions last_semi_opt
transitions: transition
| transitions ; transition
transition: id => id action_block
| * => id action_block
| id action_block
event: id
| field_access
| primitive_expr $
temporal_expr: temporal_inclusive_expression
| temporal_expr @ event
temporal_inclusive_expression: temporal_or_expression
| temporal_inclusive_expression => temporal_or_expression
temporal_or_expression: temporal_and_expression
| temporal_or_expression or temporal_and_expression
temporal_and_expression: temporal_exec_expression
| temporal_and_expression and temporal_exec_expression
temporal_exec_expression: temporal_sampling_expression
| temporal_sampling_expression exec action_block
temporal_sampling_expression: temporal_eventual_expression
| temporal_eventual_expression @
temporal_eventual_expression: temporal_repeat_expr
| eventual temporal_repeat_expr
| not temporal_eventual_expression
temporal_repeat_expr: temporal_unaryexpr
| [ range ] temporal_repeat_opt
| [ expr ] temporal_repeat_opt
| ~ [ range ] temporal_repeat_opt
temporal_primitive: cycle
| detach ( temporal_expr )
| true ( expr )
| rise ( expr )
| fall ( expr )
| change ( expr )
| delay ( expr )
| ( temporal_expr )
| { temporal_sequence last_semi_opt }
| consume ( @ event )
temporal_sequence: temporal_expr
| temporal_sequence ; temporal_expr
temporal_repeat_opt: [ * temporal_exec_expression ]
temporal_unaryexpr: temporal_primitive
| @ event
| fail temporal_unaryexpr )
type: non_port_type
| port_type
non_port_type: regular_type
| list_type
regular_type: scalar_type
| struct_subtype
scalar_type: id
| enumerated_type
| scalar_type scalar_modifier
enumerated_type: [ enum_item_list ]
scalar_modifier: [ ranges ]
| ( scalar_unit : expr )
| ( scalar_unit : * )
enum_item_list: [ enum_items ]
enum_items: enum_item
| enum_items , enum_item
enum_item: id enum_num_opt
enum_num_opt: [ = expr ]
scalar_unit: bits
| bytes
struct_type: id
| struct_subtype
struct_subtype: struct_qualifier struct_type
struct_qualifier: id
| id ' id
| FALSE' id
| TRUE' id
list_type: list of type
| list ( id : id ) of type
port_type: io_type simple of non_port_type
| io_type buffer of non_port_type
| io_type event
| serve_client call of non_port_type
| io_type method of id
io_type: [ id | in | inout ]
serve_client: id
constraint_expr: binary_expr
select: select { selection_list last_semi_opt }
selection_list: selection
| selection_list ; selection
selection: expr : expr
port_binding: bind ( expr , port_bind_target port_constraint )
port_bind_target: expr
| UNDEFINED
port_constraint: [ , { constraint_list } ]
Ival_expr: id
| field_access
| primitive_expr [ range_element ]
| hdl_path
| bit_extract
| bit_concat
| primitive_expr $
primitive_expr: lval_expr
| me
| literal
| ( binary_expr )
| new
| method_invocation
| method_port_invocation
| [ ranges ]
| cast
| select
| port_binding
new: new
| new struct_type itemname_opt with_opt
with_opt: [ with action_block ]
field_access: primitive_expr . when_field_access
| . when_field_access
| when_field_access_pair
when_field_access: id
| when_field_access_pair
when_field_access_pair: FALSE' id
| TRUE' id
| when_field_access ' id
bit_extract: primitive_expr [ expr_opt : expr_opt slice_opt ]
slice_opt: [ : scalar_type ]
bit_concat: % { bit_elements }
bit_elements: expr
| bit_elements , expr
method_port_invocation: primitive_expr $ ( argument_list )
method_invocation: primitive_expr . called_method_name ( argument_list )
| . called_method_name ( argument_list )
| id_or_special_method ( argument_list )
| hdl_path ( argument_list )
| all_values ( scalar_type )
| get all units ( struct_type )
| primitive_expr . get enclosing unit ( struct_type )
| get enclosing unit ( struct_type )
| primitive_expr . try enclosing unit ( struct_type )
| try enclosing unit ( struct_type )
| primitive_expr . seq_method ( type ) itemname_opt
| . seq_method ( type ) itemname_opt
| seq_method ( type ) itemname_opt
called_method_name: method_name
id_or_special_method: method_id
seq_method: in sequence
| in unit
argument_list: [ exprs ]
cast: primitive_expr . as_a ( type )
| . as_a ( type )
ranges: range_element
| ranges , range_element
range_element: expr
| range
range: expr_opt .. expr_opt
list_elements_or_null: [ list_elements last_semi_opt ]
list_elements: expr
| list_elements ; expr
unary_expr: primitive_expr
| now @ event
| { list_elements_or_null }
| { list_elements_or_null } [ range_element ]
| { list_elements_or_null } . id ( argument_list )
| unary_operator unary_expr
| primitive_expr unary_post_operator
| Ival_expr time_unit
| literal time_unit
| constraint_for_each_expr
| text_expansion_exp
| << STRING_LITERAL
unary_operator: not
| |
| &
| ^
| nor
| nand
| nxor
| +
| -
| ~
| !
unary_post_operator: is empty
| is not empty
binary_expr: boolean_imp_expression
| boolean_imp_expression ? expr : expr
boolean_imp_expression: logical_OR_expression
| boolean_imp_expression => logical_OR_expression
logical_OR_expression: logical_AND_expression
| logical_OR_expression boolor_operator logical_AND_expression
boolor_operator: ||
| or
logical_AND_expression: inclusive_OR_expression
| logical_AND_expression booland_operator inclusive_OR_expression
booland_operator: and
| &&
inclusive_OR_expression: exclusive_OR_expression
| inclusive_OR_expression | exclusive_OR_expression
exclusive_OR_expression: AND_expression
| exclusive_OR_expression exclusive_operator AND_expression
exclusive_operator: ^
| nxor
AND_expression: in_expression
| AND_expression & in_expression
in_expression: match_expression
| in_expression IN_operator match_expression
IN_operator: in
| in range
| not in
match_expression: relational_expression
| match_expression match_operator relational_expression
match_operator: ~
| !~
relational_expression: member_expression
| relational_expression neq_operator relational_rhs
| verilog_literal neq_operator member_expression
relational_rhs: member_expression
| verilog_literal
neq_operator: ==
| !=
| verilog_operator
verilog_operator: ===
| !==
member_expression: equality_expression
| member_expression is a struct_type
| member_expression is a struct_type ( id )
| member_expression is not a struct_type
equality_expression: soft_expression
| equality_expression eq_operator soft_expression
soft_expression: shift_expression
| soft shift_expression
eq_operator: <=
| >=:
| <
| >
shift_expression: additive_expression
| shift_expression shift_operator additive_expression
| gen ( gen_item_list ) before ( gen_item_list )
shift_operator: <<
additive_expression: multiplicative_expression
| additive_expression additive_operator multiplicative_expression
additive_operator: -
multiplicative_expression: unary_expr
| multiplicative_expression multiplicative_operator unary_expr
multiplicative_operator: *
| /
| %
| within
exprs: expr
| exprs , expr
expr: binary_expr
expr_opt: [ expr ]
opt_index: [ Index ( id ) ]
opt_prev: [ prev ( id ) ]
constraint_for_each_expr: for each itemname_opt in gen_item do_opt { constraint_list }
| for each itemname_opt using opt_index opt_prev in gen_item do_opt { constraint_list }
gen_item_list: gen_item
| gen_item_list , gen_item
| >>
| +
gen_item: primitive_expr
constraint_list: [ constraints last_semi_opt ]
constraints: constraint_expr
| constraints ; constraint_expr
verilog_literal: BASED_LITERAL
time_unit: hr
| min
| sec
| ms
| us
| ns
| ps
| ** fs**
text_expansion_exp: text begin text_list text end
text_list: ( expr )
| STRING_LITERAL
| text_list ( expr )
| text_list STRING_LITERAL
options_opt: [ using options ]
options: option
| options , option
option: id
| id = expr
| when = expr
| range_option
range_option: ranges = { cover_ranges last_semi_opt }
cover_ranges: cover_range
| cover_ranges ; cover_range
cover_range: range ( [ ranges ] optional_range_param )
| range ( id optional_range_param )
optional_range_param: [ , exprs ]
literal: STRING_LITERAL
| NUMERIC_LITERAL
| CHAR LITERAL
| TRUE
| FALSE
| NULL
| UNDEF
| MAX_INT
| MIN_INT
id: id