Digital IDE puts Verilog and VHDL language services inside VS Code

The extension is published as fpga-support, not as Digital IDE

The first thing to know before you install it is the identifier. The package.json names the extension fpga-support, gives it the display name Digital IDE, and publishes it under the publisher sterben. The description in the manifest is all in one vscode plugin for Verilog/VHDL development, while the repository description says all in one vscode plugin for HDL development.

{
  "name": "fpga-support",
  "displayName": "Digital IDE",
  "version": "0.5.0",
  "engines": {
    "vscode": "^1.85.0"
  }
}

So the search term in the marketplace is not the name on the logo, and the version constraint is a floor of VS Code 1.85. The entry point is the compiled extension at./out/extension, and the build is a webpack configuration at the repository root, with the TypeScript sources under src/. The manifest also declares the extension as an Extension Pack, a Programming Languages provider and a Snippets provider, which is a hint that the syntaxes/ and snippets/ directories in the repository are first-class parts of it rather than extras.

The activation events are unusually eager. The list is a wildcard, onStartupFinished, and workspaceContains:.vscode/property.json. That last one is the important one: the extension looks for a property.json inside a.vscode directory, which is how it recognises a hardware project folder, and it also starts on every window regardless, so a language server is available before you open a project.

The parser and language services were rewritten in Rust

The headline change in the current line is under the Features heading, and it is specific: a rewritten parser and language services in Rust, supporting Verilog, VHDL and SystemVerilog, with what the README describes as faster performance and more stable services. The figure beside it is a screenshot of the language server behaviour.

The reason this matters for an adopter is that HDL analysis is not a syntax-highlighting problem. Understanding a design means resolving module instantiations, finding the files that define a signal, knowing which packages a VHDL unit depends on, and mapping a hierarchy so that a jump to definition lands in the right file. That is a compiler front end, and the extension is essentially shipping one in Rust, embedded in the editor.

The companion feature on the rendering side is a brand new netlist renderer, which is the picture of the elaborated design rather than the source. For a hardware engineer, a netlist view inside the editor is the quickest way to see whether an instantiation resolved to the module you expected.

The other improvements in this release are quieter but relevant to daily use. The plugin's working status is shown in the status bar at the bottom of VS Code, so you can tell what the current settings are, the project configuration directory was optimised, and auto-completion performance was improved. That last one is the kind of change that only matters when it is fixed, and that the language service rewrite makes possible.

Version 0.5.0 is where VHDL and SystemVerilog became real

The 0.5.0 release notes describe comprehensive support for VHDL and SystemVerilog, with the parenthetical that this covers the file tree, the LSP and more. Before this release the extension was a Verilog tool with aspirations, and the difference is not cosmetic: language support, project structure awareness and diagnostics are three different things that have to line up for the editor to be useful on a VHDL project.

The 0.5.0 notes also add workspace icons for languages or generated files such as Verilog, VHDL, XDC, TCL and VVP. That list is the real inventory of a modern FPGA project, and it is a good sign that the tool understands the shape of a hardware workspace rather than just a folder of .v files. The same release adds LSP and syntax highlighting support for scripts like TCL, XDC and VVP.

XDC in particular is the constraint file for Xilinx devices, TCL is the scripting language that drives the vendor toolchain, and VVP is the output of the Icarus Verilog simulator. A flow that only understands source files leaves you opening three other file types in a plain editor, which is where a project-wide tool earns its keep.

The scope of the manifest keywords backs this up, listing FPGA, ASIC, IC, Digital, HDL, Systemverilog, Verilog, VHDL, Vivado and Xilinx. The intended user is a digital designer working across those file types, not a general software developer.

Vivado, ModelSim and Verilator plug in through two diagnostic settings

This is the part of the design that makes the extension a frontend rather than a replacement for your toolchain. The 0.5.0 release adds support for Vivado, ModelSim and Verilator, and the README explains the mechanism: users can use these third-party tools for simulation and auto-correction by setting function.lsp.linter.vhdl.diagnostor for VHDL and function.lsp.linter.vlog.diagnostor for Verilog.

function.lsp.linter.vhdl.diagnostor
function.lsp.linter.vlog.diagnostor

The two settings are named after the language they serve, and each one names the tool that performs the diagnosis. The split by language is not cosmetic, because the toolchains differ: a Verilog design is normally checked by Verilator or by a vendor simulator, while a VHDL design is checked by ModelSim or by GHDL, and the extension does not guess which one you use.

The result is that the editor's squiggles come from the same simulator you would trust in CI, rather than from a separate in-editor analyser that might disagree with it. That is the correct design for a domain where a warning you cannot reproduce is noise, and it is why the settings exist as plain configuration keys rather than being hard-coded.

