Sigasi Visual HDL 2026.2

Sigasi Visual HDL™ (SVH™) 2026.2 features the new Modular projects, Vivado & VUnit import, AI integration (MCP), a rewritten AI-ready CLI bringing more consistency, greatly enhanced state machine condition visualization, improved dependency analysis, External Compilers and Compilation Recipe for Classic projects, and additional refinements to the manual.

TL;DR

This release brings together various large features that were developed throughout the year, making it especially bountiful. It focuses on agentic AI integration and integration with third-party tools.

A year in the making, the Modular Project format is now available to all. Built around modularity, it lets teams reuse IP effortlessly and integrate with existing workflows. Teams can reuse existing build scripts (Makefiles, Bazel, etc.), import—and keep in sync—projects from existing toolchains such as VCS, Questa, and Vivado, and seamless integration of functional safety standards or custom rulesets via settings sharing. Modular Projects are recommended for AI-assisted and future-oriented workflows.

Through the all-new Sigasi MCP server you can feed your AI with deterministic information to enhance its probabilistic reasoning and output.

The rewritten AI-ready Sigasi CLI unlocks Compilation Recipe generation for both Classic and Modular projects. Additionally, the CLI is now available as a daemon, speeding up subsequent requests, especially useful for AI agents and CI/CD.

A long-awaited improvement to the Statemachines Diagram: all conditions and their relation to one another are now shown. Transitions are automatically simplified and composed.

Improved dependency analysis enhances the generated compilation orders and recipes, improves integration with external compilers, and optimizes the foundation of Sigasi. Additionally, you can now introspect compilation, elaboration, and preprocessor dependencies.

External Compilers and the Compilation Recipe are now available for Classic Projects (the main project format used until Sigasi 2026.2, also known as Eclipse-compatible projects, and characterized by a .project file). Have you been waiting for this feature from the legacy Eclipse product? Then now is the best time to transition from Eclipse to VS Code and enjoy all new features and enhancements!

We greatly enhanced the product manual’s search, mobile experience, and visualizations all over.

As a cherry on top, this release includes over 50 bug fixes and miscellaneous improvements.

Modular Projects

You might have seen us writing about Sigasi Projects for the past few releases… wait no longer. These powerful new projects are now available to everyone under the name Modular Projects. Modular Projects are recommended for AI-assisted and future-oriented workflows.

Modular Projects feature:

• clean directory structure using only a .sigasi folder and, optionally, a project.sigasi file in the root of your project
• reuse of your existing build scripts (Makefiles, Bazel, etc.) and project definitions (Vivado, VUnit, etc.) and integration with existing toolchains (VCS, Questa, etc.),
• extensive reuse of IP through a more comprehensive dependencies architecture,
• seamless integration of functional safety standard rulesets (DO-254 and STARC),
• settings sharing among teams and within a company.

Classic Projects, formerly Eclipse-compatible projects, were the only project format available until Sigasi 2026.2. They’re characterized by a .project and .library_mapping.xml file and a .settings folder. As Classic Projects remain supported, you do not have to migrate from existing Classic Projects. However, because of their historical baggage, Classic Projects cannot support newer features such as scripted targets and settings sharing.

Want to try them out but do not know how? Or did you try them and bump into issues?
Learn more about migrating to Modular Projects

Fundamentals

Modular Projects work with the concept of targets. We distinguish between manual targets and scripted targets. Scripted targets are completely new and allow you to reuse existing build scripts and toolchains. Both unlock the new settings sharing and Functional Safety mechanisms.

Manual targets fulfill the same role as the Classic Projects you are probably used to. You can manually configure library mapping, include directories, and set language versions. However, using manual targets, you can configure different views on the same, or another, project. For example, one could have one target per toolchain or a target for RTL and one for verification where the RTL target does not require UVM, but the verification target does.

Learn more

Clean directory structure

When using Modular Projects, you will notice that there is now a project.sigasi file and a .sigasi folder instead of the .project and .library_mapping.xml files and the .settings folder. The project.sigasi can also be dragged into the .sigasi folder if you prefer. This file and folder should be checked in to your version control, but exclude .sigasi/generated. The project.sigasi is a combination of the .project and library_mapping.xml files. The .settings folder is replaced by the .sigasi/settings.json file.

Unless you heavily use extensive settings sharing, you do not have to touch any of these files manually. The entire project can be configured via the UI.

Reuse existing build scripts and toolchains

Through the use of scripted targets, you can specify the shell commands of your build workflow such as make, vcs, questa, and bazel. In the background, Sigasi captures the calls to the compiler, allowing it to build a comprehensive view of your project and its full configuration. You specify the command once, and Sigasi stays in sync forever.

