Sigasi Studio is distributed online. It is available in two versions: as a
stand-alone application or as a plugin inside a standard Eclipse
installation. Your license gives you the right to use either version, at
any time, at your discretion. Therefore, your first task is to decide
which version suits your requirements, based on the description below.
Depending on the chosen version, you should then follow the
corresponding installation instructions.
Sigasi Studio App
The stand-alone application has the following characteristics:
Recommended if you are not using Eclipse yet
Installation is trivial: just unzip!
Everything is included in a single download
Well-balanced set of features
Optimized for VHDL and Verilog development
Complete freedom to add and configure plugins
Sigasi Studio Eclipse Plugin
The Eclipse plugin has the following characteristics:
Recommended if you are using Eclipse already
Easily plugged into your existing Eclipse platform
Complete freedom to add and configure plugins
Over one thousand other Eclipse plugins to choose from
Support for C, C++, Tcl, and other languages
Support for many version control systems
Sigasi Studio Custom Installation
Recommended for (larger) teams
Automates the setup of Eclipse, the Sigasi Studio plugin, and your project
Ensure that team members have a uniform setup
Quickly set up Eclipse with Sigasi Studio
Configure team preferences during setup
Check out a project from version control at setup time
Optionally add support for other programming languages
To download and install Sigasi Studio as a stand-alone application, follow the
online Installation Instructions.
After downloading, choose or create a folder where you want to install
the software and unpack the archive there. The archive contains a
single top-level folder called sigasi. Inside the folder, there is an
application startup file, also called sigasi. Start the application by
executing this startup file.
If you are using RedHat Linux 6 or CentOS 6, you need to follow the Plugin installation
instructions as explained here.
Running Sigasi Studio with multiple users on the same server
The following section is only relevant if you’re using a Sigasi Studio version older than Sigasi Studio 4.17.2.
Starting with Sigasi Studio 3.8, the Sigasi launcher listens on port 4444. To avoid conflicts on this port when Sigasi Studio is used on a server with multiple users concurrently, the following changes need to be made:
Edit sigasi/configuration/config.ini and replace eclipse.application=com.sigasi.runner.open with eclipse.application=org.eclipse.ui.ide.workbench
In sigasi/sigasi.ini add following lines between @noDefault and -vmargs:
--launcher.defaultAction
openFile
If there are other arguments between @noDefault and -vmargs, append to these.
This way Sigasi Studio uses the default Eclipse behavior instead of the custom Sigasi runner.
More information on the Eclipse OpenFileFeature can be found here.
The Sigasi runner allows you to open projects using the -p option.
This is not possible when using the default Eclipse runner.
Installation of Sigasi Studio Eclipse Plugin
There are two ways to install the Sigasi Studio Eclipse Plugin:
You can check your Java version with java -version
Java can be downloaded from several sources, a.o. Adoptium.
Prerequisites: Eclipse
You need to have at least Eclipse version 2021-03 (4.19).
This Eclipse version and the Sigasi Studio plugin require Java 11 or 17.
If you don’t have Eclipse installed yet, the C/C++ flavor would be a good place to start. Just download (Windows 64 bit/Linux 64 bit/Other versions), unzip, and start.
This requires the host where you install the Sigasi Studio Plugin to have access to our download server.
After starting Eclipse:
Click Help > Install New Software…
In the Work with: field enter https://download.sigasi.com/updates/studio and press enter.
Check the checkbox next to Sigasi Studio
Since Sigasi Studio 4.15, installing Sigasi Studio optional features is no longer recommended.
Click the Next button.
The following steps are pretty self-explaining.
After the installation, you will need to restart Eclipse. Once this is done, go to Window > Perspective > Open Perspective > Other… and select the Sigasi Perspective. You can then close the Welcome View to show the Sigasi Views.
Installing the Offline Update Site
Installing the offline update site is very similar to installing from the main update site, where step 2 is replaced with these steps:
Download the offline update site
In the Install Wizard, click Add…
Click Archive…, browse to the zip file you downloaded, and confirm with OK.
Next, continue with step 3. in the general eclipse installation instructions.
It is recommended to disable the option Contact all update sites during install to find required software
when installing the offline update site.
GPG Certificate Validation
Eclipse 4.26 (2022-12) added GPG certificate checking capabilities. When you install new plugins, you will be prompted to trust any not-yet-trusted GPG keys or unsigned artifacts. Because Sigasi artifacts are correctly signed using GPG, you can expect to see the following screen the first time you install or update Sigasi in an Eclipse >= 4.26.
Previously trusted keys can be inspected by going to Window > Preferences > Install/Update > Trust.
You can refer to this page for all information regarding GPG at Sigasi.
Licensing
The license key can be filled in under Window > Preferences > Sigasi > License Key.
More details can be found here. The license unlocks the features for your edition.
Configuration
Sigasi Studio stores its projects on the file system in one or more
workspaces.
When you start the tool for the first time, it will propose to create a
workspace for you:
Although you can work with multiple workspaces, we recommend using a
single workspace for all your projects.
Software Updates
Sigasi Studio has an automated update system. When updates are available, you
are notified by a pop-up window called Updates Available in the
bottom right corner:
If you want to install the updates, click anywhere in the pop-up window.
After a few seconds, a new window will appear with further instructions.
The updates can be postponed by closing the pop-up. You can perform the
updates at any time by clicking the
-icon in the status bar
at the bottom of the screen.
It is good practice to first create a backup of your installation folder before running an update. This can be done by simply compressing the eclipse or the sigasi folder in an archive (zip file)
Update Sigasi Studio App
If you run Sigasi Studio as a standalone application, the automated update system will periodically check for software updates.
Update Sigasi Studio Eclipse plugin
If you run Sigasi Studio as an Eclipse plugin, you may need to check for updates manually, by clicking Help > Check for Updates.
You can enable automatic updates by opening this preference page: Install/Update > Automatic Updates. Next, enable Automatically find new updates and notify me. Feel free to modify any of the available options.
Firewalls and Proxies
If the updates are not automatically fetched from the Sigasi Studio update server you are probably behind a firewall or proxy server. You can configure Sigasi Studio’s proxy settings in Window > Preferences > General > Network connections.
Make sure to set the Active Provider to Manual and configure the appropriate Proxy entries.
Whether you need to configure the entries for HTTP or HTTPS depends on the Locations configured in the Available Software Sites settings.
If you can not add a firewall exception for our update site, the fallback solution is to download the complete application from our website.
You can completely replace your old installation; all settings are stored in your workspace (the default is workspaceSigasi in your home directory).
Your work with Sigasi Studio typically is organized as a project. A project
is a collection of VHDL and/or (System)Verilog files that belong together. Sigasi Studio
understands the HDL units defined in the files, and the relationships
between them.
Your first step is to set up a project. There are a number of ways to do
this. The most common ways are:
Note that while you initially need to choose between a VHDL and a (System)Verilog project, any Sigasi Studio project can be a mixed language project.
If you wish to create a mixed language project, we recommend to import or create a VHDL project and then add the (System)Verilog support to this project.
To create a mixed language project, right click your project and select Configure > Add VHDL support or Configure > Add (System)Verilog support as needed.
Features
In projects you can navigate from instantiation statements to the matching entity or module.
This also works in mixed language projects.
You can navigate from VHDL entity instantiations in (System)Verilog code and (System)Verilog module instantiations in VHDL code.
You can also open the declaration of ports and generics/parameters in mixed instantiations.
Other supported features:
Find references for entity names, modules, ports, generics and parameters.
Autocomplete (System)Verilog module instantiations in VHDL code and VHDL entity instantiations in (System)Verilog code.
Error reporting of incorrect entity names, modules, ports, generics and parameters in instantiations.
You can import an existing VHDL or (System)Verilog project from the file system by clicking
File > Import… > Sigasi > Import a VHDL project or Import a (System)Verilog project. Browse to the
root directory of the project, and press Finish.
2: Set Libraries (VHDL or Mixed)
Since Sigasi Studio 4.4, Sigasi Studio automatically configures libraries of imported projects, based on project information
such as library and use clauses. If you need to customize the library configuration, you can assign different
libraries to your files and folders. Right-click on a file or folder and select Library Mapping > New Library….
Then fill out the correct library name.
If you need additional files that are not in the project root directory,
just drag them from your Windows Explorer (or other file browser) into
the project. You will have the option to create a link rather than
copying the files.
Note 1: dragging files works on Windows (using Windows Explorer), on
Mac OS X (using Finder) and on Linux (using Gnome Nautilus). If you use
KDE, you should install Nautilus.
Note 2: to avoid absolute paths in the .project file, environment variables can be used.
Right-click the file or directory in the project explorer and select
Properties > Resource > Location > Edit… to configure the path of the resource.
To access environment variables, you have to prefix the environment variable with ENV-.
For example: to refer to the home directory you can use ENV-HOME.
Creating a new, empty project
To create a new project, select File > New > VHDL Project or
File > New > (System)Verilog Project. Then give your project a name.
By default, the Use default location checkbox is checked, which
means that new projects will be located in the workspace folder.
Alternatively, you can uncheck the checkbox and choose an arbitrary
location for your project. This is especially useful if you want to use
Sigasi Studio with an existing design.
You can also select the VHDL version or the version of .v files.
After creating a new project, you can add existing files by dragging
them from your filesystem into the project explorer. New files can be
added by clicking File > New > VHDL file, File > New > Verilog file
or File > New > SystemVerilog file.
Other ways to set up a project
Adding VHDL or Verilog support to an existing Eclipse project
You can also add VHDL or Verilog support to any project in your
workspace by right-clicking the project in the project explorer and
selecting Configure > Add VHDL support or Configure > Add
(System)Verilog support. You can also remove VHDL or Verilog support from
Sigasi Studio projects by selecting Configure > Remove VHDL support or
Configure > Remove (System)Verilog support.
Sigasi Studio projects can be shared using file archives. All project-related
settings are stored in two hidden files in the project folder.
Therefore, you can create an archive of the entire top level folder
(File > Export > General > Archive file) and send it to someone
else.
You can import a project from an archive by clicking File > Import…
> General > Existing projects into Workspace and selecting Select
archive file. Browse to your project archive and press Finish.
Programatically creating a project
The Sigasi Studio .project and .library_mapping.xml files can be created using code from our
publicly available Sigasi Project Creator project.
The project offers Python classes that make it easy to generate a Sigasi Project from your own project
specifications.
For more information and examples, check out the Sigasi Project Creator project on GitHub.
HDL libraries are a very powerful feature of the HDL languages. Sigasi Studio
makes it easy to configure and use them. In this chapter, we assume that
the basic concepts of HDL libraries are understood. We will explain how
they are implemented in Sigasi Studio.
Like with any HDL tool, Sigasi Studio needs to know where the libraries are
located on the file system. We will describe how the library
configuration can be examined and modified using the GUI.
We will also present some use case about how to set up libraries with
Sigasi Studio to organize your projects.
Examining the library configuration
You can examine the library configuration in the Libraries View
and in the Project Explorer view. The Libraries view shows how
design units are mapped. The Project Explorer view show how VHDL or
SystemVerilog files are mapped.
In the Libraries view you can see a tree of all libraries in your
projects. You can open each library to see all contained design units.
In the Project Explorer view each physical file or folder is annotated
with the library it belongs to, between square brackets:
What you see here is the initial library mapping of a demo project (you
can create such a project by selecting File > New > Other > Tutorial
VHDL Project or Tutorial SystemVerilog Project).
In the screenshot we see a project called Demo, with a folder named
Common Libraries. In that folder, you see the typical standard
libraries (std and ieee) upon which all VHDL projects depend. The
demo project itself consists of a few VHDL files.
Next to the project’s name Demo, is the annotation work. This means
that, barring any overrides, everything in the project will be stored
inside the work library.
Lower down, we see overrides. For example, the STD folder has an
annotation std. This means that, again barring any further overrides,
the entire contents of the STD folder will be mapped into the library
std. There are no limits to the number of overrides that can be
performed. If this needed, any individual file can be mapped to a
separate library.
Modifying the library configuration
The library mapping for project files can be modified in the Libraries
and Project Explorer view.
Select a file or a folder in the Project Explorer and right-click.
You get a Set Library context menu, with a number of options:
Select Exclude from build to exclude the file or folder from any library
Select New Library… to define a new library and map the file or folder to it
If one ore more folders are selected, the folder can be added to a library with the folder name(s)
Select the name of an existing library to map the file or folder to that library
When you map a file into a library, only that file is affected. However,
when you map a folder into a library, then everything in that folder
will be mapped into that library. Any overrides in the folder and its
sub-folders will be removed. When you are defining the library mapping
for a new project you should map from top to bottom.
So in the case of our Demo project, you would change (if work is not
a good default) the top folder’s mapping first and then override the
mapping in the sub-folders.
When you are changing the library mapping of a project, the project will
be rebuilt completely. In order to avoid several consecutive rebuilds
while you are setting up your libraries, you can temporarily disable the
automatic rebuilds, until you are finished setting up your library
mappings. You can do this by disabling the Project > Build
Automatically option.
To exclude a file from all libraries, the library mapping context menu
provides an Exclude from build option. You can apply that to any file or folder in
the project. Sigasi Studio will then assume that the corresponding resource is
not a part of the project and will not include that resource in a
project build. This is typically useful when you have stale copies of
HDL files or folders lying around that you want simply to be ignored.
(System)Verilog include files
(System)Verilog include files are always excluded from the build. Any
file that is included in another design file gets excluded from the
build, even if it has an extension that would normally identify it as
a design file, e.g. .v or .sv. It often doesn’t make sense to
compile include files by themselves. Instead, include files are
compiled in the context of the file in which they are included.
Configuration file
All library configuration information is stored in the .library_mapping.xml
file in the root of your project.
If you edit this file, your project will be cleared and rebuilt automatically
(a so-called Clean Build).
Sigasi Studio only writes changes to this configuration file when you make
changes to the library configuration with the context menu in the
Project Explorer.
When you do make changes, Sigasi Studio first checks that all paths in the
library configuration still exist. If a path no longer exists, is will be
removed from the configuration file.
Note that the library configuration file is case-sensitive, even on Windows.
Library configuration warnings and Quick Fix
If the library mapping file contains invalid entries, there will be a warning on the .library_mapping.xml file.
This warning will show in the Project Explorer, in the editor and in the Problems View.
An associated Quick Fix is available through the Problems View.
When invoked, it will remove all invalid entries from the .library_mapping.xml file.
Common Libraries
Each VHDL project has a folder called Common Libraries.
This is where reusable libraries go: either vendor libraries, third party IP
libraries or your own reusable libraries. By default, the STD and IEEE
libraries are added to this folder.
The Common Libraries folder behaves like any other folder.
You can delete it, rename it and apply a different library mapping.
In most cases, however, the default configuration is just what you need.
If your project doesn’t have a Common Libraries folder, you can just create
it by right-clicking the project in the Project Explorer and selecting
the New > Folder dialog.
How to add files to Common Libraries?
In any newly created VHDL project, the Common Libraries folder
contains the VHDL files of the IEEE and STD libraries.
To add files to the Common Libraries folder, locate a folder with VHDL files
on your file system using the Project Explorer or the file explorer of your OS
and drag the folder with VHDL files to the Common Libraries folder.
Alternatively, you can right-click the Common Libraries folder and select the
New > Folder dialog where you can use the Advanced » settings to create
a Linked Folder pointing to the actual folder location that contains the
files you wish to add to the Common Libraries.
How is Common Libraries different from another folder?
Common Libraries by default is a virtual folder. This means that it is not
a real folder in the project directory and it can only contain references to
folders on your file system.
Files in Common Libraries are supposed to be error free. Sigasi Studio
will not mark errors or warnings in these files.
Next to these, a few other libraries’ errors and warnings are never marked, regardless of their location.
These libraries are: std, ieee, altera_mf, altera, XilinxCoreLib, unisim, mentor, lpm, simprim, std_developerskit, unimacro, and modelsim_lib.
While you work on your project, you don’t want to edit the files in the
Common Libraries, but you need them to compile your project.
If you activate an external compiler,
files in Common Libraries are supposed to be pre-compiled. If you tell
Sigasi Studio to compile your project using an external compiler, the
Common Libraries are skipped. You need to pre-compile them yourself and let
your compiler know where the compiled libraries are. For ModelSim, you can
use the “modelsim.ini” file for this. If your project root contains a “modelsim.ini”
file, it will be used instead of the default “modelsim.ini” file.
Pre-compile Common Libraries
This section links to various recommendations on to pre-compiling the simulation models of external libraries in the Common Libraries, depending on the external compiler.
You don’t need to pre-compile VUnit libraries for running
VUnit tests. The VUnit framework compiles its own library when needed.
If you’re using libraries like OSVVM, you need to call
add_osvvm() in run.py to tell VUnit to also compile the OSVVM
library.
Further documentation on using VUnit in Sigasi Studio is available
here.
External compiler in a VUnit project
If you want to configure an external compiler in a VUnit project
(e.g. for additional syntax checking), you need to ensure that the
compiler has the VUnit library. Otherwise, the compiler will flag all
VUnit constructs in your HDL code as errors.
This script
demonstrates how to compile and enable the VUnit library for Modelsim
and Questa. Run this script in the folder where you want to install
the compiled VUnit library. This should be outside your project
folder. The script takes the path of your VUnit installation as a
parameter. Once the compilation is finished, go to your project
folder and run these commands:
vmap -c # only if your project folder doesn't contain modelsim.ini alreadyvmap <folder_where_the_script_ran>/vunit_lib vunit_lib
Note that the OSVVM library is shipped with Modelsim, so you won’t
need to compile it yourself.
For other external compilers, a similar approach is needed. Customers
who need help with that are welcome to contact
support.
What if I broke my Common Libraries folder?
If you have modified the Common Libraries folder, you can always
revert it back to the original state.
Right-click on the Common Libraries folder of your project in the explorer
view and apply menu-entry Set Library > Reset Common Libraries.
Resetting the library mapping
Sigasi Studio contains two functions to reset all or part of the library mapping.
Reset Common Libraries updates the common VHDL libraries to the
version (‘93, ‘2002, ‘2008, ‘2019) required by your
project. User-defined common libraries remain untouched. To
access this function, right-click the Common Libraries folder
inside your project in the Project Explorer and select Set
Library > Reset Common Libraries.
Reset Library Mapping resets the entire library mapping of your
project. After resetting the library mapping, Common Libraries
are reset as above, and all design files are mapped to library
work. Note that this action cannot be undone, so only use it
when you want to rebuild the library mapping from scratch. To
access this function, right-click your project in the Project
Explorer and select Set Library > Reset Library Mapping.
Sigasi Studio allows you to share libraries between multiple projects. The
easiest way to do this, is to develop each library in a separate project
and configure the Project Dependencies accordingly. To configure the
project dependencies, right click the project (the one that uses the
shared library) and select Properties. Next click Project
References and mark the library project as referenced project.
Using third party libraries
Many projects use third party libraries. These can be added to the
project as any other set of VHDL files.
A number of popular third party libraries are the following:
Vendor
Library
Install dir example
AMD/Xilinx
unisim
C:\Xilinx\Vivado\2020.1\data\vhdl\src\unisims
AMD/Xilinx
unimacro
C:\Xilinx\Vivado\2020.1\data\vhdl\src\unimacro
AMD/Xilinx
XilinxCoreLib
C:\Xilinx\14.4\ISE_DS\ISE\vhdl\src\XilinxCoreLib
AMD/Xilinx
xpm
C:\Xilinx\Vivado\2020.1\data\ip\xpm
Intel
altera_mf
C:\Intel\17.0\quartus\libraries\vhdl
Mentor
modelsim_lib
${ModelSimPath}\vhdl_src\modelsim_lib
Aldec
aldec
C:\Aldec\Riviera-PRO-2015.02\vlib\aldec\
On Linux the default installation location for AMD/Xilinx software is /opt/Xilinx.
XilinxCoreLib is a very big library with more than a thousand entities and
architectures. If you include all of these design units, it slows down the
compilation phase of Sigasi Studio. In order to avoid that, Sigasi Studio
only adds the packages with the component declarations to your project by
default. It excludes the entities and architectures from compilation.
You can easily add selected entities (and architectures) to your project by
right clicking the corresponding file (filename = entity name.vhd) in the
Project Explorer, and selecting
Set Library > xilinxcorelib.
Library errors from external compilers
If you are using the External Compilers, the external compiler
can also put error markers on library clauses. You can easily verify this by
checking the prefix of the error message (e.g. vcom: for vcom errors).
Consult the Libraries section of the external compiler
integration for more information on configuring libraries for your external
compiler.
Sigasi Studio is built upon the Eclipse platform, which permits to use multiple languages within a single environment. The user interface can be customized for a particular language. In Eclipse terminology, this customized user interface is called a perspective. The icon and name of the current perspective is highlighted in the upper right corner.
Sigasi Studio provides a Sigasi perspective to work with both VHDL and Verilog files.
If you use the standalone version of Sigasi Studio, this perspective is the default. If you use the Eclipse plugin, another perspective may be open instead. You can select the Sigasi perspective by clicking the button next the perspective icon. A window pops up in which you can select the perspective.
You can right-click the perspective button to customize toolbar contents, to reset the perspective to its default layout or to save your own, customized perspective.
Quick Access
The Sigasi Studio toolbar contains a widget called Quick Access. This widget allows you to quickly find open editors, available perspectives, views, preferences, wizards, commands, etc. Simply start typing the name of the item you wish to invoke.
When you open a project in Sigasi Studio, a number of views are presented
in the user interface. Here is a typical screenshot, with the views
highlighted.
The views provide alternative ways to access the information in a
project. They permit efficient navigation, inspection, and editing.
This chapter lists and explains the most important views of Sigasi Studio. Some views are not covered here, more specifically some views that are either inherited from Eclipse, or views that are provided by third-party plugins. Please refer to the Eclipse documentation or the specific plugin documentation for further information on those views.
Via Window > Show View. If the view is not in the visible list, choose Other… and select the view in the selection dialog.
By right-clicking in the editor and selecting Show in > ….
Some views also support opening the current selection (e.g. the Block Diagram View). This selects the element in the view that corresponds to the current selection in the editor.
Project Explorer View
This view shows the directory structure of all files in all projects.
You can use it to navigate to a particular file in your project and
select it. When you double-click on a file, the file opens in the Editor
view. If you right-click a file, you see the context menu which offers
extra commands.
You can customize the behavior of the Project Explorer View in ways
that can be particularly handy for large projects. For example, if you
click the Link with Editor icon
, the Project Explorer
will be linked to the Editor view. Now, the active file in the editor
view will always be selected in the Project Explorer.
You can apply filters to choose which files are shown. Select the icon
View Menu and then
Customize view. You can then select a filter whose matching files
will be hidden in the view. For example, you can filter out all non-VHDL
or non-Verilog files.
The Project Explorer View provides textual and graphical Label Decorations which can be controlled
in Window > Preferences > General > Appearance > Label Decorations.
Label decorators are a visual guide on the state of projects, folders, and files.
Decorators can depend on various plugins.
The following descriptions apply to Sigasi-specific decorators.
Sigasi Studio adds text decorators to the right to indicate which library a project, file, or folder is mapped in. The library name is denoted in square brackets.
If a project is in a different folder than the workspace, this is denoted within round brackets.
Other text decorators to the right of a project are probably from the Git plugin. The repository name and branch are denoted with square brackets.
Open HDL projects have a bridge-like overlay in the top right corner of the project icon.
File icons with a ‘V’ in them are VHDL or SystemVerilog source files.
Folder icons with an overlay in the lower right corner are virtual folders (white square) or linked folders (square with arrow).
Other overlays in the lower right corner are probably from the Git plugin. They indicate tracked files/folders (yellow cylinder) and non-tracked files/folders (question mark). Changed files are noted with a > mark next to the icon.
Overlays in the lower left corner are generally indicating status from Sigasi Studio: errors in files/folders are indicated with a red square and white cross while files/folders with warnings are marked with a yellow triangle with black exclamation mark .
If you exclude a file from build in Sigasi studio, the icon will be overlayed with a red forbidden entry icon in the upper left corner.
Editor View
The Editor View shows the content of files and allows you to edit
files. It is a tabbed view so that multiple files can be opened for
editing simultaneously. The currently selected file is the active file.
The Outline View displays the contents of the active file, in terms of
the HDL objects that it contains.
You can sort the elements in the outline alphabetically, by enabling the
sort button .
You can also filter all concurrent signal assignments from the outline
by enabling the Hide Signal Assignments button
.
Double-click in the Outline View to navigate to the corresponding
location in the editor.
If you enable the Link with Editor icon
and you click an
element in the Outline View, the corresponding code will be selected in
the editor.
Quick Outline View
You can also press Ctrl+O to open the quick outline.
This is just the outline view in a popup, but it also allows you to filter the shown elements.
This way, the quick outline can be used as a semanticCtrl+F, making it very easy to find a declaration in your open editor.
Pressing Ctrl+O again, when the quick outline is open, will also show the inherited members between the members of the current file.
Hierarchy View
The Hierarchy View shows the design hierarchy starting at a selected top level object. To choose a top level, open a file and right-click on an architecture (or entity or configuration or module). Then click Set as Top Level. Alternatively, you can click the Set Top button in the Hierarchy View to open a hierarchy top level selection dialog. You can use the filter field to quickly search for a certain top level.
The Hierarchy View automatically refreshes itself when you save your design files. If you have a really large design this could slow you down. You can turn the automatic refresh on and off by toggling the refresh button .
To highlight the current selection of the HDL editor in the Hierarchy View, enable the Link with Editor button . If the editor selection is part of the evaluated hierarchy tree, the corresponding hierarchy tree node will be selected.
The Hierarchy View also shows the generic and constants values of VHDL components in the hierarchy.
The internal compiler computes the generics and constants, even if they are passed down through the hierarchy, and even if arithmetic operations are used to define new values. If the value cannot be computed for some reason, the
Hierarchy View will report the value to be unknown.
When you double-click an object in the hierarchy, the Editor view is updated accordingly, possibly by displaying the contents of a different file.
Use the instantiations filter to hide everything except instantiations and structural statements.
You can launch a simulation with the button if you first set up a Launch simulator.
The Hierarchy View also offers an action Select required files, which selects all design files that are part of the current hierarchy, in the project explorer. This allows you to easily perform the same action on all files in the hierarchy. E.g. team commands, …
You can also export a CSV file with all dependencies of the selected element via the context menu: right-click and select Export Dependencies to CSV file.
Problems View
The Problems View shows problems (errors and warnings) related to your
code. These problems were reported either by the internal compiler or by
an external compiler tool.
You can navigate to the source of the problem by double-clicking on a
given problem. Problems can be sorted by clicking the column headers.
The content of this view can be customized via the View Menu . Possible customizations are
scope (workspace, project, selection), type, maximum number of
problems, …
Libraries View
The Libraries View shows the library mapping of the design units in all
projects. You can use it to navigate to a particular design unit in your
project. When you double-click on a file, the file opens in the Editor
view. If you right-click a file, you see the context menu which offers
extra commands for setting libraries and for setting the top level.
If you enable the Link with Editor button
, the Library View will
be linked to the Editor View. Now, the active file in the Editor View will
always be selected in the Library View.
Tasks View
It is common practice to add TODO and FIXME comments in your
code. Sigasi Studio automatically scans your comments for TODO and FIXME tags
and clearly highlights these comments with Task Tags. You can get a
nice overview of all task markers in your workspace in the Task View
(Window > Show View > Tasks).
You can configure extra tags in the Task Tag preference page:
Preferences > Sigasi > VHDL > Task Tags
Bookmarks View
You can easily add bookmarks by right-clicking the line number where you want to add a bookmark.
You can get an overview of all bookmarks in the Bookmarks View
(Window > Show View > Others…).
The Bookmarks View can be used to delete bookmarks or navigate to the editor and other views.
The Block Diagram View displays a graphical (block diagram) view
of all architectures, modules, and their instantiations in your current VHDL or SystemVerilog editor.
VHDL processes are also shown in the block diagram.
This viewer automatically updates while you are editing your code and
gives a convenient way to visually inspect and navigate your code, even
when your code is still unfinished or broken.
You can open the Block Diagram View by right-clicking in the editor and
selecting Show In > Block Diagram. Alternatively, you can open the
view via Window > Show View > Other… > Sigasi > Block Diagram.
You can also double-click blocks, ports, or wires to navigate
to the corresponding HDL code. If you want to go into a block, you
have to select it, right-click and click Open Entity Declaration, Open Architecture, or Open Module.
To find an object in the Block Diagram, you can navigate from your code to the Block Diagram.
In your code, right-click a signal, port, process, or instantiation and select Show In > Block Diagram - just like when opening the Block Diagram View the first time.
If the Block Diagram already is open, the corresponding element is highlighted and the Block Diagram View is centered on it.
You can export the Block Diagram View to an image with the save
button. Both SVG and PNG are supported. Choose a *.svg filename for SVG export or a *.png filename for PNG export.
You can also export allblock diagrams of an entire project at once: Click Project > Export… > Sigasi > Block Diagrams export and select your project. All SVGs will be created in diagrams/blockdiagrams/ in your project.
The State Machine View displays a graphical (bubble diagram) view of all state machines in your current VHDL or SystemVerilog editor. This viewer automatically updates while you are editing your code and gives a convenient way to visually inspect and navigate your code, even when your code is still unfinished or broken.
You can open the State Machine View by right-clicking in the editor and selecting Show In > State Machines. Alternatively, you can open the view via Window > Show View > Other… > Sigasi > State Machines.
If you have documented your state transitions (i.e. the assignments), the comments will be added as text to the transitions in the view.
You can also double-click nodes or transitions to navigate to the corresponding HDL code.
With the button, you can toggle the display of comments on edge labels.
With the button, you can toggle the display of comments on edge labels. These labels show the code comments of the transition statements.
You also have to option to Zoom In, Zoom Out, or Zoom to Fit.
You can export state machines to an image with the save button. Both SVG and PNG are supported. Choose a *.svg filename for SVG export or a *.png filename for PNG export.
You can also export allstate machines of an entire project at once: Click Project > Export… > Sigasi > State Machine Diagrams export and select your project. All SVGs will be created in diagrams/statemachines/ in your project.
The Dependencies View visualizes the dependencies of your VHDL, SystemVerilog, or mixed language projects.
This view shows the relationships between your source files and makes it easy to see top levels and important packages.
The Dependencies View also makes it easy to detect orphaned files.
The view is automatically updated each time you save your files.
The Dependencies View has the following options:
show dependencies of the entire project. Uncheck to focus on the dependencies of the active editor only.
Group design files per library
Show design units inside design files. The design units are prefixed with an abbreviation of their kind (architecture, module, package, …" >}}
The Dependencies View can help you navigate too. Double-click a file name in the diagram to open the corresponding editor.
The Dependencies View can also be pinned. This prevents the diagram from changing when you switch editors.
You can export this diagram for documentation by clicking the save icon.
Documentation View
The Documentation View gives you a live preview of the automatic documentation Sigasi Studio can generate for your project.
With Net Search, you can find loads and drivers of a net.
A net is defined as a signal or port and all other signals and ports
that are directly connected to it. The loads are where you read the
value of the net and the drivers are where you write to this net.
To find the entire net of a signal or port, place your cursor on the
identifier and right-click. Now select Find Net. Alternatively, you
can press CTRL+SHIFT+H.
The Net Search View will appear. For big designs, it might take a
while before the results appear.
From the Net Search View, you can navigate to the VHDL code by
double-clicking the search results.
In the Preprocessor View, you can preview the expanded text of Verilog macros. This view automatically synchronizes with the active editor.
When you select text in the (System)Verilog editor, the expanded text will be highlighted in the Preprocessor View. This also works the other way: when you select text in the Preprocessor View, the corresponding, original source will be selected in the editor.
The Class Hierarchy View displays more information about the hierarchy of a class. It consists of a hierarchy tree
and a list of the class members. To open the Class Hierarchy of a class, click the class name, right-click and select Open Class in Hierarchy (or press F4).
Class Hierarchy Tree
The class hierarchy tree displays either the superclasses, subclasses, or both.
Command
Description
Class Hierarchy
Displays all superclasses and subclasses.
Superclass Hierarchy
Displays all superclasses and implemented interface classes.
Subclass Hierarchy
Displays all subclasses that extend or implement the selected (interface) class.
Show Qualified Class Names
Shows the qualified name next to each class.
Member List
The member list shows all members of the class that is currently selected in the class hierarchy tree.
Command
Description
Show Inherited Members
Shows or hides all members inherited from superclasses.
Sort By Defining Class
Sorts members by the class in which they are defined.
Hide Fields
Hides all fields in the members list.
Console View
When Sigasi Studio launches external tools (e.g. external compiler, documentation generation,…) the output is logged to the Console View.
This is a generic Eclipse view.
Different tools can open different consoles. You can switch between different consoles by clicking the -icon.
Minimap View
The Minimap View can be opened via Window > Show View > Other… and selecting General > Minimap.
This is a generic Eclipse view.
This view is another way to help navigation through large files.
It shows an overview of the entire active editor in a dedicated pane.
The part that is visible in the editor is highlighted.
The highlighted part of the Minimap View can be clicked and dragged to scroll through the Editor View.
The Editor shows the content of files and allows you to edit
files. It is a tabbed view such that multiple files can be opened simultaneously.
The currently selected file is the active file.
VHDL and SystemVerilog Editor
The VHDL and SystemVerilog (or Verilog) editors are optimized to help
you browse and edit VHDL and SystemVerilog code.
Most browsing and editing features are similar for both languages.
Sigasi Studio colors your code to make the structure more
clear. Unlike other tools, Sigasi Studio offers coloring based on the
meaning of a word, rather than just the syntax.
Sigasi Studio supports both syntax highlighting and semantic
highlighting. Syntax highlighting colors pieces of code according to
the lexical class the code belongs to, such as a keyword or string.
Semantic highlighting colors code according to its meaning.
For example, a constant is shown in another color than a signal.
Code highlighting is fully configurable for a number of
VHDL and Verilog and
SystemVerilog syntax and semantic elements.
Also, Color, background, style, and font can be
customized. Learn more about configuring
colors.
Rather than configuring every color yourself, you might want to have a
look at the supported Light and Dark themes. To switch between
themes, go to Window > Preferences > General > Appearance where
you can choose a theme. While it is possible to install additional
themes, only the Light and Dark themes are supported by Sigasi.
Type-time Syntax error reporting
Sigasi Studio marks VHDL and SystemVerilog syntax errors while you type. It will also report broken SystemVerilog preprocessor code.
Project exploration and navigation
Sigasi Studio offers powerful techniques to explore a file or project and navigate through it. This section covers: hovering, Occurrence Highlighting, Open Declaration, and Find References.
Occurrence Highlighting
If you click on an identifier, it is highlighted. In addition, all other occurrences of the identifier that refer to the same object are highlighted. Note that this occurrence highlighting is intelligent: it is not based on the identifier’s string value, but on the object that the identifier refers to.
You can turn occurrence highlighting on or off. Click the “Toggle Mark Occurrences” icon in the toolbar.
Find References
To look for occurrences of a given identifier in different files, place your cursor on the identifier and right-click. Now select Search References.
A search window will appear on the bottom of your workbench, displaying all occurrences of the selected identifier. You can easily navigate through all occurrences by clicking the Show Next Match arrow
and the Show Previous Match arrow in the search result view. Note that all occurrences are highlighted and marked with a small arrow at the left border of the editor for easy recognition.
Open Declaration and Hyperlinks
Open Declaration You can easily navigate to the declaration of any
port, signal, entity, etc. Place the cursor on the identifier,
right-click, and select Open Declaration. The editor immediately
switches to the line that declares the object. Since this operation is
so commonly used, it is assigned to the shortcut key F3.
Hyperlinks You can also navigate your code like a web browser by
clicking hyperlinks. If you press and hold the Ctrl key, hyperlinks will appear in your editor. If you click the link (while holding the Ctrl key), you will navigate to the target of the link.
Sigasi Studio offers the following links:
Link to Declaration: this has the same behavior as Open Declaration (F3)
Link to Matching Entity [VHDL]: this links a component declaration of an instantiation to the matching entity declaration. This also works for component generics and ports (Shift+F3)
Link to Matching Module [MIXED]: this links a component declaration of an instantiation to the matching Verilog module declaration. This also works for component generics and ports (Shift+F3). Modules that are instantiated as entity instantiations are also supported (label : entity work.verilogmodule port map (...);)
Link to Matching Architecture for entity declarations [VHDL]
Link to Matching When Clause [VHDL]: in finite state machines (FSMs) you can jump directly to the matching when part of your case statement from state transitions (Shift+F3)
Link to Open Declaration in Package Body [VHDL]: in packages you can jump directly to the matching declaration in the package body (Shift+F3). This also works in the opposite direction, Open Declaration in Package Body
Link to Open Declaration in Protected Type Body [VHDL]: in protected types you can jump directly to the matching declaration in the protected type body. This also works in the opposite direction, Open Declaration in Protected Type
Link to Include files in SystemVerilog sources (F3)
Link to Macro definition in SystemVerilog sources
URLs in comments
Hover
To learn more about the declaration of a given identifier, hold your mouse pointer over it.
After a short time, a popup shows you the name and datatype of the signal. This technique is called hovering.
The hover pop-up can show different kinds of information:
datatype
comments: inline documentation written at the declaration (association rules)
value: the value of constants
errors or warnings: a message, if the given identifier has an error or warning associated with it
binary/decimal conversion: for hexadecimal, octal, or binary values, the decimal equivalent
Since Sigasi Studio 4.1 the hovers also offer extra links that make it easy to navigate to the declaration, find references …
Auto-complete and Content Assist
Sigasi Studio provides powerful autocompletion capabilities. This means
that the tool can help you to complete identifiers and constructs as you are working on the code. Like other tools, the tool provides
autocompletion based on the HDL language. However, it goes much
further. It also provides autocompletion based on the design context. It can provide this additional level of intelligence as it knows all
objects that have been declared in the design.
Autocompletion interface
Autocompletion may come from different sources, as will be discussed in the following sections. However, the user interface to initiate them is always the same. At any point as you are entering code, you can press Ctrl+Space and the tool will suggest appropriate autocompletion.
Based on the design context
Sigasi Studio uses its knowledge of the design to provide intelligent
autocompletion that boosts your productivity tremendously.
The tool knows which objects are appropriate and which identifiers are
visible at any given point in the code. As you start typing and ask for
autocompletion, it will suggest the appropriate identifiers as
autocompletion candidates.
Sigasi Studio provides help to autocomplete:
component declarations
component instantiations
entity instantiations
module instantiations
case statements (based on variables/signals with an enumeration type)
SystemVerilog include paths ( `include "): triggering autocomplete between the double quotes will present a list of files and folders. If you select a folder, trigger autocomplete again to get completions in this folder.
Based on templates
Sigasi Studio can help you to declare VHDL and SystemVerilog objects, using autocompletion based on templates.
Sigasi Studio comes preconfigured with templates for all common declarations and statements, including (for VHDL):
function, procedure
process
type: enum, file, range, array, record
signal, constant, variable
component
entity
architecture
entity/architecture pair
package/package body pair
and much more
Some autocompletions are templates that require further user input.
In such a case, the editor goes into a special template editing mode after the autocompletion has been performed.
You can use TAB to cycle through the items that have to be modified or completed.
When done, you can press ENTER to return to the normal editing mode.
The cursor will be placed at an appropriate position to continue working.
You can also configure your own templates.
To edit or create templates, go to Window > Preferences > Sigasi > VHDL or Verilog/SystemVerilog > Templates.
Here you get an overview of existing templates.
You can create New… templates, Edit… existing templates, or remove templates.
In the template editor, you can type ${ and press Ctrl+Space to see a list of the available variables.
Templates can be exported and imported. This is useful for sharing templates with colleagues.
Automated consistent code formatting makes code more readable and helps developers understand code, whether working on their own code or when cooperating with colleagues.
You can set preferences for Tabs or spaces under Window > Preferences > General > Editors > Text Editors.
Here you can set the tab width in spaces and configure to Insert Spaces for Tabs.
Whenever a tab is pressed, the corresponding number of spaces will be inserted instead.
You can also opt to Remove multiple spaces on backspace/delete so that removing leading spaces follows the indentation levels.
Format code on save
You can configure Sigasi Studio to automatically format your (System)Verilog and VHDL files when you save your source files via Window > Preferences > Sigasi > [VHDL | Verilog/SystemVerilog], next check Enable code format on save.
You can format (System)Verilog and VHDL files without opening them in the editor.
You can format an entire project. Right-click the project in the Project Explorer and select Source > Format.
Note that only files that are part of the build will be formatted.
You can format a selection of files. Select multiple files and/or folders in the Project Explorer and select Source > Format.
Any selected file, part of the build or not, will be formatted.
Any combination of resources can be formatted this way: multiple projects at a time, a project and a folder …
Other editor features
Code folding
If you work with large files, you might want to hide certain pieces of your code. This can be done with code folding. Certain constructs, such as if-statements or process-statements can be folded so that they use a single line in the editor view. You can do this by clicking the little "-" symbol next to the statement.
You can also enable/disable code folding and perform other actions by right-clicking in the gutter (the small column to the left of your code) and selecting Folding.
Smart Caret positioning
Smart caret positioning allows you to easily jump between words within identifiers, no matter whether you use camelCase or snake_case, by using Ctrl+Left arrow and Ctrl+Right arrow.
Sigasi Studio 4.15 added the option to disable smart caret positioning in identifiers, both in VHDL and (System)Verilog.
To change the setting, go to Window > Preferences > Verilog/SystemVerilog or Window > Preferences > VHDL where you can alter the selection of Smart caret positioning in identifiers.
Rename refactoring
Right-click on any identifier (VHDL or SystemVerilog) and select Refactor > Rename element (Alt+Shift+R) to change the name of the declaration and all its references.
If you press Alt+Shift+R twice, you can preview the rename before applying it.
Full-screen view
Double-click on the editor tab to make it full-screen. You can also use Ctrl+M to achieve the same.
Block selection
Note: In other tools, this feature may be known as column editing
or column select.
Block selection is an alternative to standard (paragraph) selection.
Block selection mode differs from standard selection mode in that it
allows to select rectangular regions, or to set the cursor over multiple
lines. Block selection is ideal for selecting vertical regions, for
example, a column of a table or all port names in a port map.
To toggle between normal and block selection modes use Alt+Shift+A
or press the Toggle Block Selection icon in the toolbar.
Structured selection
Structured Select enables you to select VHDL or SystemVerilog code, based on its syntactic structure.
Shift+Alt+Up, expands the selection to the smallest syntax element that contains the current selection. You can then further expand the selection by invoking the action again.
Shift+Alt+Down, contracts the current selection to the nested syntax expression that still contains the current cursor position. You can then further contract the selection by invoking the action again.
Shift+Alt+Left, adds the syntax element left of the current selection to the selection. You can then further expand the selection by invoking the action again. You can also expand the selection in the other direction with Shift+Alt+Right
Add parentheses or create a string
When you select a region and press ( or [, the selected region is enclosed with the matching closing parentheses, ) or ].
When you select some text and press ", the selected text will be transformed into a string.
This works for both regular and multi-line strings.
This behavior can be disabled by unchecking Enclose selected region when typing parentheses or quotes in Window > Preferences > Sigasi > VHDL.
Show whitespace
You can turn show or hide whitespace markers by clicking the Show Whitespace Characters icon in the toolbar.
Move and Duplicate lines
You can easily move lines up and down by pressing: Alt+Up and
Alt+Down.
You can duplicate your current line, or the lines of the current
selection by pressing: Ctrl+Alt+Down.
The action to remove trailing whitespace is hidden by default. You can access it by pressing Ctrl+3, typing RTW, and then selecting the correct action. Alternatively, you can bind this action to Keyboard Shortcuts of your preference.
This action is being executed on the saved file, not in the editor. So before using this action, you have to make sure your file is saved.
Customize color preferences
There are several ways to customize color preferences in Sigasi Studio.
Choose the Eclipse Theme in the Window > Preferences > General > Appearance preferences menu.
Edit Eclipse Colors and Fonts setting in the Colors and Fonts sub-menu.
Change color setting for different text editor features in Window > Preferences > General > Editors > Text Editors
Annotation colors can be configured in the Annotations sub-menu.
Highlighting colors for differences can be configured in the Quick Diff sub-menu.
Syntax coloring for Verilog/SystemVerilog can be changed in the Window > Preferences > Sigasi > Verilog/SystemVerilog > Syntax Coloring preferences menu.
Syntax coloring for VHDL can be changed in the Window > Preferences > Sigasi > VHDL > Syntax Coloring preferences menu.
Multiple Screen Support
You can right-click the title tab of any view and select Detach to move the view into a separate window that can be dragged to another screen.
Alternatively, you can drag a view out of the current window to create a new window from it.
Once multiple windows are available, views can be dragged between screens.
The Editor View can be split or duplicated in
independent viewports that access the same file buffer.
There are 3 ways to split the Editor View.
Horizontal Split shows 2 viewports on top of each other.
Vertical Split shows 2 viewports next to each other.
Clone to a new Editor View.
This new Editor View can be detached so that
the same file buffer can be viewed on multiple displays.
To split the editor view, go to Window > Editor and select the desired action.
There are Keyboard Shortcuts
to toggle the Horizontal Split (Ctrl+_) and the Vertical Split (Ctrl+{).
There can only be a single horizontal or vertical split within an Editor View.
Multiple Editor Views can be cloned and re-arranged to obtain a custom layout with many views on the same file buffer.
Side-by-side Diff
Previous versions (local history or version control)
Comparing two files
Opening project files
The default way to open files in the VHDL and SystemVerilog editor is to double-click the files in the Project Explorer. But there are more methods to open files in your projects.
Open Resource
When you press Ctrl+Shift+R the Open Resource dialog opens. In this dialog, you can type a name or pattern to open a specific file name.
Open Design Unit
When you press Ctrl+Shift+D the Open Design Unit dialog opens. In this dialog, you can type a name or pattern to open a specific VHDL or SystemVerilog design unit name.
In addition to the powerful features of an Eclipse editor, the VHDL
editor that comes with Sigasi Studio supports a number of advanced editing
features which are specifically useful for VHDL editing. These are
described in this chapter.
Code highlighting
Highlighting Classes for VHDL:
Syntax : Comment, Keyword, Number, String, Task tag
Note: In other tools, this feature may be known as paste as
instantiation or port translation.
Sigasi Studio knows all entities in the design and their interfaces, and
can therefore automate much of the instantiation process. At the point
in the code where you normally enter the entity name, you can use
autocompletion instead to suggest a list of possible entities. Upon
selection, the tool will complete the instantiation with a generic map
and a port map with named associations. As an initial suggestion, each
actual parameter will have the same name as its formal parameter. Of
course, the actual parameter names need to be reviewed and edited by the
user. Therefore, the editor will go into template editing mode after the
autocompletion.
Instantiating a component is similar to instantiating an entity. Note
that components will only be shown if they are visible in the current
scope.
Declaring a component
Note: In other tools, this feature may be known as paste as
component or port translation.
If you want to use instantiation based on a component (as opposed to
direct instantiation) you need to associate an entity with a component.
Sigasi Studio can automatically declare a component for an existing entity. At
the point where you normally enter the component name, you can use
autocompletion instead to show the list of available entities. Upon
selection, the tool will automatically complete the component
declaration.
Type Conversion
In VHDL design you need to do a lot of type conversions. Sigasi Studio’s
autocomplete functionality can help you with those. Put a dot (.)
after the element you want to convert, and the autocomplete suggestions
will appear. The conversion functions have descriptions like “convert
type” and “convert to …”.
Stuttering
Stuttering is an editing technique popularized by Emacs, that lets you
type certain things really fast. Stuttering means that you tap a certain
key twice and it expands to something more complex. For example, press
the period key . twice, and the editor will expand it to a right
arrow =>. Stuttering works like double-clicking: if you type keys
slowly, the stuttering mechanism will not be triggered.
The following stuttering keys are available:
Keys
Effect
,,
<=
..
=>
;;
:=
Stuttering can be disabled or enabled through the Enable stuttering option in the Window > Preferences > Sigasi > VHDL menu.
Smart Indentation
When you press enter, Sigasi Studio automatically adjusts the indentation of
the current and the new line. Depending on the content of the preceding
line, Sigasi Studio will automatically increase or decrease the indentation
level. E.g. an extra indent after an if-statement and removal of an
indent for the matching else-clause.
You can enable/disable this feature via Window > Preferences >
Sigasi > VHDL by toggling the “Enter adjusts indentation on current
and next line” setting.
Tabs vs. spaces: This features inserts tabs characters or spaces,
according to your preferences.
Press Ctrl+Shift+F to format your current VHDL file.
This includes:
indentation
vertical alignment of certain symbols like “<=”
wrapping lines that are too long
Context-based
Sigasi Studio’s formatter is context-based and tries to respect the author’s style. So depending on the original source style, the formatter might make different choices.
One example is the decision to format a conditional signal assignment on one, or multiple lines. Sigasi Studio makes this decision based on the position of the first else keyword. If you put the else keyword on the first line, the formatter will put everything on one line. If you put the else keyword on a new line, the formatter will use multiple lines for the assignment.
demo<=(others=>'0')whenenable='1'else(others=>'1')wheninput='1'-- else on new lineelse(others=>'X');
Note about broken code: If your VHDL source file contains syntactical errors, the formatter can not always figure out appropriate formatting. For this reason, the formatter is programmed to stop applying (whitespace) changes when unsupported syntax errors are encountered.
VHDL-specific code formatting can be configured at Window > Preferences > Sigasi > VHDL > Formatting.
Configurable settings currently include:
Preserve newlines: this option configures the formatter to not add or remove newlines in your code.
Vertical alignment: this option configures the formatter to vertically align consecutive declarations and statements.
Lowercase/Uppercase keywords: when this option is set to UPPERCASE the formatter will convert all VHDL keywords to uppercase.
When this option is set to lowercase, the keywords will be converted to lowercase.
When this option is set to ignore, the case of keywords won’t be changed by the formatter.
(Without a Sigasi Studio XL
license, keywords are not changed by the formatter).
Alignment column for trailing comments: this setting configures the column Sigasi Studio uses to align trailing comments (default is column 40)
Correct indentation only
Sigasi Studio can also correct the indentation of your code without making any other changes. Inside a VHDL editor, open the context menu and click Source > Correct Indentation, or hit Ctrl+I. This only changes whitespace at the start of your lines.
If you select code first, only the code in the selection will be indented.
Disable formatting in defined regions
You can disable the formatter for defined regions in your VHDL source files by enclosing them with off and on tags:
off tag: -- @formatter:off
on tag: -- @formatter:on
VHDL 2019 tool directives
Sigasi Studio 4.16 introduced VHDL 2019 tool
directives, which are a simplified version of the preprocessor found in
SystemVerilog or the C family of languages.
Tool directives allow to conditionally enable code based on tool type,
debug mode, or really any other custom variable.
You can edit the defined tool directives by right-clicking your project and then going to Properties > VHDL Conditional Variables.
In addition to the powerful features of an Eclipse editor, the Verilog and SystemVerilog
editor that comes with Sigasi Studio supports a number of advanced editing
features which are specifically useful for SystemVerilog editing. These are
described in this chapter.
Code highlighting
Highlighting Classes for Verilog and SystemVerilog:
Include paths and initial preprocessor definitions
The fastest way to add an include path is to run the Quick Fix on `include errors in the editor.
You can configure the include paths of your SystemVerilog projects in the Verilog Preprocessor property page.
Right-click your project and select Properties > Verilog Preprocessor.
Here you can Add and Remove include paths using the buttons on the right.
You can also move the order of the include paths using the Up and Down buttons.
The Import... and Export... buttons can be used to transfer a semicolon-separated (;) list of include paths from and to the clipboard.
In the Initial preprocessor definitions field, you can configure definitions that are set before other files in the project are processed.
This allows you to, for example, set global defines without an explicit include statement.
When you hover over a SystemVerilog preprocessor directive (e.g. include ...), Sigasi Studio shows the preprocessed text.
You can find a convenient link to open the Preprocessor View at the bottom of this hover.
Ctrl+Click on `defines (or F3) will lead you to the corresponding declaration.
Autocomplete will also offer you a list of all visible `defines.
In the Preprocessor View, you can preview the expanded version of your preprocessed SystemVerilog source files.
Verilog version
You can configure the Verilog version via Window > Preferences > Sigasi > Verilog/SystemVerilog
and select whether *.v files are treated as Verilog or SystemVerilog. *.sv files are always treated as SystemVerilog.
Smart Indentation
When you press enter, Sigasi Studio automatically adjusts the indentation of
the current and the new line. Depending on the content of the preceding
line, Sigasi Studio will automatically increase or decrease the indentation
level. E.g. an extra indent after a module and the removal of an indent for
the matching endmodule.
You can enable/disable this feature via Window > Preferences >
Sigasi > Verilog/SystemVerilog by toggling the “Enter adjusts indentation on
current and next line” setting.
Tabs vs. spaces: This features inserts tabs characters or spaces,
according to your preferences.
Press Ctrl+Shift+F to format your current Verilog or SystemVerilog file.
The default formatter implementation corrects indentation only.
Since Sigasi Studio 4.15, Sigasi ships with Verible built-in. Verible is an ambitious SystemVerilog formatter that is agnostic to macro invocations and includes and therefore produces a consistent formatting result even in heavily preprocessed code.
You can enable the Verible formatter for your installation by going to Window > Preferences > Sigasi > Verilog/SystemVerilog > Formatting.
Under Select formatter, you can choose between the default Sigasi formatter which corrects indentation, and using the Verible formatter.
Sigasi ships with a recent Verible version by default.
If you’d rather run your own Verible installation, this can be achieved in Window > Preferences > Sigasi > Verilog/SystemVerilog > Formatting > Verible.
To select your own Verible binary instead of the one that comes with Sigasi, select the Use external Verible formatter instead of bundled one: option and configure the Verible installation path: option.
This page also allows you to customize the Verible formatting rules, both for the built-in and the external Verible binaries, by pressing the Edit… button.
For maximal compatibility, you need to make sure the Eclipse setting to Insert spaces for tabs is enabled and that the Displayed tab width is matching the Verible configuration.
In the Verible configuration page, configurations are grouped in the following tabs.
Indents and Wrapping
Ports and Parameters
Types
Statements and Expressions
If you want to undo your changes, you can use the Restore Defaults button, either per tab or for the entire dialog.
After applying your configuration changes, press the OK button.
To see this in action, you can have a look at our screencast.
The Verible website and README contain more information.
You can call Sigasi Studio from the command line to open files. Just run
sigasi yourFile.vhd. You can also drag and drop files on the Sigasi Studio
icon to open them.
You can specify a linenumber by appending +yourLineNumber to the
command line. For example: sigasi test.vhd +10 will open test.vhd at
line 10.
You can also specify the project location with the -p <project path> parameter.
If the specified project was not open in the workspace yet, this will import
and open the project in the workspace.
Note that the VHDL file you specify on the command line has to be in an
open Sigasi project to enjoy all of Sigasi Studio’s powerful editing and
navigation features. If the file you open from the command line is not
in a Sigasi Studio project, Sigasi Studio opens the file as an external
file. This is nevertheless really handy for quick
edits.
This feature enables you to configure Sigasi Studio as default editor for other
EDA tools.
Note You could get a firewall warning when you start Sigasi Studio because
Sigasi Studio opens and listens to a port (4444 by default). This is necessary
for the communication between the running Sigasi Studio instance and the
command line executable. Configure your firewall to allow Sigasi Studio access
for opening this port. Update Since Sigasi Studio 4.17.2, the listener no longer listens to port 4444.
A random free port will be used, one per user on multi-user systems.
Eclipse Plugin
Eclipse plugin users can also use this feature but need to specify a few
more command line options. You have to type
eclipse -application com.sigasi.runner.open instead of sigasi. For
example: eclipse -application com.sigasi.runner.open test.vhd +10 will
open test.vhd at line 10.
Other command line options
You can add some extra parameters to Sigasi Studio to modify the behavior.
-help : show simple command line usage information
-data <location> : specifies the workspace location
-noSplash : do not show the splash screen at startup
-consoleLog : log all debug information in the console (in addition to the regular log file)
-refresh : force refresh of workspace
-showLocation : show workspace location in title bar
-application org.eclipse.ui.ide.workbench : use the default Eclipse workbench launcher instead of the Sigasi Studio workbench launcher.
This avoids conflicts on port 4444 when running Sigasi Studio with multiple users on the same server.
Refer to the setup page for more information.
--launcher.openFile <somepath> : open the Import Projects dialog to import a new or existing project into the workspace
-Dcom.sigasi.hdt.disableAutomaticTutorial : suppress the creation of the tutorial projects in empty workspaces.
-Dswt.chromium.path=/home/user/blub : extract the Chromium binaries in blub
External Files
You can edit VHDL files without setting up a project.
When a file that doesn’t belong to a project is opened in Sigasi Studio, this
file is called an external file and it will be opened in single file mode.
Single file mode is a limited environment in which not all Sigasi Studio
features are available. Navigation only works within a file. For that reason
missing declaration are not flagged as errors.
When I double-click a VHDL file, I want it to open with my favorite VHDL editor. Sigasi Studio, obviously.
Here is how to set this up in MacOS:
Find a VHDL file in the Finder
Right-click and select Get Info
Select Open with > Other… and find your Sigasi Studio application
Click Change All… so that all other VHDL files will also get opened with Sigasi Studio.
Repeat this procedure for *.vhd files and for *.vhdl files.
Intel Quartus
In Intel Quartus, open the preferences page in Tools > Options >
General > Preferred Text Editor.
As command-line options, you should have %f +%l -p %p. Optionally you
could add -noSplash to skip the splash dialog.
AMD/Xilinx Vivado
You can configure Sigasi Studio to be the preferred editor for AMD/Xilinx Vivado.
In AMD/Xilinx Vivado, click Tools > Settings…
Open the Tool Settings > Text Editor tab
Locate the Current Editor drop down menu and instead of ‘Vivado Text Editor (default)’ select ‘Custom Editor…’
If needed click the … button and in the pop-up dialog enter:
<path to Sigasi Studio>/sigasi.exe [file name] +[line number]
Click OK to close the dialog and OK to close the Settings window.
Extra steps on Linux
If your log file contains warnings about LD_LIBRARY_PATH being set to an incompatible value or if you get an error telling the JVM terminated, you can correct this by making sure LD_LIBRARY_PATH and (optionally) LD_PRELOAD are empty when launching Sigasi Studio.
Do this by e.g. creating a script to launch Sigasi Studio and call that script from within the Vivado Text Editor settings.
Extra steps for the Sigasi Studio plugin on Windows
If you use the Sigasi Studio Eclipse plugin on Windows, you might need to take some extra steps
before you can open files from Vivado in Sigasi Studio.
Make sure to close Eclipse before making the changes below.
In your Eclipse installation
In eclipse.ini remove these 2 lines
--launcher.defaultAction
openFile
In configuration/config.ini
replace osgi.instance.area.default=... with osgi.instance.area=@nodefault - note the removal of the .default suffix
replace eclipse.application=.... with eclipse.application=com.sigasi.runner.open
In Vivado configure the custom editor with the following setting
C:\....\eclipse.exe [file name] +[line number]
The first time you might need to pick a workspace and enable the use this as default and do not ask again option.
AMD/Xilinx ISE
To configure Sigasi Studio as default VHDL editor in AMD/Xilinx ISE:
In AMD/Xilinx ISE, Click Edit > Preferences and ISE General > Editors
Select Custom instead of ISE Text Editor
If Sigasi Studio is on your path enter sigasi.exe $1 +$2 (Windows) or sigasi $1 +$2 (Linux).
If Sigasi Studio is not on your path, use the absolute path instead. If there are spaces in this
path, you need to enclose the path in curly braces . For example:c:\\My\ Applications\sigasi\sigasi.exe $1 +$2.
If you now open any VHDL file in AMD/Xilinx ISE, Sigasi Studio will automatically open the selected file.
You can find more info on configuring AMD/Xilinx ISE to work with external editors in the AMD/Xilinx documentation.
HDL Designer
To configure Sigasi Studio as external editor in HDL Designer:
In HDL Designer, click Options > Main
Click the Text tab
Press the Setup… button in the Editor section to open the Editor Command Setup dialog.
Fill the Name, Command and Arguments sections as shown.
Click the Add button to add Sigasi Studio to the list of available editors.
Press OK to close the dialog.
Press the Setup button in the HDL Viewer section and repeat this procedure from step 4.
You now can select the Sigasi entry in the list box for the Editor and HDL Viewer sections.
From now on you can double click on a file or a line in a file - for example by selecting an architecture or an entity - and Sigasi Studio will open the file at the correct location.
In addition to syntax validation, Sigasi Studio also checks your code for
semantic problems (Linting, or Linter checks). Some of these
problems can be automatically resolved with Quick Fixes. Both syntax
checking and linting happen at type-time: new markers appear as you are
typing your code.
Linting
VHDL code Lint is defined as code that is strictly correct according
to the language definition, but still suspicious or problematic.
Sigasi Studio has a built-in linter, which provides info about code lint
in the design.
In addition to code linting, Sigasi Studio can also check that file
headers and symbol names (entities, signals, variables…) follow
certain patterns. This is discussed under naming conventions.
Marker Icons
marks an info message that can be resolved automatically with a Quick Fix.
marks an info message.
marks a warning that can be resolved automatically with a Quick Fix.
marks a warning that cannot be resolved automatically.
marks an error that can be resolved automatically with a Quick Fix.
marks an error that cannot be resolved automatically.
Configuring the Severity Level
The Sigasi Studio VHDL linter has reasonable defaults for the severity level of
reported lint problems. However, the severity level of certain classes
of linting rules is configurable for additional flexibility. The configuration
interface to configure severities for the entire workspace is available through:
Specific warnings can be suppressed in your code by adding a @suppress comment (-- @suppress for VHDL, // @suppress for SystemVerilog), on the same line as the warning.
You can limit the suppression to a specific warning by putting a prefix of the warning message between quotes after @suppress. Sigasi also recommends adding a reason why the warning was suppressed by adding an extra comment after @suppress:
<line with warning> // @suppress "Warning message prefix" Reason why warning is suppressed
Since Sigasi Studio 4.2 the @suppress comment also suppresses Errors.
Since Sigasi Studio 4.3 warnings have a quickfix to automatically add the @suppress comment with a matching warning message prefix.
No Linting for Common Libraries
Common Libraries are considered to be production ready libraries.
Linting is skipped for all files in the Common Libraries folder.
Naming conventions
Sigasi Studio can check whether all sorts of names in the design -
entities, instances, modules, signals, variables… - follow
particular patterns. This may help designers to follow their
company’s or team’s coding rules. For example, coding rules may
prescribe that signal names must have a s_ prefix, that generics
names must be written in capitals, or that variable names must use
CamelCase. Empty rules (which is the default) means that the
particular rule is not checked.
In addition, Sigasi Studio can also check for file header comments,
e.g. whether a copyright notice or disclaimer have been included.
At the top, you can set the severity of naming convention and file
header comment non-conformities. Below, you can enter the validation
patterns. Patterns use the Java regular expressions
syntax. Information on Java regular expressions is available through
the link above the severity settings. Note that names are not
validated if the corresponding validation pattern is empty.
You can also configure naming conventions per project, or even per
file or folder. Documentation on how to do that is
here.
Quick Fixes
Some of the VHDL lint problems can be automatically resolved with Quick Fixes.
These problems have markers annotated with a lightbulb icon (like ).
To trigger a Quick Fix, click the problem marker or press Ctrl+1 and select the Quick Fix.
Language specific code rules
The currently available linting rules are described in detail on the following pages.
Sigasi Studio offers 2 ways of configuring the severity of linting checks.
For the entire workspace, through the Window > Preferences dialog as described above.
You can override these setting by creating a settings file for your projects.
In each project, you can override the coding rules settings. You can override rules for the entire project, for folders in the project, or for individual files.
Errors/Warnings property page
To configure the severity level, right click the project (or file or folder) in the Project Explorer and select Properties > VHDL Errors/Warnings or Properties > SystemVerilog Errors/Warnings.
On the top of the dialog, select Enable project specific settings to activate the severity level on a project base.
Enabling this setting will override any settings specified at the workspace level.
For each of the available ID’s, you can choose from a drop-down list or you can set all severities at once using the drop-down list on top.
Note that choosing the default setting does not inherit from the workspace settings.
It will apply the Sigasi built-in default for a linting rule.
Project settings are stored in this settings file:
If you only want to change the severity of naming convention and/or
file header checks for an entire project, you can change them through
the dialog in Sigasi Studio: Project > Properties > Verilog Errors/Warnings (look for ID 92 and 188) Project > Properties > VHDL Errors/Warnings (look for ID 2 and 22)
Other project specific naming convention and/or file header check
settings can be configured in the configuration files.
The project-specific Naming Conventions and Header Comment are stored in this settings file for VHDL related settings:
Naming Conventions can be restricted to a specific file or folder using ${path}.
Possible values are:
<project> (literally, with brackets!) to set Naming Conventions for the entire project
the folder name to which the Naming Convention should apply
the full path of the file to which the Naming Convention should apply
The pattern that defines the Naming Convention is set in ${convention}.
Patterns are configured with regex syntax.
Naming Conventions for a project and setting the severity of the linting checks
are configured in the same settings file.
Syntax for Header Comment
Lines that configure the Header Comment should start with 188 and are of this format:
188/params/comment_header/${path}=${convention}
The meaning of ${path} and ${convention} is equal to the definitions for Naming Conventions.
Examples:
92/severity/<project>=INFO
92/params/constant_name/<project>=c_.*
92/params/entity_name/my_folder=e_([A-Z_0-9])*
188/severity/<project>=WARNING
188/params/comment_header//<project>=-- Project specific header comment\r?\n-- Second line
188/params/comment_header//my_folder=-- Folder specific header comment
Note that to use \R in the configuration file the \ needs to be escaped.
So you’ll need to put \\R in the configuration file.
Errors in the patterns will be reported in the log file: Help > Open Log.
The table below lists the Verilog and SystemVerilog code rules that can be checked automatically by Sigasi Studio.
The availability of code rules depends on the license requirements.
The table below lists the VHDL code rules that can be checked automatically by Sigasi Studio.
The availability of code rules depends on the license requirements.
Sigasi Studio supports a number of ways to work with external tools such as
simulators. Different techniques offer varying degrees of flexibility
and automation.
Most people will want to set up their external compilers
so that Sigasi Studio can use them to compile and start simulations.
Another way to compile your project is to export your project to a CSV (comma separated values) list
of all the files in your project, in the correct compilation order.
Learn more about how to export your project’s file list.
The third, and more advanced way of working with compilers or simulators
is to use the standard Eclipse mechanisms of builders and external
tools.
By creating a builder,
you can arrange for an external tool to be run automatically when a
Sigasi Studio project is rebuilt. By default, this happens each time you save a
file. External Tools Configuration
allow you to call any program or script from within the Sigasi Studio GUI. You
have to write and maintain the scripts yourself, but you have complete
flexibility as to what is in the scripts.
External Compilers
If you have a simulator or lint tool installed, you can use this for two
purposes:
Save-time Compilation: Compile and
check your files each time you save. Any errors or warnings will
show up in the file, on the line number of the problrem
Launch Simulator: Start the
simulator in its own window, ready to run a simulation.
If an external compiler is enabled, you can also start a simulation from
Sigasi Studio. You can start a simulation by first selecting your top level
in the Hierarchy View. Next click the
Simulate button in the hierarchy
view to launch the simulator gui with an elaborated design ready for
simulation. Sigasi Studio opens a new console for each simulation launch. You
can terminate a simulation by clicking the Stop icon
.
When you launch a simulation, Sigasi Studio opens a new console in the Console View
You can switch between different consoles by clicking the -icon.
Configure external compiler
You can configure the external compiler settings by clicking Window >
Preferences > Sigasi > Toolchains. There is a sub-page for each
supported toolchain. Before you can enable a toolchain on the main page,
you must specify its installation path. Clicking Restore Defaults on
a Toolchain page will automatically fill in the installation path if
your toolchain is installed on a default location. After you press
Apply, you can select your toolchain on the Sigasi > Toolchains
page.
For some toolchains you can specify extra command line arguments. Note
that these preference pages support Eclipse
Variables
which allow you to more easily share settings in a team.
Environment variables are supported too.
If you want to use the $HOME environment variable, you can call this variable by typing ${env_var:HOME}.
List of toolchains
By “toolchains”, we mean any tool or set of tools that processes VHDL or
Verilog code, and that is supported by Sigasi Studio. At this time, external
compiler include simulators and lint tools, but in the future it could
also include synthesis tools.
For each toolchain Sigasi Studio can support any combination of the following:
Sigasi Studio can use an external VHDL or Verilog compiler for additional code validation. At this time, Sigasi Studio supports:
vcom / vlog / vsim style compilers. These compilers include Aldec Riviera-PRO and from Mentor Graphics ModelSim and QuestaSim.
isim compiler from AMD/Xilinx.
ncsim compiler from Cadence Incisive.
Catching bugs earlier is cheaper than catching them late. Traditionally,
the first errors are found when the hardware designer decides to run a
simulation. At this time, the simulator’s compiler tool will detect
errors and fail. At Sigasi we think that this is too late. Problems
should be detected as soon as possible.
Sigasi Studio adds two extra layers of error detection to catch problems
earlier. First, there is the type-time error detector. As soon as
the designer writes an error, it is marked in the text much like a spell
checker in a word processor. Second, as soon as you save a file,
Sigasi Studio calls the external compiler for further analysis. All errors that
the external compiler finds are marked inside your file, so that you can
find and fix them easily. Sigasi Studio intelligently controls the external
compiler incrementally and only recompiles design files that need
recompilation.
All output from external compilers is logged in Sigasi Studio’s console view
for your convenience. Paths to your design files are automatically
converted to hyperlinks to ease naviation.
The table below lists some examples of VHDL errors that are detected in
Sigasi Studio at type time, at save time and with the external compiler
integration.
Check
Type time
Save time
Save time compile
Syntax errors
yes
yes
yes
Undeclared signals
yes
yes
yes
Multiple files
no
yes
yes
Data type mismatch
no
no
yes
Multiple drivers
no
no
yes
Libraries
Libraries are fully supported. But note that Sigasi Studio does not send Common
Libraries to the external compiler for compilation. These libraries are
expected to be pre-compiled. Contact support@sigasi.com if you want to
add more libraries to this list.
If your project root contains a modelsim.ini file, Sigasi Studio will add this
file to the vcom command with -modelsimini. This allows you to
configure custom settings for Mentor’s vcom.
External Tools Configuration
Select Run > External tools > External Tools Configurations to get
started, or use the icon.
To create a new configuration, first select
Program, then click
.
Enter all necessary information to start your external tool:
Name: The name for this configuration.
Location: The location of the executable. You can browse for programs and scripts in your workspace or programs on your file system.
Working Directory: The working directory for your program.
Arguments: The arguments, if any, to your program.
You can test your tool configuration with the Run button.
The following example screenshot shows how to set up configuration to
run a simulate.sh script from within Sigasi Studio.
The following example screenshot shows how to set up a configuration to
run make clean on a Linux machine.
To run the external tool just select the configuration from the dropdown
menu on the -icon. You can rerun the
last configuration by simply clicking
.
Variables in Arguments
In the arguments field you can use variables, which are automatically expanded when the external tool is run.
This allows you to do things like adding the currently selected file in the file explorer as an argument for an external tool configuration (${resource_path}).
Sigasi Studio adds following variables and parameters for VHDL and (System)Verilog projects:
Variable Name
Description
${library:<argument>}
Get the library name of <argument>. For example, to the get the library of the currently selected resource use ${library:${resource_path}}
${sigasi_toplevel}
Get the name of the current top level: library.name
${sigasi_toplevel:short}
Get the name of the current top level without library: name
${sigasi_toplevel:project_path}
Get the path of the current top level’s project root
Creating a Builder
An external tool configuration as described in the previous section
makes it easy to run an external tool, but you still have to do so
explicitly. For some programs, such as the make utility, it makes
sense instead to do this automatically upon a change in your project.
This functionality can be accomplished by a builder. We will show how to
create a builder for a Modelsim Makefile as an example.
To create a builder, right-click your project and select Properties >
Builders.
Click New… and the builder configuration window will pop up:
You will be asked to select a configuration type:
select Program.
Next, configure the builder in a configuration window pop up window:
Name: The name of your builder, e.g. ModelSim.
Location: The location of the program, e.g. /usr/bin/make.
Working Directory: The working directory for your program. For example, click Browse Workspace… and select the root folder of your project.
Arguments: The arguments to your program, e.g. --makefile=Makefile.vsim all.
With the default settings the ModelSim Makefile will only be run during
a manual build or after a “Clean”. To make sure Sigasi Studio runs make
every time you save a change to a file, click the Build Options tab
and check the During auto builds checkbox.
After configuration, the new builder will appear in the builder list.
When you close the builder configuration dialog windows, the new builder
will automatically be run. In our example of a Modelsim Makefile,
Modelsim’s messages will appear in the console view.
For the specific case of Modelsim, warnings and error messages in the
console are made clickable. When you click a message, the corresponding
location will automatically be opened in the Editor view.
You can add as many extra builders as you want. This can be useful for
additional linting tools or code generators.
Intel Quartus integration
If you are using Intel Quartus 12.1 or higher, you can use Sigasi Studio as
preferred HDL editor.
If you use the Sigasi Studio/ Intel Quartus integration, you can
easily open VHDL files by double clicking on them in Quartus. Sigasi
Studio will be aware of the entire Quartus project, so that you can
perform project-wide searches and navigation actions in Sigasi Studio.
Furthermore, if you add or remove files in the Quartus project, these
changes are automatically applied in Sigasi Studio.
Note: If you want to set up a project independent of Intel Quartus,
please read the documentation on setting up a project.
Setting the preferred editor
While importing a Quartus Project in Sigasi Studio, you have the
possibility to configure Sigasi Studio as preferred editor
in Intel Quartus.
This offers the ability to open files in Sigasi Studio from within Quartus.
Open a Quartus Project in Sigasi Studio
After you have configured Sigasi Studio to be the preferred editor in
Quartus, you can open files by double clicking on them in Quartus.
Sigasi Studio will import entire Quartus project and your file will open
in the Sigasi Studio editor view. If you make changes to your Quartus
project (like adding or removing files), these changes are reflected in
Sigasi Studio as well.
The first time you import your project, it may take a few minutes. After
that, you can leave Sigasi Studio open and double-click other files in
Quartus to open them in the Sigasi Studio editor view.
If your Quartus Project File (.QPF file) contains a reference to a
file that does not exist, Sigasi Studio will show an icon for that file with
the broken link icon .
Quartus Preferences
The first time you import a Quartus project, Sigasi Studio will ask for the
Quartus installation location. Sigasi Studio needs this path to find the
Quartus libraries. You can change the Quartus installation
location by selecting Window > Preferences > Sigasi > Toolchains.
Add files to your Quartus project in Sigasi Studio
To add a file to your Quartus project, you can use the default New
VHDL file wizard of Sigasi Studio (File > New > VHDL File).
Note that Quartus does not automatically update its UI after you add
files to your project. In order to update the files list, you should run
a work flow action in Quartus, like starting a compilation.
AMD/Xilinx integration
Setting the preferred editor
To open the Sigasi Studio editor from AMD/Xilinx, you first have to configure Sigasi Studio as preferred editor in Vivado or ISE.
You can change the AMD/Xilinx Vivado installation location by selecting Window > Preferences > Sigasi > Toolchains > Xilinx Vivado.
Sigasi Studio needs this path to find the AMD/Xilinx Vivado libraries.
ISE
You can change the AMD/Xilinx ISE installation location by selecting Window > Preferences > Sigasi > Toolchains > Xilinx ISE.
Sigasi Studio needs this path to find the AMD/Xilinx ISE libraries and to run the ISim compiler and simulator.
Export
You can export a list of all HDL files in your project, sorted in the correct compilation order.
You can use your own simple scripts to manipulate such list and run any EDA tool, including simulators, synthesis and linter tools.
To export a comma separated value (CSV) list of files in your project, right-click your project and select Export….
In the Sigasi category, select CSV File. Then select the project you want to export.
As a result, you get a file named compilation_order.csv, which lists the HDL files in your project in a valid compile order.
This file will use relative paths, except when the file is on a different drive (on Windows).
Auto-export
You can also configure Sigasi Studio to auto-export this CSV file, every time the dependencies change.
Right click on the project you want to auto-export in the Project Explorer, and select Properties and Sigasi Auto Export.
If you do not set a fixed top level name (i.e. empty top level name in the property page), Sigasi Studio will use the current top level in the Hierarchy View as input.
Note that this only works if the top level belongs to the selected project.
This information is stored in .settings/com.sigasi.hdt.shared.ui.prefs in your project.
VUnit is an open source unit testing framework for VHDL and SystemVerilog. VUnit helps you to write tests more easily and run them frequently.
Sigasi Studio can help you manage VUnit projects and enables you to run and inspect test results straight from the IDE.
When you import a VUnit project or add VUnit support to an existing project, Sigasi Studio runs VUnit in the background and automatically adds the correct libraries - as specified by the VUnit script - to your project. It also shows error markers in the VUnit script (run.py) if anything goes wrong.
Since Sigasi Studio 4.14, the library mapping of the project is automatically updated based on the contents of the VUnit run.py script.
VUnit project setup in Sigasi Studio
Prerequisites
VUnit version 4.5.0 or higher is required.
Sigasi Studio needs to know where VUnit is installed. If you installed VUnit using pip install vunit_hdl and Python is in your path, then Sigasi Studio should find your VUnit installation.
To verify whether Sigasi Studio can find your VUnit installation, go to Window > Preferences > Sigasi > Toolchains > VUnit and check the read-only VUnit installation path field.
If your Python installation is not in the path, you can configure it here in the Python executable location field.
If you have installed VUnit in a dedicated location, you should add the VUnit location to the $PYTHONPATH and make sure the $PYTHONPATH variable is visible to Sigasi Studio.
When you’re installing VUnit in a virtualenv, make sure to launch Sigasi Studio from within the terminal after activating the virtualenv.
If you installed VUnit from the Microsoft Store, you might get an error message when trying to select the Python executable.
To use Python outside of Windows Store apps, Python needs to be installed using an installer from https://www.python.org/downloads/windows/.
You should make sure that the python run.py --version command only returns the VUnit version number. Additional output will prevent Sigasi Studio to parse the VUnit version number correctly and will result in errors.
Import VUnit Project
To import an existing VUnit project, click File > Import… > Sigasi > Import a VUnit project. Next, select the VUnit script (run.py) and the location for the Sigasi Project.
The VUnit project repository comes with a number of example projects which can be imported this way. If you first specify the Python Script Location, the Project Location will be set automatically.
Add VUnit support to an existing Sigasi project
You can also add VUnit support to an existing project: Right-click your project and select Configure > Add VUnit support. Next, select an existing run.py script or let Sigasi create an example script.
VUnit project configuration and troubleshooting
The VUnit integration in Sigasi Studio gives useful feedback in the VUnit Console View.
To open this view, first open a console (Window > Show View > Other… > General > Console) and in the Console View toolbar click the triangle () next to the Open Console icon.
Select VUnit Console to open the VUnit Console View.
Since Sigasi Studio 4.14, the library configuration from run.py is used to configure the library configuration in the Sigasi Studio project.
Note that this automatic configuration does not work with linked folders.
You need to manually assign linked folders or any files/folders in them to a library.
Path separators in the run.py file need a /, also on Windows.
SystemVerilog
For SystemVerilog projects you need to manually add the VUnit include files to your projects:
Right click your project, select New > Folder > Advanced > Link to alternate location and add VUNIT/verilog/include as location.
Use the quick-fix on the failing `include "vunit_defines.svh" to add the include folder to the include paths.
Configure options for finding and running tests
In Window > Preferences > Sigasi > Toolchains > VUnit you can add different options for finding and running tests.
The Options for finding tests will be passed to run.py when generating the json file that lists the VUnit tests.
The Options for running tests will be passed to run.py when running the VUnit tests.
Select the Set VUnit output to project root to have the VUnit output stored in the project root instead of in the temp location from where VUnit is called.
Run VUnit Tests
There are multiple ways to run VUnit tests in Sigasi Studio:
Right click your project and select Run VUnit tests to run all tests in your project.
Right click one or more HDL files and select Run VUnit tests to run all tests in the selected files.
Right click in the Sigasi editor and select Run VUnit tests to run all tests in the active editor.
Right click in the VUnit test name (the string in the run function call) and select Run VUnit test to run this single test only.
Rerun the tests in the VUnit view.
Inspect VUnit Test Results
When you run VUnit tests in Sigasi Studio, the VUnit view is opened. This view presents a convenient way to inspect the test results.
You can also open the Console View to inspect the entire VUnit output.
Handling specific common libraries
In Sigasi Studio, Common Libraries may be present in a project. Some
of these are standardized and available in all tools, e.g. IEEE VHDL
libraries, or the VUnit library in case of a VUnit project. Your
project may also require vendor or company specific common
libraries. External simulators, including the simulator which runs
your VUnit tests, require a particular setup to find your library.
If, for instance, ModelSim is used, then:
common libraries need to be pre-compiled,
a customized modelsim.ini with a reference to the pre-compiled libraries is required, and
VUnit needs to be aware of the customized modelsim.ini.
The latter is achieved by setting an environment variable
VUNIT_MODELSIM_INI which points at the customized
modelsim.ini. One could set this variable from the shell (Linux) or
user variables (Windows), but that is inconvenient as all projects
will use the same modelsim.ini. A better solution is to set
VUNIT_MODELSIM_INI in the run.py script, before calling
VUnit.from_argv().
# This is run.py# code omittedos.environ['VUNIT_MODELSIM_INI']='/path/to/custom/modelsim.ini'vu=VUnit.from_argv()# code omitted
Note that VUnit may still produce warnings that the library is
missing, as shown below. These warnings are harmless. They show up
because only Sigasi Studio and the simulator are aware of the library,
while VUnit is not.
WARNING - C:\Users\Wim Meeus\workspaceSigasi\VUnit-demo\design\design_top.vhd: failed to find library 'vucommon'
Alternatively, one could define the library and its
contents in the run.py script. In that case, VUnit will be aware of
the library and the warnings won’t show, but compile times will be
longer - which is exactly what common libraries are meant to avoid.
Using an external compiler in a VUnit project
If you want to configure an external compiler in a VUnit project
(e.g. for additional syntax checking), you need to ensure that the
compiler has the VUnit library. Otherwise, the compiler will flag all
VUnit constructs in your HDL code as errors.
How to compile and enable the VUnit library for an external compiler
is explained in the libraries section of this
manual.
The Sigasi Studio documentation generator makes the documentation process easier by automatically extracting information from your HDL source files. The biggest advantage is that there is only a single source for both your design and your documentation. While this gives no guarantee for the design staying in sync with the documentation, it certainly makes it easier.
The Sigasi documentation generator has following advantages:
No special coding requirements: the plain comments in your code are extracted for the documentation, no need for special annotations. Sigasi uses the same comment association as the hover provider. So to document a port, you append a comment to a port declaration. To document an architecture, you put the comment just on top of the architecture.
All included. All documentation processing is done in Sigasi/Eclipse. So you do not need to install extra tools.
Fully hyperlinked. If you export the documentation, you get a fully hyperlinked document.
Live preview: you can see what the documentation will look like while you type your code and comments.
Export Documentation
You can export documentation for the entire project or a specific toplevel by clicking the save icon on top of the Documentation View or via the Export… menu.
When you select the entire project, the design elements will be listed in alphabetical order.
When you select a specific toplevel, design elements will be ordered in a breadth-first order from the top down.
The resulting HTML file is saved in the sigasi-doc folder in the root of your project.
The generated Block and State Machine Diagrams are saved in subfolders of the sigasi-doc folder.
Sigasi Studio 4.5 introduced exporting the documentation to HTML.
You have to choose between Linked resources and Embedded resources when exporting the documentation.
Linked resources
Creates an HTML document with linked resources.
All Block Diagrams and State Machine Diagrams are in separate files which are linked from within the HTML document.
The custom CSS file, if present in the project root, will be referenced from the HTML document.
Embedded resources
Creates an HTML document with embedded resources. The documentation is in a single file.
The Block Diagrams and State Machine Diagrams are embedded in the HTML document.
The CSS from the custom CSS file, if present in the project root, will be included in the HTML <head>.
Any errors are logged to the console view.
Customization
Sigasi Studio 4.17 introduced pagination and the introduction and problems section.
Pagination
Enabling the Split pages by elements count will paginate the output documentation. This is useful for very big designs that produce documentation 100’s of MBs large.
The summary information about the design appears on the first page and fans out to subsequent pages that will contain the documentation about individual design elements.
Problems section
Enabling Include problem information will add a Problems section containing all the project’s Errors, Errors and warnings, or Errors, warnings, and infos. On top of that, the suppressed problems can also be shown.
Introduction section
If a sigasi-doc.md file is present in the root directory of your project, Sigasi will automatically include it in the exported documentation as an introductory chapter.
As usual with our documentation, this is a MarkDown file. This allows you to easily annotate the text.
The exported documentation includes the Dependency Diagram, State Machine and Block Diagrams.
If you created custom graphics configurations for one or more of your diagrams, these will be used instead of the default diagrams.
If you have multiple graphics configurations for the same diagrams, the alphabetically first one is used.
Custom CSS
If the root of your project contains a sigasi-doc.css file, this file will be used to style the generated HTML documentation.
Note that only the generated HTML will be affected and not the Documentation View.
For example, you can give the background and titles different colors. You can also change the font for the entire document or parts of it.
Entire sections for entities, architectures and modules can be given different background colors.
Likewise the list of processes can get a different background color.
The difference in documentation with the CSS settings described above is shown in the screenshots below.
Comment Association
Comments in HDL code are used to add extra information or documentation to that code.
Sigasi Studio uses certain rules to determine which comment belongs to which code.
This is important for documentation hovers, refactoring, formatting,…
Which comment belongs to which exact code is subjective.
Sigasi Studio associates comments with HDL declarations with following rules:
If there is a declaration before a comment in the same line (trailing comment), the comment is associated with this declaration. This comment can span multiple single line comments if they are aligned.
If there is no trailing comment and there is a comment with the same indentation on the line above the declaration, the comment is associated with this declaration. This comment can span multiple lines if all comments have the same indentation.
Empty lines break comment blocks
The association rules are illustrated in the image below:
The Formatter and Structural select respect (and fix) comments according to the association rules.
Special cases
VHDL components and component instantiations: If a component (or one of its ports or generics) does not have comment itself, Sigasi Studio will use the comment of the corresponding entity. This also works for component instantiations.
Comment markup with Markdown
VHDL and SystemVerilog comments are processed with a Markdown processor. This allows to add markup (e.g. bold, code, paragraphs, hyperlinks,…) to comments. This results in nicer hovers and documentation.
In hovers the complete Markdown syntax is supported. For documentation generation following features are supported:
paragraphs (add and empty comment line to break paragraphs)
line breaks (by adding two trailing spaces)
emphasis (*emphasis*)
strong (**strong**)
lists
tables (with alignment)
external links and email addresses (<https://www.sigasi.com>, [Sigasi](https://www.sigasi.com) and <sales@sigasi.com>)
Sigasi Studio 4.6 added support for Fenced Code blocks in comments.
This enables you to add text to the documentation without Markdown rendering.
To add a comment verbatim to the documentation, surround it with with triple back ticks: ```<verbatim comment>```
The BlockDiagram- and StateMachine views are a very useful way to explore and understand HDL designs, but sometimes that just doesn’t cut it.
The diagrams can be too complex and crowded to understand a design. For this reason, the diagrams can’t always be directly used in documentation. To solve this challenge you can make use of the Graphics Configuration Language.
The Language
The Graphics Configuration Language is a plain text file containing declarations and configurations, which when interpreted, result in grouping, filtering and coloring in the diagram.
You can see it in action in the images below:
This BlockDiagram
Turns into:
This StateMachine
Turns into:
A plain text format was chosen over a buttons and menus for several reasons:
It can easily be managed with your version control system because files can easily be compared and merged.
It’s easy to debug by yourself, unlike proprietary formats or UIs.
We can support you using all of our well-known features such as auto-complete, validations, formatting,…
It’s lightweight and can be used as the basis for the UI implementation.
Getting started
To get started, choose a design with a BlockDiagram or StateMachine you want to simplify.
Create a new Graphics Configuration file by going to File > New > Other > Graphics Configuration > Graphics Configuration File.
You can also press the Sigasi button on the top right of the BlockDiagram or StateMachine view.
From there, you can declare groups and configure your diagram, check it in to version control and share it with your colleagues.
Auto-complete (Ctrl+Space) helps you write most of the code while formatting (Shift+Ctrl+F) helps you to keep your file clean.
If you’re interested in the language’s exact syntax, you can find it here.
Features
The Graphics Configuration features:
Grouping
Hiding
Reassignment hiding
Block collapsing
Coloring
Regex matching
Note that in the BlockDiagram you can group blocks and wires while in the StateMachine you can only group states.
Graphics Configuration Editor features:
Auto-complete (Ctrl+Space)
Formatting (Shift+Ctrl+F)
Quick outline (Ctrl+O)
Show in BlockDiagram/StateMachine (Alt+Shift+W)
Navigate to declaration (Ctrl+click or F3 on identifier)
Double-click on a diagram element to navigate to it in the code
Hovering to show more information
Graphics Configuration for BlockDiagrams
You can express which diagram you want to filter in the first line of the file by writing diagram fullyQualifiedName. The fully qualified name in VHDL is always library.entity.architecture. In SystemVerilog this is work.module.
E.g. if you want to filter the diagram for the architecture RTL implementing the entity ent in the work library, you use the following line as the first line: diagram work.VME64xCore_Top.RTL.
The file is read from bottom to top. You start with the above definition of the diagram, then within that you can hide reassignments, create groups and finally, create configurations for ports, blocks and edges.
Hiding reassignments
When using a lot of reassignments or when you’re indexing vectors, you can get a skyscraper effect in the generated block diagrams.
By using reassignments hide you can draw through the assignment blocks making the diagram a lot simpler.
Skyscraper
Hidden reassignments
Multiple reassignments
Hidden reassignments
Grouping
After hiding the reassignments you can define groups of edges or blocks.
The syntax for a group is as follows: def Type group ID (Identifiers)
Where Type is block or wire, ID is the new name of the group and Identifiers is a comma separated list of existing IDs (Graphics Configuration, VHDL or SystemVerilog) or a regex.
The syntax for a regex is regex"regex_pattern". This uses Java regexes, you can also find a cheat sheet here.
You can also check what the regex matches by hovering over the query.
E.g. if you want to group block2 and block3 you can add either of the following lines: group block middle regex"block[23]" group block middle (block2, block3)
Ungrouped
Grouped
The same can be done for wires by using wire instead of block.
Ports can be grouped by grouping the wires attached to the ports into a bus.
Configuration
The syntax for a configuration block is as follows: Type Identifiers { ConfigurationItem* }
Where Type is block, wire or port.
The syntax for a ConfigurationItem is as follows: hide | collapse | color GraphicsColor | reassignments hide
You can discover which colors are available here or through the autocomplete.
E.g. we can color a block, called middle, green and hide its internals: Colored and collapsed group
Configurations are not cascading (unlike CSS).
Coloring the middle block green does not turn all its internal blocks green as well.
Note that the language can not see everything: it can not see blocks, wires or ports that are within another block.
E.g. we can’t type block block3 { color red } as block3 is part of the block middle.
To access a block within a block, we have to nest configurations.
Nested configuration
Another use case would be to hide (unconnected) ports by using port a { hide }.
Hidden port
Note that when you hide a block or port, the edges that are connected to them will also be hidden.
It is also possible to hide reassignments in configurations, as you saw in the above skyscraper example, the reassignment in the generate block was not hidden.
You can do so as follows:
Hidden reassignment in generate
Graphics Configuration for StateMachines
StateMachines are configured in the same way as the above BlockDiagrams, except the only Type that can be used is state.
The header is also slightly different, the syntax is as follows: statemachine architecture : state_variable.
For an example you can check out step_3_state_machines.vhd (in our VHDL Tutorial) with this filter file.
Hiding labels
Labels on state transitions can be hidden using labels hide.
You can also use labels comment or labels condition to only show comment or condition labels on the state transitions.
Since Sigasi Studio is built on Eclipse, you can install third-party Eclipse plugins.
The best place to start looking for a plugin is the Eclipse Marketplace. We list some interesting
plugins here. Since these are third-party plugins, there is no official
support from Sigasi.
Installing Plugins
Unlike most Eclipse distributions Sigasi Studio is shipped without the Eclipse Marketplace plugin and the standard Eclipse update sites.
Hence, you have to add a plugin update site to install new plugins.
Click Help > Install New Software Now click Add and fill out the update site. Press OK to confirm.
Installing
Still in the Install dialog, search for the plugin you want to install. You can browse the list of available plugins or use the filter text above the list of plugins.
Select the checkbox for the plugin and click Next
Follow the instructions for the rest of the wizard.
Revision Control Systems
Sigasi Studio supports a wide range of Revision Control
Systems (also known as
Version Control or Source Control systems). Support for revision control
is based on Eclipse plugins. This section contains a preliminary listing
of the most popular revision control systems.
GIT
Recommended plugin: EGit
This plugin is shipped with the standalone version of Sigasi Studio.
While this is not strictly speaking a version control system, Sigasi Studio has
a built-in feature that keeps a local history of your files.
Learn more.
Other Systems
Some other popular revision control systems include:
Python: You can add support for Python to Sigasi Studio by installing the PyDev Eclipse plugin.
Use https://www.pydev.org/updates as update site.
Remote Collaboration
You can use the Saros plugin to remotely collaborate on the same project with multiple people. You’ll see edits from collaborators in your own editor as they happen. To install the Saros plugin in Sigasi Studio, use https://www.saros-project.org/update-site/eclipse as update site.
Opening to a Shell
If you want a quick way to open files and folders from the Project Explorer in a terminal, EasyShell is a useful plugin.
If the user interface of Sigasi Studio is unresponsive, you can interrupt the internal compilation process by pressing the stop button in the progress view. To activate the progress view, select Window > Show View > Other… > General > Progress, or click the tiny conveyor belt icon , on the right side of the status bar.
Create performance and memory snapshots
Performace snapshot
Sigasi Studio has a built-in profiler. By default this profiler is not active.
On some occasions we’ll ask you to provide an anonymized performance snapshot from the profiler.
To obtain this snapshot, follow the steps below.
Activate the profile using Help > Sigasi > Performance > Start Async Sampling
On Windows, use Help > Sigasi > Performance > Start Sampling instead.
Perform the laggy operations in Sigasi Studio
Stop the profiler using Help > Sigasi > Performance > Stop Profiling
Memory snapshot
It may happen that, as part of a support case, we’ll ask you to
provide an anonymized memory snapshot of a running Sigasi application.
To obtain this snapshot, select Help > Sigasi > Performance >
Capture Heap . You’ll be prompted for a location and a filename to
store the memory snapshot.
Sending your snapshot to Sigasi
The snapshot you’ve obtained needs to be obfuscated to anonymize it and it needs to be uploaded.
If you edit a file outside of Sigasi Studio with an external editor, Sigasi Studio will normally notice the changes and ask if you want to load the changes. If
it doesn’t, you can refresh the editor’s content by pressing F5 or by right-clicking a file or a project in the project explorer and
selecting Refresh.
No content in the editor and only a cross in the editor tab
If you see empty views in Sigasi Studio on Linux: make sure libXss or libXscrnSaver is installed.
How much local history will be stored?
Sigasi Studio stores the history of your file so that you can compare your current version with the version you saved an hour ago.
You can define how much disk space is used for storing local history in Windows > Preferences, select General > Workspace > Local History.
For more information on local history, check out this page.
I see hundreds or thousands of errors
If you see a large number of errors, you either have very, very buggy code (not so likely) or your project is not configured correctly.
Check that all files are mapped to the correct library.
Check that all stale files are ignored. (see the section on unneeded files)
Check that all third party libraries are included.
Make sure that automatic build is enabled.
Auto Build is not Enabled
Symptoms:
When you introduce an error in a VHDL or Verilog file and save the file, an error marker shows up in the file, but not in the problems view.
Navigation (Find References, Open Declaration) behaves strangely when it involves more than one file.
Other features that involve multiple files behave incorrectly: autcomplete, refactoring, …
VHDL files contain errors, but these errors do not show up in the Problems View.
Cannot select a top level in the Hierarchy View
Cannot navigate from a name in one file to its declaration in another file.
In the Project Explorer, the name of the library (for example: [work]) is not shown next to the filename.
Cause: The project does not have VHDL support enabled
Resolution: Enable VHDL support: right-click the project > Configure > Add VHDL support
Project does not have Library Mapping Information
Symptoms:
All VHDL-files in the project are not mapped
The Project contains only one error: “This VHDL project can not be built since the library mapping information is missing”
VHDL files contain errors, but these errors do not show up in the Problems View.
In the Project Explorer, the name of the library (for example: [work]) is not shown next to the filename.
Cause: The project does not have a (valid) VHDL library mapping information file
Resolution: Reset the library mapping: right-click the project > Library Mapping > Reset Library Mapping
Project does not have Common Libraries
Symptoms:
Project has many errors, in practically all files. Project build may be slow.
The standard data types (like integer and std_logic) are not recognized.
The IEEE and STD libraries are not recognized.
The IEEE and STD files are either missing or are mapped to the wrong library (for example: [work]).
Cause: Common libraries are not configured correctly.
Resolution: Reset the common libraries: right-click the project > Library Mapping > Reset Library Mapping
Sigasi Studio analyzes HDL files that I do not need
By default, Sigasi Studio assumes that all VHDL or Verilog files are part of the project. However, some projects may contain multiple files with older or alternative definitions of a VHDL object. We call these stale files, because they are no longer used. In such a case you will want Sigasi Studio to ignore certain files.
Ignored resources are decorated with a icon in the project explorer view.
Sigasi Studio startup fails: “Could not create the Java virtual machine”
On some computers, the standalone version of Sigasi Studio will fail to start with an error message similar to: “Could not create the Java virtual machine.” This happens especially on 32-bit Windows machines with less than 2GB of physical memory. The reason is that the Java virtual machine tries to allocate more memory than what is available.
In order to solve this, you can decrease the default heap size settings. You can do this by adding following lines to sigasi.ini or eclipse.ini in your Sigasi Studio installation folder:
-vmargs
-Xmx1000m
This sets the maximum heap size to 1000 MB (instead of the standard 3GB).
Note: Do not use eclipsec.exe, as this will ignore all of the settings configured in the eclipse.ini file.
Sigasi Studio shows a startup message about port 4444 already being in use
If you want to run Sigasi Studio on a server with multiple users, the configuration files should be updated according to the descriptions here.
I want a clean restart
If you ever suspect that the state of your project is inconsistent in Sigasi Studio, you can do one or all of the following things. Consider these
steps to be advanced usage; you should not need them during normal operation.
Force a clean compilation
You can force a completely clean compilation by selecting: Project > Clean … > Clean All Projects > OK.
Remove stale markers
Sometimes markers remain visible, even after the problem is fixed or when a file is excluded from compilation. We call these stale markers and they are can be caused by a crash during compilation.
You can delete these stale markers from the Problems View: In the Problems View, select the markers and press DEL (or right-click and select Delete).
Note that during the next build, the tool may generate new markers. If you want to suppress certain warnings, you can configure the linting rules.
Remove the cache
For faster performance Sigasi Studio is using a cache.
Sometimes the cache can get corrupted which might cause internal errors.
The cache is located in your workspace.
By default, Sigasi Studio’s workspace is located in ${HOME}/workspaceSigasi.
To remove the cache, stop Sigasi Studio and delete the folder workspaceSigasi/.metadata/.plugins/com.sigasi.hdt.shared.ui/resource.cache/sigasiBuildCache.
Remove the workspace state
Much of your configuration and cached data is stored in your workspace.
By default, Sigasi Studio’s workspace is located in ${HOME}/workspaceSigasi.
A lot of this data is stored in the hidden .metadata directory.
Sometimes, a part of your metadata can become corrupt.
It can help to remove the .metadata directory (take a backup first!).
This clears all of your workspace state.
You will need to enter your license code again.
You will need to import your projects again. Import > General > Existing Projects into Workspace
Keep getting reports about an “Incompatible version of Quartus”
If you are using the integration with Intel Quartus. Some people keep getting a dialog box that says something like:
Incompatible version of Quartus
Project interface was created with an older, incompatible version of Quartus.
Is it OK to upgrade the project to match the installed version of Quartus?
Obviously, you should upgrade the project. If this message keeps popping up, you may want to check that Sigasi Studio is using the correct version of Quartus, in the Sigasi Studio application: Window > Preferences > Sigasi > Toolchains > Intel Quartus.
Contact support
If this troubleshooting guide did not solve your problem, please send us an email
.
Any of the following information will help us help you:
Steps to reproduce your problem
Description of the expected behavior and the actual behavior.
The version number of your Sigasi Studio: Help > About Sigasi > Installation details Note that the version number contains the date of the release. (For example, version 2.0.1.20110809… was released on August 9, 2011.)
As you become more experienced with Sigasi Studio, you will find that there are a number of actions that you perform quite often. At some point, you may feel that the GUI-based approach becomes too slow for these actions. For that reason, Sigasi Studio provides a number of keyboard shortcuts. They are a great way to boost your productivity. A printable cheat sheet with all shortcuts on one page is available for download.
In this chapter, we describe the available keyboard shortcuts.
Top keyboard shortcuts
In this section, we list the most important shortcuts.
Open Resource (Shift+Ctrl+R): Shift+Ctrl+R opens a dialog that allows you to swiftly open an editor on any file in the workspace.
Open Declaration (F3):
Use F3 to navigate to the declaration of the selected identifier.
Open Design Unit (Shift+Ctrl+D): Shift+Ctrl+D opens a dialog in which you can type a name or pattern to open a specific VHDL or SystemVerilog design unit name.
Backward History (Alt+Left):
Often, when you navigate to a declaration you want to go back to where you came from; just press Alt+Left.
Content Assist (Ctrl+Space):
With content assist (autocomplete) you can really speed up coding VHDL. Just press Ctrl+Space to get a suggestion of possible autocompletes in the current context.
Go to next marker (Ctrl+.)
Does your file contain warnings or errors? Quickly navigate to the next problem by pressing Ctrl+. (Ctrl+, jumps to the previous problem).
Quick Fix (Ctrl+1):
To fix problems even quicker, navigate to the problem with the previous shortcut. Press Ctrl+1 to activate the Quick Fix, select the fix with the UP or DOWN keys and execute the Quick Fix with Enter.
Go to Line (Ctrl+L)
You can directly jump to a certain line with this shortcut. You can display the line numbers by right-clicking on on the gray bar on the left side of the editor view and clicking on Show Line Numbers.
Search references (Shift+Ctrl+G)
To search for all occurrences of a given identifier, just select the identifier and press Shift+Ctrl+G. The search view is displayed, with a match for each occurrence (possibly in multiple files)
Rename Refactoring (Shift+Alt+R)
Once you get used to the rename refactoring you will be using it all the time. Use Shift+Alt+R to run it even quicker.
Toggle Block Selection (Shift+Alt+A)
Switch between regular and block selection mode.
Structured Select (Shift+Alt+Up/Down/Left/Right)
Select VHDL or Verilog code, based on its syntactic structure. (Structured selection)
Format (Shift+Ctrl+F)
Format your current VHDL or SystemVerilog file.
Quick Access (Ctrl+3, This is the shortcut to use, when you forgot the shortcut you actually need.)
With Quick Access you can quickly find open editors, available perspectives, views, preferences, wizards, commands, etc. Simply start typing the name of the item you wish to invoke.
If you are using MacOS, most of these keyboard shortcuts use Command instead of Ctrl. To inspect the exact list of keyboard shortcuts, go to Preferences > General > Keys.
Customizing keyboard shortcuts
Keyboard shortcuts can be easily customized via Preferences > General > Keys.
This preference page also enables you to select the Emacs scheme, for more Emacs-like keyboard shortcuts, or (if you have installed the UltraEdit key bindings for Eclipse plugin) the UltraEdit key bindings.
If you’re looking for Vi or Emacs keybindings, have a look at Third Party Plugins.
The advanced setup of Sigasi Studio is meant for engineers and organizations who want to:
automate the setup of Sigasi Studio
automate the setup of a project (or a set of related projects)
combine Sigasi’s VHDL and SystemVerilog support with other programming languages, version control settings, or different Eclipse plugins
ensure that all team members share the same settings (indent style, templates, linting preferences…).
The advanced setup uses
Oomph, a highly
customizable installer for Eclipse. Oomph is configured with setup
files. Most of the team members will use these files when setting up a
new version of eclipse and/or when they join a new project. Only every
now and then, e.g. at the start of a new project, a setup file needs
to be created or updated.
For the standard setup procedure for Sigasi Studio, look here.
The user perspective: using existing setup files.
Setting up the latest version of Eclipse with the Sigasi Studio plugin
is easy and straightforward. One or two files are needed:
The product setup file determines the Eclipse setup, e.g. plugins and workspace settings.
The optional project setup file tells Eclipse how to set up a project, e.g. from a version control system.
To get the installation started, download, unzip and run the Eclipse
installer. In the top-right
corner, click the 3 horizontal bars (the burger menu) and select
Advanced Mode….
Next, click on the plus icon next to the filter text and enter the URI
of the product setup file. This can be a file on your system or a web
link, e.g. to a file on your team’s internal web page. For demo
purposes, you can use our example file:
https://insights.sigasi.com/resources/manual/SigasiStudio.setup. Click
OK to close the pop-up.
Select the desired product setup under User Products and click Next >.
Now you can optionally select a project to set up. Again, click the
plus icon next to the filter text and enter the URI of the project
setup file. You may want to try our demo project from
https://insights.sigasi.com/resources/manual/SigasiDemoProject.setup
which will set up a Sigasi project using git version control. Select
the desired project (checkbox) and click Next >.
Next, configure the path for your Eclipse installation, workspace and
project. Check Show all variables to see all relevant paths. Make
changes if required and click Next > to continue. In the next
screen, click Finish to start the setup process.
At the end of the product setup (Eclipse install), Eclipse starts
up. If a project setup was selected, a second Eclipse installer starts
for that purpose. When finished, the Eclipse installer window(s) may
be closed by clicking Finish.
Your new Eclipse with Sigasi Studio is now ready, with the optional
project if one was selected.
Setting up the setup files
So far, we’ve seen how a user can set up Eclipse, Sigasi Studio and
projects quickly and easily using setup files. These setup files are
convenient for teams to keep tool settings consistent between team
members.
This section discusses how to create and modify setup files. Setup
files use the XML format, which means that they are structured text
files and therefore human readable. The Eclipse Oomph plugin has a
convenient graphical editor for these files. Using a text editor is
error-prone and therefore not recommended.
Setting up Eclipse Oomph
Oomph is an Eclipse plugin, so you’ll want to either run Oomph in your
current Eclipse, or install a separate (minimal) Eclipse. The Eclipse
installer can be found
here. Recent versions of Eclipse
contain Oomph by default, so you shouldn’t need to install anything
extra.
If your Eclipse doesn’t contain Oomph, open Eclipse, go to Help >
Install New Software…, enter
http://download.eclipse.org/oomph/updates/release in the box next
to Work with, select the Oomph Setup > Oomph Setup and proceed
with the installation.
Then, create a new General project to contain the setup files:
File > New > Project… > General > Project, name the project and
click Finish.
Now you can either create new product and project setup files in this
project, or copy (drag & drop or otherwise) files into the project for
customization.
Product setup file
For a product setup file, it is recommended to start from one of our
examples: either a fairly minimal
SigasiStudio.setup or an
example in which a few extra workspace options are configured:
SigasiStudioPlus.setup.
Place one of these files in your Oomph project and open it for further
customization.
If you prefer to start from scratch, right-click your Oomph project
and select New > Other… > Oomph > Setup Product Model, and check
out one of the above examples for the basic configuration.
Both examples will install Eclipse with Sigasi Studio and Git revision
control. The minimal example will, in addition, configure the maximum
heap space for Eclipse, it will enable the Sigasi perspective, and it
will turn off the Preferences Recorder. The extended example, shown
above in the Oomph editor, contains further options for linting
severities, formatting options and an auto-complete template.
Note the three groups of settings:
Eclipse Ini: settings that will go in eclipse.ini.
P2 Director: plugins to install and the repositories where they
can be found. Here you can add additional plugins, e.g. to support
an additional programming language or a different revision control
system. To add an item, right-click P2 Director, and select
New Child > Requirement for an additional plugin, and
subsequently New Child > Repository for the plugin repository.
Custom preferences: workspace settings. Here you can fine-tune
workspace settings to the need of your team. To add a new
preference, first find the key and the value of the preference
which you want to configure (see below). Then, right-click Custom
preferences and select New Child > Preference. Then fill out
the key, the value and the optional description.
Finding keys and values of workspace preferences is easy as
follows. First, install a custom Eclipse with the setup file as it is,
i.e. without the preference. In that copy of Eclipse, select
Window > Preferences > Oomph > Setup Tasks > Preference Recorder, check the
Record into: checkbox and click the Open the recorder target
file icon on the same line. Then, set other preferences as
desired. After clicking Apply and Close, a pop-up like the one
below shows the information for the key and value to configure.
After adding the desired preferences and plugins, it’s time to save
the setup file and use it with the Eclipse installer, as described
here.
Project setup file
For a project setup file, it is recommended to start from our example:
SigasiDemoProject.setup,
which you can copy into your Oomph project and open for further
customization. If you prefer to start from scratch, right-click your
Oomph project and select New > Other… > Oomph > Setup Project
Model, and check out the above example for the basic configuration.
Specify the location of your project and save the file. Now it is ready
for use in the Eclipse installer.
We recommend to save project preferences in version control with
the project, rather than in a project setup file. That way, changes to
project settings get propagated to all team members effortlessly, and
each revision of the project contains matching project settings. To
that end, store .project, .library_mapping.xml and .settings of
your project in version control.
Sigasi Studio supports VHDL version 1993, 2002, 2008 and 2019 and Verilog (2005) and SystemVerilog (2012).
You can select the default VHDL version to use in: Window > Preferences > Sigasi > VHDL.
You can set the default Verilog version in: Window > Preferences > Sigasi > (System)Verilog.
Since Sigasi Studio 3.2, you can also set the language version
per project, per folder and per file.
In the Project Explorer, right click your project, folder or file; select Properties > VHDL Version
or Properties > (System)Verilog Version and select the version via the dropdown menu.
When you change the language version of a file, only that file is affected.
However, when you change the version of a folder, then everything in that folder will have the new language version.
Any overrides in the folder and its sub-folders will be removed.
When you are defining the language versions for a new project you should map from top (project root) to bottom (files).
The version information is stored in <project path>/.settings/com.sigasi.hdt.vhdl.version.prefs and <project path>/.settings/com.sigasi.hdt.verilog.version.prefs.
We recommend you add this file to version control so you can share it with your team.
Notes:
VHDL libaries: Any new project that you create will have the Common Libraries (STD and IEEE) that correspond to your selected VHDL version.
Your existing project will not be modified.
If you want to update the Common Libraries for an existing project, right-click the project and select Library Mapping > Reset Common Libraries.
Since Sigasi Studio 3.3, you will get a warning if your Common Libraries do not match the VHDL version of you VHDL file.
You can use the proposed quick fix to resolve the issue.
If you want to compile VHDL 87 code, you should select the “1993” option. There are no checks to warn about constructs that were not supported in 1987, but that were introduced in 1993.
Sigasi Studio does not send the Common Libraries to an external compiler. It is expected that these libraries are pre-compiled.
Colors and Fonts
You can configure the code coloring by selecting Window > Preferences > Sigasi > VHDL > Syntax Coloring.
For each class of semantic and syntactic elements, you can select the font, letter color, background color, style (bold, italic, underline, strike through).
Font size
Sometimes you want extra small fonts, so that you can fit more content on your screen. Another time you
may want extra large fonts, so that you can use a beamer and your audience can see what you are doing.
Most fonts, including the font that is used by the editors, can be controlled in the preferences:
Window > Preferences. Fonts are controlled in General > Appearance >Colors and Fonts. The font of the editors are in Basic > Text font.
Some fonts cannot be controlled in this preference page. These fonts are defined by general system settings, and are used for writing the menu names, the Project Explorer View and the Outline and Hierarchy Views. On
Windows, you can change these fonts by changing your font settings in the Windows Control Panel. On Linux, these fonts are controlled by a settings file: ${HOME}/.gtkrc-2.0 . You can change the font by adding
a line like:
gtk-font-name = "Sans 10"
You have to restart Sigasi Studio before these changes take effect.
Annotations Colors
Annotations are colors added on top of your text editor, and to the right of your text editor, in the scroll bar. The image below shows annotations for each occurrence of a certain data type. The color has
been changed to bright green.
You can change the color of annotations in Window > Preferences > General > Editors > Text Editors > Annotations.
For the particular case of occurrence annotations, you want to modify the color for annotation type Occurrences.
If more than one Occurrences type is displayed, you need the org.eclipse.xtext.ui.editor.defaultOccurrenceAnnotation.
The others may refer to occurrences for Java or other plug-ins.
Tabs and Spaces
If you want to use spaces instead of tabs, you can set your indentation preferences in: Window > Preferences > General > Editors > Text Editors. Here you can select choose to Insert Spaces for Tabs and choose your preferred Displayed Tab Width.
The “Gutter”
The Gutter is the small area to the left of the editor view. It is used for displaying extra information about your code.
Line numbers: What line is this?
Quick Diff: Did this file change?
Folding: hiding pieces of code from view
Markers: error markers, warnings and bookmarks.
There is not much to configure about markers, but the other categories can be turned on or off.
Line numbers
To enable line numbers, right-click in the gutter and select Show Line Numbers.
Quick Diff
Instead of using a compare editor, you can enable quick diff support and see the changes within the text editor. This feature can be enabled via Window > Preferences > General > Editors > Text Editors > Quick Diff.
When you enable Quick Diff, you can see changes in the active editor with the version on disk (or the latest version in version control), by hovering the annotations in the gutter.
You can choose the severity of linting rules in: Window > Preferences > Sigasi > VHDL > Errors/Warnings.
Read more information about Linting and Quick Fixes.
Language
Eclipse is available in several languages, and you can install the language pack of your choice. Read more in this support article : Installing translations for Eclipse
Keyboard shortcuts
Sigasi Studio comes with a large number of Keyboard Shortcuts preconfigured. You can configure keyboard shortcuts (key bindings) in Window > Preferences > General > Keys. You can modify individual keyboard shortcuts or add new key bindings.
There is also a preconfigured scheme for Emacs-like keyboard shortcuts.
After you have configured your keyboard shortcuts, you can export your settings and share them with your colleagues (or re-import them on another computer):
To export, go to File > Export… > General > Preferences, and select Key Preferences. To import that file: File > Import… > General > Preferences.
Sigasi Studio’s license key management system is based on the well known FlexNet (a.k.a. FlexLM) license manager.
Sigasi Studio supports both node-locked and floating license keys.
The Sigasi Studio edition is controlled by the license key.
Node locked licenses
If you have a node-locked license, you can enter your license key directly in Sigasi Studio.
Open the Sigasi Studio License Key preference page: Window > Preferences > Sigasi > License Key
Click Edit License File
paste your key in the dialog
An example node-locked license looks like this. Note that the first line starts with INCREMENT
Configuring Floating license in Sigasi Studio (FlexNet Client)
In order to use a floating license, Sigasi Studio needs to know how to contact the server.
The license server can be configured in Sigasi Studio or using an environment variable.
Configure the license server in Sigasi Studio
In Sigasi Studio, navigate to the License Key preference page via:
Window > Preferences > Sigasi > License Key.
Next enter <portnumber>@<servername> in the License key path. For example:
27000@myserver.example.com
If you have redundant license servers, enter each of the license servers separated using “,”.
It is recommended to specify the primary server first in the list.
For example:
If you have multiple, non-redundant license servers, the servers should be separated using “:” on Linux and using “;” on Windows.
If you leave the License key path empty, Sigasi Studio will try to use an environment variable
to find the license server.
Configure the license server in an environment variable
You can also set your license server via an environment variable instead of configuring it in Sigasi Studio.
Both SIGASI_LM_LICENSE_FILE and LM_LICENSE_FILE are supported.
When SIGASI_LM_LICENSE_FILE is set, LM_LICENSE_FILE is ignored.
Note that if you want to use an environment variable, you can not enter a path in the License Key preference page.
The value on the License Key preference page has priority over environment variables.
The version of the FlexNet daemons must be equal or higher than the FlexLM version of Sigasi Studio. The required version can be found in Sigasi Studio: Window > Preferences > Sigasi > License Key and look for the FLEXLM_VERSION line.
By default, Sigasi license files use ports 27000 and 27001 on your license server.
If these ports are already in use on the server, you can change the port numbers in the license file.
The port of the Sigasi daemon is set on the DAEMON line. For example: DAEMON sigasi port=27001, forces the Sigasi daemon to use port 27001.
The port of the FlexNet daemon is set on the SERVER line For example: SERVER your_server_name1 BD41FCF5DE27 27000, forces FlexNet to use port 27000. This is the port clients need to use to check out a license.
You can change the port numbers and your_server_name1 without breaking the signature.
If you have a firewall, remember to open these ports for access.
Starting the FlexNet and Sigasi daemon on Linux
the easiest way to start the Sigasi FlexNet daemon is like this (on Linux)
Create a folder to hold the license manager software, in this example we will use D:\Sigasi\license.
Unpack the zip file into the license folder (D:\Sigasi\license)
Run the license configuration tool lmtools.exe as administrator.
Save the license file supplied for Sigasi Studio to the license folder
Using a text editor, edit the license file and replace your_server_name1 with the name of the machine you are using, for example:
From: SERVER your_server_name1 74e50bb0911e
To: SERVER Maple 74e50bb0911e
Note: If you are not sure of the name of the machine you are using click on the System Settings tab of lmtools, where it is shown, see below:
Click on the Config Services tab and fill in the following, use the browse button when available:
Service Name: Sigasi License Manager
Path to lmgrd.exe: D:\sigasi\license\lmgrd.exe
Path to license file: D:\sigasi\license\sigasi.lic
Path to the debug log file: D:\sigasi\license\debug.logNote: You will probably need to type the “Path to the debug log file”, in full as the file will not exist so you cannot browse to it.
Ensure both the following check boxes are checked:
Use Services
Start Server at Power Up
Now click the Save Service button, and click yes on the confirmation dialog.
Switch to the Start/Stop/Reread tab and start the server.
The license server should now be configured correctly, and looks a bit like this one
Floating License options
Release a floating license
You can release a floating license (check a license in) without closing your Sigasi Studio application or Eclipse application. This is useful if you use Eclipse to edit other files than VHDL files, like C or Tcl.
First, make sure that all VHDL and Verilog files are closed and all VHDL and Verilog projects are closed. Next select Help > Sigasi > Floating license > Release Sigasi Floating Licenses
To get the license back (to check the license out), open the license dialog Help > Sigasi > Configure License… and press Apply.
How to block Sigasi Studio from checking out a license?
If you have configured an environment variable with the location of a FlexNet license server, you can instruct Sigasi Studio not to check out a license by setting the Sigasi Studio License key to none.
Checking out and releasing the XPRT license
If you have a license for Sigasi Studio XPRT
, this is actually licensed as a com.sigasi.hdt.xl FlexNet feature
combined with a com.sigasi.hdt.xl.doc FlexNet feature.
The XL license is checked out as described above.
The XPRT license is checked out automatically in the following cases:
When you open the Block Diagram view
When you open the State Machine view
When you open the Class Hierarchy view
When you open the VUnit view
When you export documentation
When you click Help > Sigasi > Floating License > Check out Sigasi Studio XPRT license
The XPRT license can be released via: Help > Sigasi > Floating license > Release Sigasi Studio XPRT Floating Licenses.
Troubleshooting
If your license key does not work, the first things to check are:
Which version of the Sigasi license daemon are you using? Note: The Sigasi 2 daemon needs to be updated to run Sigasi 3. Otherwise you will see an License is not valid (Internal Flexlm Error) error message in the Sigasi Studio preference page.
Is the MAC address correct?
Since Sigasi Studio 4.3, on Linux Sigasi Studio uses the ip command to list MAC addresses instead of the now deprecated ifconfig command. If you’re using a version of Sigasi Studio older than 4.3 on Linux, you might need to install additional packages to obtain the ifconfig command.
On Arch, Debian or Ubuntu Linux, the “net-tools” package is needed.
On (Open)Suse the “net-tools-deprecated” package is needed.
Has the license expired?
Did you copy the license string exactly as it was sent to you?
Did you accidentally try to use a License Token as a license key?
A License Token is a 24 character string. You can use your license token to Activate Your License Key.
If your floating license server does not function properly, try the following steps:
Start the FlexLM daemon with the -z option to see what is going wrong
You can check that the FlexNet daemon is running as expected by following these steps:
Download the daemon zip file on the client machine
Run lmutil[.exe] lmdiag -c "<port>@<server>" -n
If the server is running correctly, you should see a description of the valid FlexNet features served by you license server.
Make sure the server name in the license key file is correct.
Make sure both the Sigasi and FlexNet daemon are the same version (i.e. from the same zip-file from the Sigasi download server). If you need to mix versions, the FlexNet daemon version should be equal to or higher than the Sigasi daemon version.
Firewall problems:
make sure that the port for the Sigasi FlexLM license daemon is open
you can force the port for the Sigasi license daemon by adding USE_SERVER and DAEMON sigasi port=to your license key
On Linux you might have to install lsb to avoid No such file or directory errors when starting lmgrd or other flexlm tools:
sudo apt-get install lsb-core
zypper in lsb
yum install lsb
yum install redhat-lsb.i686
If the installation of lsb-core fails (e.g. on Debian Linux 10), try this workaround (as root):
cd /lib64
ln -s ld-linux-x86-64.so.2 ld-lsb-x86-64.so.3
The lmgrd license manager needs to have write access to the /usr/tmp/ path. If your system doesn’t have a directory /usr/tmp, you can make a link to /tmp (as root) :
ln -s /tmp /usr/tmp
You can not have spaces in the daemon path.
Some users reported that specifying an arbitrary absolute path for the Sigasi daemon on Windows (e.g. DAEMON sigasi C:\\sigasi.exe port=27021) does not work. It only works if the Sigasi daemon is in the C:\Sigasi folder.
Other users have reported that you are not allowed to have the directory name being the same as the daemon name. For example: c:\flexlm\sigasi\sigasi.exe is invalid, but c:\flexlm\vhdl_editor\sigasi.exe works fine.
Make sure the environment variable is correct: SIGASI_LM_LICENSE_FILE=<port number>@<servername>
Verify that your server meets the License Server System Requirements.
If you try to run the daemon on an unsupported version of Windows, you will typically see this error message: CreateProcess error code: 0xc1 File= sigasi.exe.
You can easily check the status of your license via the License Key preference page : Preferences > Sigasi > License Key. At the bottom of this preference page you can see the type and expiration date of your license.
If you are accessing your license server through an SSH tunnel, try using 127.0.0.1 instead of localhost.
Sigasi Studio pre-emptively tries to check out certain license features. As a result, you might see warning message like this in your server log. These messages can be safely ignored.
9:14:47 (sigasi) UNSUPPORTED: "com.sigasi.hdt.custom" (PORT_AT_HOST_PLUS ) testuser@testmachine (License server system does not support this feature. (-18,327:10054 ""))
9:14:47 (sigasi) UNSUPPORTED: "com.sigasi.hdt.preview" (PORT_AT_HOST_PLUS ) testuser@testmachine (License server system does not support this feature. (-18,327:10054 ""))
If the steps above do not help, feel free to send us an email
and send us a screenshot of the license dialog with the error message.
Typical error messages
Check the content of the Sigasi License preference page via : Window > Preferences and Sigasi > License Key
No license
Is a valid license key path configured (or are valid environment variables used)?
Is the user trying to use a Sigasi Studio 3 license in Sigasi 2.x?
Did you correct the server name to the actual server name in the (floating) license key file?
Internal Flexlm Error
Check version number of FlexNet daemon, it is probably outdated. If not, check the daemon log on the license server
Invalid Message Received From License Server
Check the daemon log on the license server
Updating DACL Failed: “Service has been created but failed to update the DACL settings of FlexNet Licensing Service. It will give problem for accessing TS features. Check whether FlexNet Licensing Service is correctly installed or not and delete and create this service again.”
There seems to be a bug in lmtools.exe version 11 on some systems. You can work around this issue by configuring the (latest) Sigasi daemon with an older version of lmtools (Download here).
(lmgrd) license manager: can’t initialize:No SERVER lines in license file.
(lmgrd) License Path: “C:\FlexLM\sigasi\license.dat”
(lmgrd) FlexNet Licensing error:-13,66
If you see this error message. Double check you license file contains line with USE_SERVER.
Talkback is a Sigasi Studio service that automatically collects metadata about how Sigasi Studio is used and sends this metadata to Sigasi through a secured connection.
Why should I enable Talkback?
By enabling Talkback you help us improve Sigasi Studio:
Talkback lets us determine which features are heavily used. This helps in planning which kind of features are valuable for you as Sigasi Studio user, so that we can adjust our product roadmap.
Talkback collects performance statistics, that we can relate to the project sizes. Together with our in-house performance tests, this helps us keep the Sigasi Studio compiler and user interface fast.
Talkback helps us reduce software errors by collecting incident reports from a wide range of use cases.
The activation of Talkback is required to enable our free educational and open source licenses.
Talkback is automatic and less cumbersome than feedback surveys.
The end result is that you can use an always-improving Sigasi Studio.
How does Sigasi use this information
Sigasi uses the information transmitted by Talkback for marketing and product planning and development. We use it for deciding which features to develop and improve, for finding and fixing bugs and for finding and fixing performance issues.
What kind of information is sent through Talkback?
Talkback transmits meta-information about your project, operating system, Java Virtual Machine, tool usage, build performance, system statistics, license type, and incident reports (stack traces) that occur due to software errors.
Talkback never transmits any HDL code. All transmissions are through an industry standard SSL secure connection.
In the Talkback transmissions, we identify your Sigasi/Eclipse workspace using a generated identifier (a standard Java universal unique identifier UUID).
Talkback stores all the information it transmits in a local log file, so that you can inspect it. The information is human-readable, in JSON (JavaScript Object Notation) format.
You can access the Talkback log to verify by clicking Window > Preferences > Sigasi > Talkback > Talkback log.
This log file is rotated for each new Sigasi Studio session or when the log reaches a certain size.
How do I enable or disable Talkback?
Talkback is always disabled by default. To enable Talkback, or to disable it later on, click Window > Preferences > Sigasi > Talkback and select or deselect the checkbox “Enable Talkback”.
What about my Firewall or Proxy?
Talkback uses the https protocol to send the information.
If your firewall blocks SSL connections Talkback will not be able to send diagnostics.
Your firewall should allow outgoing connections to https://talkback-sigasi.sigasi.com/.
Talkback does not support Proxies. If Talkback is unable to connect to our server directly because of your firewall or proxy server, you need to purchase a commercial license.
Features like Talkback are against our corporate policy, even if it is disabled. What can I do?
Please send us an email
so that we can discuss a solution for your company.
Although VHDL is not case-sensitive, it is recommended to always use the same capitalization when referring to the same declaration. Sigasi Studio warns when the capitalization of a reference differs from the capitalization of the declaration. Because external libraries can have different code styles, this linting only checks references in the same library as its declaration.
Capitalization can easily be fixed with a Quick Fix.
All capitalization issues in a file can be fixed in one click.
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
Sigasi Studio can check that the header comment matches a specified pattern. A header comment is a comment that starts at the first character of your file (no leading whitespace).
The check can be enabled in Preferences > Sigasi > VHDL > Naming conventions. The pattern can be set on the same page.
More information on file header comment checking is available here.
Since Sigasi Studio 4.4, the raw string of the header comment is checked to allow for maximum compliance checking.
This means that when a new line is matched, users should use \r?\n or the newly introduced \R to make sure the naming conventions work on all platforms.
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
Dead code is code that does not have any effect on your simulation or
synthesis. Examples of dead code are signals that are never used or
conditions that are never triggered.
Dead code does not bother the simulator or the synthesis tool. However,
it consumes mental energy of anybody reading the code. People will try
to figure out the purpose of a given statement and it may take a while
before they realize that they are dealing with dead code. This makes it
more expensive to review code and reuse code. In general, dead code
is a form of technical debt that should be avoided.
architecture RTL of empty is
signal unused_s : bit;
constant unused_c : bit := '0';
begin end;
a Quick Fix is available to help you remove unused declarations fast.
unused ports (rule 67) and generics (rule 68)
entity empty is
generic(unused_g : bit);
port (unused_p : in bit);
end entity;
architecture RTL of empty is begin end;
unreachable statements (rule 79): if the Sigasi Studio analyzer can determine that a condition is always false,
it will mark the if-statement because it contains dead code.
if true then
v := v + 1;
elsev := v - 1;
end if;
dead states in a state machine: a state is considered dead if it has no outgoing transitions (rule 71)
type t_state is (IDLE, START, RUN, DONE);
signal state: t_state;
-- [omitted code]
case state is
when IDLE => -- do something
state <= RUN;
when RUN => -- do something
state <= DONE;
when DONE => -- do something
state <= IDLE;
when others => -- do nothing
end case;
Project specific setting of these rules
These rules can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
Deprecated IEEE Packages and Non-Standard Packages
Some packages are widely spread but were never standardized by IEEE.
Different vendors have shipped different versions, with incompatible
implementations. These packages should not be used and are flagged as
Deprecated IEEE packages.
use ieee.std_logic_arith.all
use ieee.std_logic_signed.all
use ieee.std_logic_unsigned.all
Instead, use the standard ieee.numeric_std package.
use ieee.numeric_std.all
The package ieee.std_logic_misc has the same problem of not being standardized by IEEE. Contrary to the packages above, there is no consensus on how to replace this package. Sigasi Studio flags this package as Non-standard package.
Sigasi Studio can check that the filename contains the name of at least one of the design unit names inside that file. Note that this check is ignored by default. You can enable it in the VHDL Errors/Warnings preference page (Style Validation > Filename must contain primary name).
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
Sigasi Studio warns about port maps and generic maps that are incomplete: Port map uses default values. Missing optional actuals: yourport
Input ports and generics need to be assigned in your instantiation
statement if they don’t already have a default value. If you don’t do
this, you are writing illegal VHDL. Sigasi Studio will mark an error, and so
will all other tools.
Input ports and generics with a default value, as well as output ports,
do not need to be assigned explicitly. However, this is often not
intended. For that reason, Sigasi Studio can warn you about this.
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
Sigasi Studio can check for a number of array / vector index-related problems:
Index out of range (rule 210).
architecture RTL of array_range_check is
signal foo: bit_vector(7 downto 0);
signal bar, baz: bit;
begin
bar <= foo(8); -- 8 is out of range "7 downto 0"
baz <= foo(7);
end architecture RTL;
Slice has wrong direction (rule 211).
Slice ranges must use the same direction as the vector.
architecture RTL of array_range_check is
constant iterations : integer := 8;
signal foo: bit_vector(7 downto 0);
signal bar, baz: bit_vector(0 to 7);
begin
bar <= foo(0 to 7); -- foo has a downto range
baz <= foo;
end architecture RTL;
Project specific setting of these rules
These rules can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
On the Naming Conventions preference page (Window >
Preferences > Sigasi > VHDL|Verilog/SystemVerilog > Naming Conventions) you can configure
patterns to check the correct naming of your VHDL, Verilog, and SystemVerilog identifiers. Patterns are
configured using regex syntax.
The above defines the Naming Conventions for the entire workspace.
To specify Naming Conventions for a project instead of for the entire workspace, have a look at Naming Conventions per project.
Only names with a specified pattern are checked. Empty patterns are omitted.
Example: to enforce a style where all variables have a _v suffix,
you would specify .*_v pattern in the Variable name field.
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
92/severity/<project>=IGNORE
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
Sigasi Studio gives a warning when the order of generics or ports in a map differs from the original generics or ports declaration order.
architecture RTL of dut is
component my_comp port (
clk : in std_logic;
rst : in std_logic;
inp : in std_logic;
outp : out std_logic);
end component;
begin
assert iterations <= MAX_COUNT;
i_comp_1: my_comp port map( -- associations should be kept in the same order as the declaration
rst => rst,clk => clk,
inp => data_in(0),
outp => open
);
i_comp_1: my_comp port map(
clk => clk,rst => rst,
inp => data_in(0),
outp => open
);
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
Most VHDL designers prefer named associations in port and generic maps in instantiations. This makes it a lot easier to spot wrong connections.
By default, Sigasi Studio warns when positional associations are used. You can change the severity of this check via Preferences > Sigasi > VHDL > Errors/Warnings in the Instantiation statement validation section.
architecture RTL of dut is
component my_comp port (
clk : in std_logic;
rst : in std_logic;
inp : in std_logic;
outp : out std_logic);
end component;
begin
i_comp_1: my_comp port map( -- positional associations not recommended
clk,rst,data_in(0),open
);
i_comp_2: my_comp port map( -- named associations recommended
clk => clk,rst => rst,inp => data_in(0),outp => open
);
end architecture RTL;
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
If you are using vendor libraries from Intel or AMD/Xilinx (ISE or Vivado),
you do not need to set up these libraries by hand. Sigasi Studio has a Quick Fix
to do this for you.
The missing library will be added to the Common Libraries of your project.
The library statement that tries to import a missing library (like
altera) will have a yellow warning marker next to it. Click this
marker and select Configure library altera (Altera). If the path to your
Intel Quartus (or AMD/Xilinx ISE or Vivado) installation is not yet set, Sigasi Studio will
ask to set the path now. You can always change these paths in Window
> Preferences > Sigasi > Toolchains.
Note that for the AMD/Xilinx libraries we only map the packages with the
component declarations. By default, all entity and architecture
declarations are not mapped (excluded). This significantly reduces the
time for a clean build. If you use direct entity instantiations, you can
easily map the entities you need.
See also Choose your version of the Vivado unisim.VCOMPONENTS package.
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
If a case statement contains all the possible choices (usually in an
enumerated datatype), you can safely remove the when others clause.
Sigasi Studio warns about this:
Case statement contains all choices explicitly. You can safely remove
the redundant others.
case bits is
when "00" => -- code
when "01" => -- code
when "10" => -- code
when "11" => -- code
when others => -- never reached: all cases are covered
end case;
There is some debate on this coding rule. However, the vast majority of
synthesis tools do not take the others into account if all choices are
enumerated. If the synthesis tool is set up to generate fault-tolerant
hardware, the fallback state is the same as the reset state (for most
synthesis tools). Check the manual of your synthesis tools and run some
experiments.
For more information, see VHDL case statements can do without the “others”.
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
VHDL requires a sensitivity list for each process or wait statements in the process body.
Sigasi Studio can warn about problems with your sensitivity list:
Presence of either a sensitivity list or one or more wait statements in a process (rule 38)
Incomplete sensitivity list (rule 72) (there is Quick Fix for this)
process(a)
begin
c <= a and b;
end process;
Superfluous signals in sensitivity list (rule 73)
process(a, b, c)
begin
c <= a and b;
end process;
Duplicate signals in sensitivity list (rule 85)
process(a, b, b)
begin
c <= a and b;
end process;
A sensitivity list should contain all signals that are read
asynchronously in the process. For a combinatorial process, all
signals read by the process should be in the sensitivity list. For a
synchronous or clocked process, only the clock signal and an
asynchronous reset signal (if present) should be in the sensitivity
list. In synthesizable code, an incomplete sensitivity list will
likely cause a synthesis-simulation mismatch. Even in test benches and
purely behavioral code, an incomplete sensitivity list is often
unintended and may lead to an unexpected simulation result. Most
synthesis tools ignore the sensitivity list. In traditional workflows,
only the synthesis warnings will give you a hint that your sensitivity
list is incomplete. This report will be available only hours or even
days after you have finished typing your code. Flagging this problem
early can save a lot of time.
Since VHDL-2008, you can write process (all) to make sure you have
all the necessary signals in the sensitivity list.
process(a, b)
begin
c <= a and b;
end process;
process(clk)
begin
if rising_edge(clk) then
-- code
end if;
end process;
process(clk, rst)
begin
if rst = '1' then
-- reset code
elsif rising_edge(clk) then
-- code
end if;
end process;
process(all)
begin
c <= a and b;
end process;
Project specific setting of these rules
These rules can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
If you type a numeric literal with a physical unit, there should be a
space between the number and the unit.
T := 25ns; -- ILLEGAL, but accepted by ModelSim
T := 25 ns; -- OK; according to VHDL language standard
Mentor Graphics’ ModelSim and QuestaSim accept the former (illegal)
version. As a result, some VHDL designers got used to writing the
incorrect version, producing code that is not portable to other
simulators. Sigasi Studio accepts the ModelSim-style physical literals
but warns about this.
Every design unit except package STANDARD is assumed to contain the following implicit context items as part of its context clause:
librarySTD,WORK;useSTD.STANDARD.all;
Hence, any extra library statement in your VHDL code that includes
STD or WORK is pointless, as is any use clause that includes
std.standard.all. Hardly anybody would type the use clause, but
quite some people start all of their files with two extra library
clauses.
It is good practice not to include use clauses for libraries STD and WORK. Sigasi Studio flags as warning if they appear.
library IEEE, STD, WORK;
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
When using booleans, it is unnecessary to test whether they’re equal to true (rule 185) or false (rule 186). Simply testing the boolean results in cleaner code.
signal valid: boolean;
-- some code omitted
if valid then
-- ...
end if;
if valid = true then
-- ...
end if;
if not valid then
-- ...
end if;
if valid = false then
-- ...
end if;
if valid /= true then
-- ...
end if;
Note that the equals-false rule (186) is disabled (set to IGNORE) by default.
Project specific setting of these rules
These rules can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
Sigasi Studio flags an error if a type is used in an expression.
architecture RTL of type_in_expr is
type t_foo is (one, two);
begin
p : process is
begin
case t_foo is -- a type cannot be used in an expression e.g. a case expression
when one =>
end case;
end process p;
end architecture RTL;
architecture RTL of type_in_expr is
type t_foo is (one, two);
signal s_foo: t_foo;
begin
p : process is
begin
case s_foo is -- use a signal or variable of the required type in expressions
when one =>
end case;
end process p;
end architecture RTL;
Sigasi Studio checks the vector size in assignments and port maps. This check works at type-time and takes the (symbolic) value of generics into account.
Sigasi Studio will not take into account the value assigned to a generic in instantiations. The reasoning behind this is explained here.
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
In Verilog, it is possible to reference identifiers from different files. However, if multiple files are declaring the same identifier there is no way to know which one should be used. Such cases will be marked as ambiguous references.
A possible reason you might be seeing these errors is that your project defines multiple top levels that have been mapped to the same library. More information about library mappings can be found here.
Sigasi Studio has several checks on Verilog assignment patterns.
Default member must be last
Concrete assignments must precede more general assignments. Otherwise, some of those assignments might be ignored (rule 28).
In particular:
for arrays, default must be at the end of the list
for structures, default must be at the end, but type-default must be after the particular member assignments
module badcode;
int a[3:0] = '{0: 5, default: 0, 3: 1};
typedef struct {
int x;
int y;
real radius;
} circle_t;
circle_t b = '{default: 0, x:1};
circle_t c = '{default: 0, real: 0.0};
endmodule
module goodcode;
int a[3:0] = '{0: 5, 3: 1, default: 0};
typedef struct {
int x;
int y;
real radius;
} circle_t;
circle_t b = '{x:1, default: 0};
circle_t c = '{real: 0.0, default: 0};
endmodule
Only one default member expression is allowed
Sigasi Studio flags an error when expressions have multiple default assignments (rule 29). In particular:
arrays cannot have multiple default assignments
structures cannot have multiple default assignments or multiple type-default assignments
module badcode;
int a[3:0] = '{default: 1, 0: 2, default: 3}; // multiple default assignments
typedef struct {
int x;
int y;
real radius;
} circle_t;
circle_t b = '{default: 0, radius: 1.0, default: 0}; // multiple default assignments
circle_t c = '{int: 0, radius: 1.0, int: 0}; // multiple *type*-default assignments
endmodule
module goodcode;
int a[3:0] = '{0: 2, default: 3};
typedef struct {
int x;
int y;
real radius;
} circle_t;
circle_t b = '{radius: 1.0, default: 0};
circle_t c = '{radius: 1.0, int: 0};
endmodule
Overwritten type key in assignment pattern
Sigasi Studio flags a warning for duplicate type member keys in assignment patterns (rule 30). This is not an error according to the language reference manual,
but the last used type key overwrites previously matched members, making the code confusing and hard to maintain.
module uglycode;
struct { int x, y; } a = '{int: 0, int: 1};
int b[10] = '{int: 0, int: 1};
endmodule
module goodcode;
struct { int x, y; } a = '{int: 1};
int b[10] = '{int: 1};
endmodule
Duplicate member key in structure assignment pattern
Sigasi Studio flags an error for duplicate members/index keys in assignment patterns (rule 31). Each member/index key can occur only once.
module badcode;
struct { int x, y; } a = '{x: 0, y: 0, x: 0};
int b[10] = '{5: 1, 5: 2, default: 0};
endmodule
module goodcode;
struct { int x, y; } a = '{x: 0, y: 0};
int b[10] = '{5: 1, default:0};
endmodule
Mixed named and ordered notation in assignment pattern
Sigasi Studio flags an error when an assignment contains a mix of ordered and named elements (rule 32).
module badcode;
// Mix of ordered and named associations: not correct
struct { int x, y; } a = '{0, y: 1};
int b[4] = '{0, 1, 2:5, 3:7};
endmodule
module ok_code;
// Place binding: correct but may be harder to read, particularly with many elements
struct { int x, y; } a = '{0, 1};
int b[4] = '{0, 1, 5, 7};
endmodule
module goodcode;
// Name binding: esay to understand and maintain
struct { int x, y; } a = '{x: 0, y: 1};
int b[4] = '{0: 0, 1: 1, 2: 5, 3: 7};
endmodule
Project specific setting of these rules
These rules can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
Sigasi Studio has a number of checks on Verilog case statements.
Case statement does not cover all cases
A case statement should cover all options, either enumerating all options explicitly or with a default
clause (rule 8). This rule is checked for enum types only, not for scalar or vector types.
module badcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state) // Error: case `INIT` is missing
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
endcase
end
endmodule
module bettercode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
INIT : state = IDLE ;
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
endcase
end
endmodule
Default clause has to be the last item in a case statement
The default clause should be at the end after all the other options (rule 15). Sigasi Studio flags a warning if that is not the case.
module badcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
IDLE : state = START;
START : state = READY;
default : state = IDLE ; // The `default` clause must be at the end
READY : state = IDLE ;
endcase
end
endmodule
module goodcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
default : state = IDLE ;
endcase
end
endmodule
This rule also applies to generate case statements, e.g.
module bad_example#(parameter WIDTH=8);
generate
case (WIDTH)
default: // The `default` clause must be at the end begin // others - carry look-ahead adder
adder_cla #(WIDTH) x3(co, sum, a, b, ci); end
1: begin // 1-bit adder implementation
adder_1bit x1(co, sum, a, b, ci);
end
// other cases
endcase
endgenerate
endmodule
Case statement can only have one default clause
A case statement can only have one default clause (rule 16). A warning is flagged if more than one default clause is present.
module badcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
default : state = IDLE ; // Error: two `default` clauses
default : state = START;
endcase
end
endmodule
module goodcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
default : state = IDLE ;
endcase
end
endmodule
This rule also applies to generate case statements, e.g.
module bad_example#(parameter WIDTH=8);
generate
case (WIDTH)
default: // Error: two `default` clauses begin // others - carry look-ahead adder
adder_cla #(WIDTH) x3(co, sum, a, b, ci); end
1: begin // 1-bit adder implementation
adder_1bit x1(co, sum, a, b, ci);
end
// other cases
default: // Error: two `default` clauses begin // others - carry look-ahead adder
adder_cla #(WIDTH) x3(co, sum, a, b, ci); end
endcase
endgenerate
endmodule
Default clause missing from case statement
Sigasi Studio flags a warning for case statements without a default clause (rule 40). While a case statement without a default branch is syntactically correct, many guidelines recommend attaching a default branch, even if the case statement is completely defined. This ensures no latch would be inferred during synthesis if the case is incomplete (sometimes difficult to judge, esp with casex/casez semantics or larger widths).
module rather_ok_code(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
INIT : state = IDLE ;
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
// no default branch
endcase
end
endmodule
module goodcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
INIT : state = IDLE ;
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
default : state = IDLE ;
endcase
end
endmodule
Project specific setting of these rules
These rules can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
Initializing registers at the point of declaration may be tricky. If your (System)Verilog code is not going
to be synthesized (e.g. testbench), it is completely acceptable. FPGA synthesis tools may also take initialization
into account, so depending on your FPGA project, initializing registers when they are declared in the code may be
a viable (or even preferred) option.
ASIC synthesis tools however will ignore initialization as in the first example, which may lead to a mismatch between
synthesis and simulation. In such a case, initialization should be done using resets, as in the second example.
By default, Sigasi Studio flags a warning for register initialization at the point of the declaration. For FPGA projects
it may be desirable to turn the warning off, whereas for ASIC projects one may want to raise the severity to error.
module fpga_only(input clk, input rst, input ii, output logic oo = 1'b0);
logic sig = 1'b0;
// ...
endmodule
module asic_fpga(input clk, input rst, input ii, output logic oo);
logic sig;
always @(posedge clk) begin
if (rst == 1) beginsig = 1'b0;oo = 1'b0;end
else begin
// ...
end
end
endmodule
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
In Verilog class methods and class properties can be declared as local or protected to restrict their access. Sigasi Studio will flag attempted accesses that violate these restrictions as errors.
Local
local methods and properties can only be accessed from within the class itself.
class my_class;
local int secret = 42;
function int get_secret();
return secret;
endfunction
endclass
module bad_code;
my_class inst = new();
int x = inst.secret;
endmodule
Protected
protected methods and properties can only be accessed from within the class itself, or from any of its subclasses.
class my_class;
protected int secret = 42;
endclass
class my_sub_class extends my_class;
function int get_secret();
return secret;
endfunction
endclass
module bad_code;
my_sub_class inst = new();
int x = inst.secret;
endmodule
Sigasi Studio has a number of checks on Verilog and SystemVerilog coding style.
Empty loops and conditional branches
While occasionally intended, this construction is confusing, and often
the result of a typo. Sigasi will flag a warning if an empty block is
found (rule 1). In RTL code for synthesis, empty conditional branches
in sequential code can cause unwanted latch generation. There may
be a couple of reasons why an empty block is present in your code:
It is an unintentional omission and should be fixed to prevent unexpected behavior.
Some functionality is not yet, or never will be, supported. In this case, a $fatal (or similar) system task should be called.
It is intentionally blank. In this case, a comment should clarify the reason why.
File name does not match design unit
It is recommended that the base name of the filename is the same as the name of the design unit (e.g. module) in the file (rule 17). Sigasi Studio flags a warning if that is not the case.
E.g. module my_module should be in a file named my_module.v or my_module.sv .
In a file with multiple design units (which is not recommended), this rule is not active.
File contains multiple design unit
It is recommended that a Verilog file contains only one design unit (rule 18). Sigasi Studio flags a warning if that is not the case.
Verilog code line too long
For legibility, it is recommended to keep lines of code short (rule 20). Sigasi Studio flags a warning if a code line is longer
than a certain length. The maximum length is set to 120 characters by default, but this can be changed in the
project linting settings (${project_location}/.settings/com.sigasi.hdt.verilog.linting.prefs). E.g.:
20/params/max_line_length/<project>=123
Tabs are not allowed
While this may potentially be controversial, TABs are forbidden in the majority of coding standards in the HDL domain with the motivation
of code not looking the same regardless of the editor/settings used. This check is off by default but it can be enabled in
the workspace or project linting settings (rule 21).
File header comment does not match required pattern
Many coding standards require the presence of a header comment in every file, matching a certain format. Sigasi Studio can check whether the file
header comment matches a pattern (rule 22). By default, the pattern is empty which disables this check.
The pattern can be configured through Window > Preferences > Sigasi > (System)Verilog > Naming conventions > File header and uses
the regex syntax.
More information on file header comment checking is available here.
Report encrypted regions
Starting with Verilog 2005, regions of Verilog and SystemVerilog files
may be encrypted to protect intellectual property. Sigasi obviously
won’t check the content of these regions. Optionally, Sigasi can flag
the presence of encrypted regions in your code (rule 44). This rule is
off by default (i.e. set to IGNORE) but can be enabled (as info,
warning, or error) as required.
Multiple statements per line
For readability, each statement should be on a separate line. Sigasi
Studio will flag a warning if a line of code contains multiple
statements (rule 47).
module rule47;
reg A, B, C, D, K, M;
reg EN;
assign A = B & C, D = K & M; // multiple statements in one line: less readable
assign A = B & C; // one statement per line: more readable
assign D = K & M;
always@(*)
if(EN==1'b1) begin
A = B & C; D = K & M; // multiple statements in one line: less readable
A = B & C; // one statement per line: more readable
D = K & M;
end
endmodule
Trailing comma is not recommended
Sigasi Studio will flag a warning if a parameter list has a trailing comma (rule 52).
Most EDA tools will treat a trailing comma as a syntax error.
Naming conventions in Sigasi
use RE2/J regular expressions.
RE2/J expressions mitigate potential performance problems that are
caused by some shapes of regular expressions using the regular Java
regular expression engine. Sigasi will warn if a naming convention
rule contains a regular expression that is incompatible with RE2/J
(rule 58).
Project specific setting of these rules
These rules can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
In Verilog, you are not allowed to declare the same identifier multiple times within the same scope. All duplicate declarations will be marked as errors.
module bad_code;
parameter p = 0;
parameter p = 1;
endmodule
parameter p = 0;
module good_code;
parameter p = 1;
endmodule
Non-blocking assignments are not allowed in functions
A non-blocking assignment (<=) is not allowed in a (System)Verilog function.
While syntactically correct, it will generally not lead to the desired behavior, and will likely cause synthesis-simulation mismatch.
Sigasi Studio flags an error if a blocking assignment is used in a function (rule 41).
A good fix to correct the problem is to replace non-blocking assignments (<=) with blocking assignments (=)
module badcode;
function plus_one;
input integer a;
begin
plus_one <= a + 1; // Incorrect: non-blocking assignment
end
endfunction
endmodule
module goodcode;
function plus_one;
input integer a;
begin
plus_one = a + 1; // Correct: blocking assignment
end
endfunction
endmodule
Function prototype has implicit return type
SystemVerilog function prototypes (pure virtual functions) should have a return type. Sigasi Studio flags a warning for function prototypes without return type (rule 10).
virtual class badclass;
pure virtual function myfunc(input bit[31:0] data); // return type missing
endclass
virtual class goodclass;
pure virtual function integer myfunc(input bit[31:0] data);
endclass
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
Although the input direction is taken by default, it is preferable to explicitly specify the direction to improve readability and make the code self-documenting.
module bad_example;
function int my_func(int a, b); // bad: direction of a and b omitted
return a+b;
endfunction
task my_task(int a, b); // bad: direction of a and b omitted
begin
$display(a);
$display(b);
end
endtask
endmodule
module good_example;
function int my_func(input int a, b); // good: direction of a and b specified
return a+b;
endfunction
task my_task(input int a, b); // good: direction of a and b specified
begin
$display(a);
$display(b);
end
endtask
endmodule
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
When choosing entity and port names in VHDL, it is recommended not to use (System)Verilog keywords.
This will prevent problems if the VHDL entity ever has to be integrated into a mixed VHDL/Verilog project.
Sigasi Studio will warn if a (System)Verilog keyword is used as an entity name.
entity always is port( -- always is a Verilog keyword: not recommended!
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
An out-of-block method declaration signature should match its prototype declaration’s signature.
Sigasi Studio flags an error if the prototype and the implementation signatures have a:
different subroutine form (task or function)
different return type, if it is a function
different arity or any argument has a:
different name
different direction
mismatched type
If an argument default value is present in an out-of-block method declaration but is missing in the prototype, or default values are not syntactically identical, a warning message is reported (rules 77, 78).
Errors are also reported for a missing prototype for out-of-bound definitions and missing or duplicated definitions for an extern method prototype.
class C;
extern task proto_only(); // missing definition
extern task who_am_i();
extern function bit bad(input int a, b, c, d, e = 2 + 3);
extern function int good(input int a, output string b);
endclass
function C::who_am_i(); // should be a task
// ...
endfunction
function C::no_proto(); // missing prototype
// ...
endfunction
function logic C::bad( // should return bit
output int a, // should be input
input integer b, // should be int
input int si, // should be 'c'
input int d = 4, // should have no default value
input int e = 5 // should be same value as prototype: 2 + 3
);
// ...
endfunction
function bit C::bad(ref x, y); // completely different signature, duplicate definition
// ...
endfunction
function int C::good(input int a, output string b);
// ...
endfunction
Project specific setting of these rules
These rules can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
A virtual method signature should match the overridden method signature in the superclass.
Sigasi Studio flags an error if the signatures have a:
different subroutine form (task or function)
different return type, if it’s a function
different arity or any argument with a:
different name
different direction
mismatched type
If an argument default value is present in one method and is missing in the other one, an info message is reported (rule 67).
interface class A;
pure virtual task who_am_i();
pure virtual function bit bad(input int a, b, c, d);
pure virtual task too_bad(input int a, b, c, d);
pure virtual function A good(input int a, output string b);
endclass
class B implements A;
virtual function who_am_i(); // should be a task
// ...
endfunction
virtual function logic bad( // should return bit
output int a, // should be input
input integer b, // should be int
input int si, // should be 'c'
input int d = 4 // should have no default value
);
// ...
endfunction
virtual task too_bad(ref x, y); // completely different signature
// ...
endtask
virtual function B good(input int a, output string b);
// ...
endfunction
endclass
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
Sigasi Studio validates the use of parameters in (System)Verilog.
Parameters without a default value
Sigasi Studio flags a warning if a parameter is declared without a default value (rule 19). Syntactically this is allowed since the instantiating modules should provide the value to the instance parameter.
However, it is undesirable since it makes the definition dependent on a particular hierarchy and limits code reusability.
In addition, it is creating elaboration errors when attempting to use such modules as a top-level.
Sigasi Studio has several checks on Verilog port and parameter associations.
Named parameter and port connections have to be used for all instances with many parameters / ports
A long list of positional parameters or port connections is difficult to read and maintain. Therefore, Sigasi Studio warns if a
list of positional connections is longer than 3 items (rules 24 and 26). If the number of associations is larger than 3, named connections should be used.
module sub(input clk, arst, enable, data, output reg data_out);
always @(posedge clk or negedge arst)
if (~arst)
data_out <= 1'b0;
else if (enable)
data_out <= data;
endmodule
module badtop;
logic clk, arst, en, a, b;
sub sub_inst(clk, arst, en, a, b); // 5 ordered associations: difficult to read and maintain
endmodule
module goodtop;
logic clk, arst, en, a, b;
sub sub_instance (
.clk(clk),
.arst(arst),
.enable(enable),
.data(a),
.data_out(b)
);
endmodule
The maximum number of 3 items is a default value, it can be changed in the
project linting settings (${project_location}/.settings/com.sigasi.hdt.verilog.linting.prefs). E.g.:
Sigasi Studio flags an error when attempting to mix named and positional port or parameter associations (rule 25).
module sub#(PARAM_1=2, PARAM_2=3) ();
endmodule
module badtop;
// Syntax error: mix of named (`PARAM_1`) and positional (`3`) association
sub#(.PARAM_1(2), 3) sub_inst();
endmodule
module ok_top;
// All associations are positional: OK but harder to understand and maintain
sub#(2, 3) sub_inst();
endmodule
module goodtop;
// All associations are named: best practice
sub#(.PARAM_1(2), .PARAM_2(3)) sub_inst();
endmodule
Unresolved formal names
Sigasi Studio flags an error for named port and parameter connections if the instantiated module doesn’t have ports with these names.
Sigasi Studio flags an error for duplicate named port and parameter connections (rule 37).
module sub#(WIDTH=8) (input[WIDTH-1:0] i1=1'b0, i2, output[WIDTH-1:0] o1);
endmodule
module badtop;
logic a, b, c;
// parameter `WIDTH` and port `i1` are connected twice
sub#(.WIDTH(4), .WIDTH(6)) sub_inst(
.i1(a),
.i1(b),
.o1(c)
);
endmodule
module goodtop;
logic a, b, c;
// parameter `WIDTH` and port `i1` are connected once
sub#(.WIDTH(4)) sub_inst(
.i1(a),
.o1(c)
);
endmodule
Missing actuals for formals that have no default value
Sigasi Studio flags a warning for missing port or parameter connections if the ports or parameters don’t have a default value (rule 38).
module sub
#(LHS, RHS=0)
(input[LHS:RHS] i1=1'b0, i2, output[LHS:RHS] o1);
endmodule
module badtop;
logic[7:0] x;
// parameter `LHS` and port `i2` don't have a default value so they must be connected
sub sub_inst(.o1(x));
endmodule
module goodtop;
logic[7:0] x;
wire[7:0] y;
sub#(.LHS(7)) sub_inst(
.i2(y),
.o1(x)
);
endmodule
Excessive number of actuals in ordered notation
Sigasi Studio flags an error if the number of positional parameters or port connections is larger than the number of parameters or ports of the instantiated module (rule 39).
module sub#(WIDTH=8) (input[WIDTH-1:0] i1=1'b0, i2, output[WIDTH-1:0] o1);
endmodule
module badtop;
logic a, b, c, d;
// Expecting 1 parameter connection and 3 port connections instead of 2 and 4
sub#(4, 6) sub_inst(a, b, c, d);
endmodule
module goodtop;
logic a, b, c;
sub#(4) sub_inst(a, b, c);
endmodule
Note that if there are too few positional parameters or port connections, an error for missing connections will be flagged.
Named connections are not allowed with blank ports
If an instantiated module contains a null port, the instantiation must use port association by order and not by name (rule 56).
module sub(
input clk,
, // this is a *null port*
input rst
);
endmodule
module badtop;
sub sub_instance(
.clk(clk),
.rst(rst)
);
endmodule
module goodtop1;
sub sub_instance(
,clk,rst
);
endmodule
module goodtop2;
sub sub_instance(
clk,foo,rst
);
endmodule
Project specific setting of these rules
These rules can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
(System)Verilog always constructs without an event control statement at the top cannot be synthesized.
Additionally, they would activate in random order at the moment 0 at beginning of a simulation.
Sigasi Studio flags a warning for always blocks without an event control statement at the start.
A good way to correct this description is to place the timing control statement at the top.
module test(clk, data_in, data_out);
input clk;
input[3:0] data_in;
output reg[3:0] data_out;
always
begin
data_out <= data_in;
@(posedge clk); // Timing control not at the top of 'always'
end
endmodule
module test(clk, data_in, data_out);
input clk;
input[3:0] data_in;
output reg[3:0] data_out;
always @(posedge clk)
data_out <= data_in;
endmodule
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs:
Sigasi Studio has a number of checks on VHDL coding style.
Extended identifier contains whitespace
Sigasi Studio flags an info message when using extended identifiers
which contain whitespace (rule 228). Particularly in mixed-language
designs, these identifiers may cause problems in
Verilog and SystemVerilog as they use whitespace to mark the end of
an extended identifier.
signal \foo bar\ : std_logic -- identifier with spaces: not recommended!
Project specific setting of this rule
This rule can be disabled for your project, or its severity can be modified in the project linting settings.
Manual configuration in ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs:
Sigasi Studio flags an error if a mismatch exists between the selected
VHDL language versions of a project, VHDL common libraries,
and individual design files.
Applying the associated quick fix will upgrade the version of the project,
or - if it’s already set up correctly - it’ll upgrade the version of the file with the outdated version.
The Common Libraries will automatically be updated to the upgraded version.
In Sigasi Studio, you can set the version of the VHDL
language for
your project and individual files. The setting for individual
files is only intended for compatibility with legacy code. Setting a
higher VHDL version on a design file than the VHDL version of the
project is not supported and will cause this error to appear.
[Back to top]
This single page manual was generated on 2023-05-26.
This website uses cookies. By continuing to use this
site you are giving consent to cookies being used.
Accept & close
-icon in the status bar
at the bottom of the screen.
next the perspective icon. A window pops up in which you can select the perspective.
, the Project Explorer
will be linked to the Editor view. Now, the active file in the editor
view will always be selected in the Project Explorer.
and then
Customize view. You can then select a filter whose matching files
will be hidden in the view. For example, you can filter out all non-VHDL
or non-Verilog files.
in the top right corner of the project icon.
while files/folders with warnings are marked with a yellow triangle with black exclamation mark 
.
in the upper left corner.
.
.
Double-click in the Outline View to navigate to the corresponding
location in the editor.
.
to hide everything except instantiations and structural statements.
button if you first set up a Launch simulator.
button. Both SVG and PNG are supported. Choose a *.svg filename for SVG export or a *.png filename for PNG export.
button, you can toggle the display of comments on edge labels.
button, you can toggle the display of comments on edge labels. These labels show the code comments of the transition statements.
show dependencies of the entire project. Uncheck to focus on the dependencies of the active editor only.
Group design files per library
Show design units inside design files. The design units are prefixed with an abbreviation of their kind (architecture, module, package, …" >}}
-icon.
in the toolbar.
and the Show Previous Match arrow 
in the search result view. Note that all occurrences are highlighted and marked with a small arrow at the left border of the editor for easy recognition.
in the toolbar.
Horizontal Split shows 2 viewports on top of each other.
Vertical Split shows 2 viewports next to each other.
marks an info message that can be resolved automatically with a Quick Fix.
marks an info message.
marks a warning that can be resolved automatically with a Quick Fix.
marks an error that can be resolved automatically with a Quick Fix.
.
icon.
.
.
, on the right side of the status bar.