For a reader choosing a tool, this is the deciding feature. An extension that analyses HDL on its own gives you a second opinion that you then have to reconcile. An extension that drives your own tools gives you one opinion, in the editor, where you are already working.

The Icarus Verilog runner and the Vivado export are the fragile paths

The bug fix list in the 0.5.0 notes is unusually informative, because it tells you exactly which features are still settling. Three of the fixes concern the Icarus Verilog simulation feature. One fixed a bug where duplicate paths were included as compilation parameters. Another fixed a case where adding or removing an include would cause the simulation compilation to fail, and the note explains the cause, namely that the instModPathStatus property of the instance was not updated. The third fixed simulation issues with Icarus Verilog version 12.

Two more fixes concern Vivado project generation. One addressed the problem of being unable to import Block Design, or BD, during Vivado project generation, and another addressed libraries in custom mode not being importable into Vivado. Both are the kind of failure that only appears when you actually generate a project, and they are the kind of failure that blocks a release rather than a warning.

The pattern to draw from this is that the two integrations with the outside world are the risky parts. The internal services, the file tree, the syntax highlighting and the netlist renderer are the extension's own code and behave consistently. The Icarus Verilog path and the Vivado export path depend on the version and the configuration of a third-party tool, and that is where version 12 of Icarus and the block design import path bit.

For an adopter, that is a testable boundary rather than a vague worry. If your flow is Verilator or ModelSim based, you are in the better-tested area. If your flow depends on generating a Vivado project with block designs, expect to spend time in the troubleshooting and expect to check the CHANGELOG.md at the root of the repository before each upgrade.

Translations for four locales, and a repository that is more than the extension

The repository carries a localisation setup, with an l10n/ directory and separate package.nls files for German, Japanese, Simplified Chinese and Traditional Chinese, plus the base package.nls.json. For a tool used in academic and commercial hardware teams across several regions, that is a meaningful inclusion rather than a detail.

The rest of the tree shows the scope of the work. There is a syntaxes/ directory and a snippets/ directory, a library/ directory, a config/ directory and a scripts/ directory, plus test-fixtures/ for the test data. The webpack.config.js at the root and the tsconfig.json describe a TypeScript extension build, and the .vscodeignore file is what keeps development-only files out of the packaged vsix.

The documentation lives in two places and is worth noting because the README points to both. There is an English document site and a Chinese one, both marked as new, plus a Bilibili video. The repository itself also has a CHANGELOG.md at the root, which is the file to read before upgrading, and a LICENSE file.

The manifest lists categories of Extension Packs, Programming Languages and Snippets, and the activation on workspaceContains:.vscode/property.json tells you the plugin expects a project marker file. That is the shape of the workflow: a hardware project carries a property.json in its .vscode directory, the extension recognises it, and the file tree, language services and workspace icons follow from there.

MIT licensed, and still at version 0.5.0

The licence is MIT, and the LICENSE file sits at the repository root. You can use, modify and redistribute the extension, including in a commercial engineering environment, provided the copyright notice and the licence text are retained. That is a licensing fact rather than legal advice, and for a tool that automates a real engineering flow inside a company it removes a question that commercial HDL tooling tends to raise.

The version number is the thing to keep an eye on. The extension is at 0.5.0, the published release is a 0.5.x vsix dated 2026-09-23, and the previous one is 0.4.6 from 2026-03-05. The repository is not archived, the default branch is main, and the last push was on 2026-09-23, the same day as the newest release. So the project is being worked on, and the releases are tracking that work.

A pre-1.0 version is a signal about the shape of the API, not about the quality of the code. The manifest is where extension-facing settings live, and the two diagnostic keys are the ones the README tells you to change, which means the configuration surface is small and documented in one place. The risk to manage is not that the extension is abandoned but that the configuration surface and the behaviour of the third-party integrations will move as the project approaches 1.0.

The upgrade cost is a vsix and a settings review. Because the two linter settings name external tools you already have, an upgrade that changes the key names would break your configuration, and checking the CHANGELOG.md is the cheap way to avoid finding out at the start of a debug session.

Editorial conclusion

Digital IDE fits a hardware engineer who wants to stay in VS Code while editing HDL, and who wants the editor to know about XDC constraints, TCL scripts and VVP output alongside the source. It does not fit a team that needs a stable, settled tool, since the version number is 0.5.0 and the changelog for the newest release is mostly fixes to the Icarus Verilog and Vivado paths. Before adopting it, set function.lsp.linter.vlog.diagnostor and function.lsp.linter.vhdl.diagnostor to the tools you actually use, and reproduce your own simulation flow on a small design before you rely on the built-in runner.

Frequently asked questions

Official sources

1. Digital-EDA/Digital-IDE on GitHub
2. Issues
3. License: MIT
4. README
5. Releases