If you happen to have a license of SVH Enterprise Edition, or like me, have a trial license, you also can use the CLI features of SVH.
A few things on the CLI. As of the 2025.3 release, the CLI is part of the VSCode extension, but by default, it ends up in a bit unconvenient location :
/.config/Code/User/globalStorage/sigasi.sigasi-visual-hdl/cli/sigasi-cli
for me. You will need to add that to your path (or better, symlink it in $HOME/bin. I prefer a manual CLI installation.
On a build agent, you will need the separate installation anyway, else it will require a headless VSCode installation, and that is way harder then a download + unzip of the sigasi-cli installation.
The separate download is available here. To install it, unzip it into a location of preference, and make sure the directory is in your PATH variable, so calling sigasi-cli actually works.
The CLI is a licensed feature, so you need to set SIGASI_LM_LICENSE_FILE to the correct location of the license file, and make sure the user calling sigasi-cli has access to both the installed CLI, as well as the specified license file.
First, let me explain the value of the Sigasi CLI : it allows for automation of operations that are otherwise not easy to do outside of VSCode, and it can be used to safeguard project quality in your CICD pipeline.
If you are a software developer, the IDE and CICD pipeline safeguard certain aspects of your project. If you happen to code in Go for example, most IDE’s already call go fmt on your Go files.
If you use CICD and work with Go projects, you can use a pre-commit hook to automatically reject commits that contain unformatted code.
Why would you want that in the first place ? Well, different whitespace settings in IDE’s can cause very long diffs in version control. It takes focus away from engineers from things that really matter : Functional changes.
Lets give an example. First, a piece of (badly) formatted VHDL code
library IEEE;
use IEEE.std_logic_1164.all;
entity and_gate is port ( a : in std_logic; b : in std_logic; y : out std_logic); end entity and_gate;
architecture rtl of and_gate is begin y <= a and b; end architecture rtl;
As you can see, both the entity, as wel as the architecture declaration are one liners. Syntactically, it is correct, the parser will have no issue with it, and the resulting netlist will be a correct one.
Is it easy to read (image a 1000 line file) : Probably not, at least, not for me.
So, lets try to fix that :
sigasi-cli format --align --keywords=lowercase --spaces-for-tabs --vhdl-version 2008 bad_example.vhd --out=formatted.vhd
which will result in
library IEEE;
use IEEE.std_logic_1164.all;
entity and_gate is
port(a : in std_logic; b : in std_logic; y : out std_logic);
end entity and_gate;
architecture rtl of and_gate is
begin
y <= a and b;
end architecture rtl;
Unfortunately, the formatted lacks verilog support, as well as configuration options for the formatted. For verilog, there is verible-verilog-format which works well, as has configuration options for determining how it formats. Downside : Another tool to install in the CICD agent.
So, why does this matter ? If you are a lonely designer like I am, probably not. If you are part of a team, it matter a lot. Looking at the example above, both are valid VHDL files. If one developer uses one version, and another developer uses the other, and it ends up in version control, the diff will look like
--- bad.vhd 2025-10-11 18:55:41.282057461 +0100
+++ good.vhd 2025-10-11 18:55:47.554132357 +0100
@@ -1,6 +1,11 @@
library IEEE;
use IEEE.std_logic_1164.all;
-entity and_gate is port ( a : in std_logic; b : in std_logic; y : out std_logic); end entity and_gate;
+entity and_gate is
+ port(a : in std_logic; b : in std_logic; y : out std_logic);
+end entity and_gate;
-architecture rtl of and_gate is begin y <= a and b; end architecture rtl;
+architecture rtl of and_gate is
+begin
+ y <= a and b;
+end architecture rtl;
Are there ways to limit the impact of whitespace ? Sure. Do you want to use it : No. Desigers should focus on the design, not on how the code is formatted, or if code conventions are lived after. That is what we have IDE’s for.
Sigasi SVH has options to set requirements for a coding style to be used. Do you want all input ports to start with i_ ? You can configure that in SVH.
The same applies to many other options related to verilog / VHDL coding styles. You can flag violation of the requirements on info, warning and error level.
Setting the style validation option in a project level will result in a file being writtin in the .settings directory in the project. Those files can be added in version control.
Doing a sigasi-cli verify . from the CICD pipeline on the checked-out project will result in the validation being run, and that includes style validation.
Setting the input port pattern to ^xx_.* will, and using a name that doesn’t match will result in validation messages like below.
rtl/z80/z80_debug.v:10:16: WARNING: Naming convention violation: input port name should match pattern 'xx_.*'
In this case, its a warning, but you can also set it to ERROR level. Adding this to a pipeline is a next step in making checked in code comply to company guidelines, and reject code that fails to meet the guidelines.
If you have really big projects, this can help in maintaning a consistent style.
The above options provide some basic guidelines how to use the Sigasi CLI in your CICD pipeline. It can do all kinds of validation, based on settings that developers set in their IDE. Doing so helps to keep a project maintainable.
The tools is agnostic of the actual CICD pipeline used, but since its bound to a flexlm issued license, using a PaaS / SaaS hosted CICD solution will probably not work. Most solutions will allow to run your own agent, and that does allow to use licensed features.