Similarly, you can execute your own TCL scripts, but Sigasi comes with two very useful built-in scripts already: import_vivado and import_vunit. As you might guess, these let Sigasi figure out your project structure, and again, remain in sync with your existing project configuration forever.

Learn more

Import Vivado and VUnit projects

Using the new project wizard, you can automatically import functionality from third-party Vivado or VUnit projects and keep your Modular project in sync with those tools. Using this import wizard automatically configures the import_vivado or import_vunit TCL command mentioned above.

Note that you still have to add the Vivado libraries that are used in the project.sigasi manually.

Learn more

IP reuse

In Classic Projects you might have reused IP by using linked folders or using the Library Database. For example, you are creating a dut and want to reuse your Ethernet IP block, which uses some JTAG IP.

Using Classic Projects you would likely add both of these using linked resources. To do so, you would likely first add JTAG as a linked folder to the Ethernet IP ➊, such that you can design it independently from dut. Then for dut you would have to add ethernet as a linked folder ➋, but also add jtag again ➌. You repeat this exercise for every project that uses the Ethernet IP. In this setup, you always have to browse the filesystem to configure dependencies, even if all your dependencies are in the same place in an IP catalog.

Using Modular Projects, you can add your IP catalog to the Dependency Search Path. Then, you first configure the JTAG IP and Ethernet IP as Modular Projects. Now you can add the JTAG IP as a dependency of the Ethernet IP without browsing the file system but by right-clicking the project in the Projects View and clicking Add Dependency.

For every project that requires the Ethernet IP, simply add the Ethernet IP as a dependency. As it already defines all of its dependencies, there is no need to also manually import the JTAG IP.

The more complex your dependency story becomes, the more advantageous Modular Projects become.

When adding dependencies, every dependency from your Library Database is also shown, making it easy to add the required Vivado libraries, for example.

Learn more

Target dependency graph

Once you start working with a real project, you will end up with many targets, some manual, some scripted, all with their own dependencies. To help you visualize and inspect this architecture and hierarchy, you can make use of the Target Dependency Graph. It can be opened by pressing the icon in the top right of an editor with a project.sigasi file open.

Learn more

Settings sharing

The new Modular Projects come with a new format to configure settings such as linting rule severities and formatting rules. The settings live in .sigasi/settings.json and replace the many settings files that lived in the .settings folder in Classic Projects.

Most companies enforce an internal linting ruleset and style guide, often with custom naming conventions. Previously, you would configure this for one project and then copy and paste it to every other project and dependency. If a change had to be made, as style guides receive continuous revisions and Sigasi’s set of linting rules grows with every release, the change had to be manually propagated to each project.

The new settings format offers an include mechanism to allow you to define your custom rulesets and configuration centrally and propagate each and every change automatically. If necessary, every setting can be overridden, per project, folder, or file, simply via the UI.

Learn more

Ignore-all ruleset

Want to work from a blank slate and only configure the linting rules that are applicable to your project a whitelist of sorts? Simply add "@include": ["sigasi-settings:/ignore-all"] at the top of your settings.json and configure only the rules you need.

While the include needs to be added added manually to your settings.json file, once it is added, all linting rules show as ignored and can be fully configured from the project settings UI.

Learn more

Functional safety standards

Using the include-mechanism, you can also include Sigasi’s DO-254 and STARC rulesets predefined by Sigasi. These enable and configure every Sigasi linting rule and formatting setting that brings you closer to full standard compliance. Note that both require a naming convention to be set, but they do not specify which one should be used. You will thus get warnings for every unconfigured naming convention rule. We recommend you configure all required naming conventions once when adopting a new functional safety standard.

Learn more about the DO-254 ruleset
Learn more about the STARC ruleset

Further new and noteworthy

Besides the above-mentioned features, the following improvements were made to Modular Projects for those that were already using the preview version:

• The Common Libraries folder has been replaced by VHDL Standard Libraries
• Conflicting dependencies that introduce ambiguous references now mention the involved targets
• Added a context menu item to open Modular Projects that you depend on to the workspace
• Added a validation for conflicts introduced by ambiguous dependency configuration
• Added support for setting the dependency search path by setting the SIGASI_DEPENDENCY_SEARCH_PATH environment variable
• Added support for using environment variables in the dependency search path
• Added support for defining environment variables in the project and manual target section in the project.sigasi file
• Added support for using environment variables in includeDirectories and directory in the project.sigasi
• Added Compilation Recipe support for Modular Projects
• Added Compilation Order CSV support for Modular Projects
• Added Documentation Export support for Modular Projects
• Added consistent usage of icons when referring to targets
• Added a warning when referring to missing files and folders in the scripted target command and scripts executed through it
• Inlined all elements of the Design and External nodes into the Projects view
• Refined context menu items, their location, and their availability

Further bug fixes

Besides the above-mentioned features, the following bugs were fixed for Modular Projects for those that were already using the preview version:

• Fixed Sigasi project creation when you have no checked-out license
• Fixed scripted target crash when something is printed to stdout on MSYS/Git on Windows
• Fixed failing xrun scripted targets when their path ends in a slash, e.g., xrun /
• Fixed possible performance degradation when referring to missing files and folders in scripted targets
• Fixed paths in Compilation Order export
• Fixed missing Documentation Export for scripted targets
• Fixed Excluded Files filtering for Modular Projects in the Projects view
• Renamed smart library to not mapped under the Targets node in the Projects view
• Fixed issue paths for Sigasi CLI with Modular Projects (no longer include Target)

AI integration

SAL served us well during the early days of AI when AI integration in VS Code did not support custom models yet. However, with VS Code’s current on-premise models and Bring Your Own Key natively supported through GitHub Copilot, the time has come to sunset SAL.

However, to unlock Sigasi’s full power within VS Code (Copilot) and Cursor, we are introducing the Sigasi MCP extension. It comes pre-installed with Sigasi and it is automatically activated. When you ask the AI to use Sigasi, or when it believes it would be beneficial, it will access the MCP server, feeding it with deterministic information to enhance its probabilistic reasoning and output.

Additionally, for any other AI platform (Codex, Claude Code, Mistral Vibe, etc.) or extension (Gemini, Claude, Mistral, etc. in VS Code) the new Sigasi CLI provides faster iterations through its daemonization.

Learn more

New Sigasi CLI

The Sigasi CLI was rewritten from the ground up. This enables cutting down iteration time for AI agents and CI/CD by adding a daemonization option. You can start the daemon via the sigasi-cli daemon start command and stop it using sigasi-cli daemon stop. Using the daemon will speed up subsequent requests to the CLI.

Additionally, the CLI was perfectly aligned with Sigasi for VS Code. This cuts down on edge cases and inconsistencies. The Compilation Recipe generation now also works for both Classic and Modular Projects.

We’ve ensured that when using the Sigasi Enterprise CLI feature outside of VS Code, you are not blocked or delayed by colleagues using the Sigasi doc gen Enterprise feature in VS Code. All Enterprise customers using CI/CD will get the extra license free of charge.
If you are an Enterprise customer only using Documentation Generation and you want to upgrade to the full Enterprise possibilities, contact our Sales Team for more information.

Learn more about the daemon
Learn more about using Sigasi CLI with AI

State machine visualization

A long-awaited feature hits the spotlight! We improved the analysis of transition conditions, detecting previously undetected transitions, improving reset state detection, and… finally rendering all conditions and their relation to one another. Comments are now rendered in green in a monospace font, as in your editor. Conditions are inferred and automatically composed.

Dependency analysis

Dependency analysis is a foundational feature of Sigasi. It drives the order in which we handle preprocessing, link identifiers, and much more.

This release brings a fully rewritten, more accurate dependency analysis. It splits up dependency sources into compilation, elaboration, and preprocessor dependencies. Most noticeably, this leads to a significantly better preprocessor order approximation, resulting in a better compilation recipe and better external compiler results. All three dependency types can be inspected through the Dependencies Diagram.

Learn more

Classic Project exporters

The External Compiler and Compilation Recipe design automations are now available for both Classic Projects and Modular Projects. If external compiler support is what was keeping you on the legacy Eclipse product, you can now seamlessly move to VS Code and enjoy all the new features, performance improvements, and many bug fixes.

Learn more about the Compilation Recipe
Learn more about the External Compilers

Refinements to the product manual

Work on the product manual continues. Many more pages were rewritten for clarity and completeness—accounting for user requests and feedback. Other than that, the following features were implemented:

• Added an overview page of all VS Code settings impacting Sigasi
• Greatly improved the search
• Greatly improved mobile experience
• Greatly improved code block visualization all over the manual

Quality of life

• Views (Block Diagram, Preprocessor View, etc.) now restore on reload
• Added progress reporting and a cancellation button to the Documentation Export
• Greatly lowered memory usage
• Added a button to clear the top level in the Design Hierarchy
• Redesigned the user flow for creating and adding projects, including the Projects View when no projects are open
• Added an on-hover button to files and folders in the Projects view to change the library mapping of the element
• VHDL Show the current version in the change language version picker
• Verilog Added a button to clear the root UVM component in the UVM Topology View and UVM Diagram

Further new and noteworthy

• Improved licensing error messaging for UVM linting
• Renamed Sigasi support is disabled in this file to Sigasi analysis is not enabled by this file. If you are encountering this warning, ensure the file is library mapped.
• Consolidated all used dependencies and software licenses into one NOTICE.txt file in the root of the .vsix installation file
• Adopted readme, tutorial, demo projects, and walkthroughs to new features and Modular Projects
• Decreased size of persisted cache and added an automatic cleanup mechanism
• Map small projects to work by default
• Improved descriptions of workspace settings
• Included the username in the temp directory lock files for automated tasks, allowing fair play in multi-user environments
• Added a --sonarqube-pre-10.3 option to the Sigasi CLI to support SonarQube servers older than 10.3
• Verilog Greatly improved navigation, rename, find references, and mark occurrences performance for functions
• Verilog Added support for ANSI variable ports without a port direction
  SYSTEMVERILOG

    module test(input a, var b);
    endmodule

• Verilog Show definition documentation of extern functions when there is no declaration documentation
  SYSTEMVERILOG

    class klass;
      extern function int fun();
    endclass
  
    // DOCUMENTATION
    function int klass::fun();
      return 0;
    endfunction

• Verilog Added support for hierarchical identifiers as clocking event in properties and sequences
  SYSTEMVERILOG

    module m;
      logic a, b, x;
      property p;
          @a.b x;
      endproperty
      A1: assert property (p);
    endmodule

• Verilog Added support for class::static_task in disable statements
  SYSTEMVERILOG

    module top;
      class ahb_driver;
        static task drive_master();
          forever #1;
        endtask
      endclass
  
      initial begin
        fork
          ahb_driver::drive_master();
        join_none
  
        #10;
        disable ahb_driver::drive_master;
      end
    endmodule

Bug fixes

• Fixed incorrect State Machines Diagram after reloading window
• Fixed dots in comments triggering autocomplete
• Fixed calling Sigasi CLI from a root directory on Windows, e.g., from C:\
• Fixed a typo in exported documentation
• Fixed missing Change library... item when selecting mapped and unmapped files together
• Fixed server not starting when it automatically increased the max memory threshold above the available amount
• Fixed missing linking when referring to a VHDL instantiation in a generate block from Verilog
• Fixed incorrect VHDL port direction on hover when instantiating an entity from Verilog
• Verilog Fixed missing navigation on includes of .svh files
• Verilog Fixed missing Open Class Hierarchy Code Lens for some UVM classes
• Verilog Fixed missing warnings for files with multiple extern or attributed modules
• VHDL Fixed the Enable project formatting settings option

Talkback

To allow us to analyze what features you use in which way, we added Talkback reporting for

• Target creation
• Target dependency graph usage
• External compiler usage
• Code action and inlay hint usage
• Documentation export

Talkback lets us find and fix bugs, steers our technical direction, and assists in feature prioritization. Talkback is only sent when the sigasi.enableTalkback setting is enabled.

Updates

• Upgraded compilation recipe export to version 2
• Aligned Sigasi CLI issue reporting with Sigasi for VS Code
• The dependency search path setting was renamed to sigasi.dependencySearchPath
• Paths in the @override section of the settings.json no longer use the Design/ and External/ prefix

Sigasi Visual HDL 2026.2.1 Point Release

On July 10, we released Sigasi Visual HDL 2026.2.1. This release contains the following changes and bug fixes:

• Fixed hang during Extracting JRE

Update or install

If you have downloaded SVH from the VS Code Marketplace , your installation will automatically update. You can also download the latest .vsix file and manually install  it in VS Code.

• Linux: https://download.sigasi.com/vs-code/updates/latest/sigasi-visual-hdl-linux.vsix 
• Windows: https://download.sigasi.com/vs-code/updates/latest/sigasi-visual-hdl-windows.vsix 

The SHA sum is downloadable from https://download.sigasi.com/vs-code/updates/latest/vs-code-sha1.txt .

System requirements

Sigasi Visual HDL requires:

• Windows 10 or Windows 11 64-bit
• 64-bit Red Hat Enterprise Linux RHEL 8 or higher
• VS Code >= 1.82 and < 2.0

We recommend having at least 8 GB of memory and about 1 GB of free disk space available for Sigasi Visual HDL.

Feedback

Our Support Team happily welcomes any of your feedback.