TerosHDL: a VS Code toolbox that wraps the HDL tools you already use
VHDL and Verilog/SV IDE: state machine viewer, linter, documentation, snippets... and more!
At a glance
- What is it?
- TerosHDL is a Visual Studio Code extension that puts a large set of EDA tools behind one interface for VHDL and Verilog/SystemVerilog development, with linters, a state machine viewer, documentation generation and simulator support. It suits FPGA and ASIC engineers who keep their tools installed separately, and it does not replace the tools themselves.
- Who is it for?
- TerosHDL is worth trying for an FPGA or ASIC engineer who already has simulators and linters installed and is tired of switching between a terminal, a waveform viewer and an editor, because the plugin's job is exactly that switching and it does it through a single activity bar view and a log panel. It is the wrong choice for someone who wants a single tool that replaces their EDA flow, and for a team that cannot install vendor tools on developer machines.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly VHDL, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A toolbox of backends with one VS Code interface on top
The stated goal of TerosHDL is to provide an open source toolbox for HDL developers, with functionalities commonly used by software developers. The architecture is described plainly: the toolbox consists of a bunch of tools, some developed by the Teros Technology organization and others coming from open source projects, all organized in different backends and exposed to the graphical interface through the plugin.
That distinction matters. TerosHDL is not a simulator and not a linter. It is the layer that knows how to find those programs on your machine, how to invoke them, how to read their output and how to show the result inside the editor. The tool list is long and specific, and it names the tools individually: Raptor, Vivado, ModelSim, GHDL, Verilator, Icarus, VCS, Yosys, VUnit, cocotb, Diamond, Icestorm, ISE, Quartus, Radiant, Spyglass, Symbiflow, Trellis and Xcelium, and more.
Mixing vendor tools and open source tools in one list is the point. An engineer whose simulation flow spans, say, a vendor simulator for sign-off and Verilator for fast iteration gets one interface for both instead of two workflows.
The design goal of being as much self-contained as possible and simplifying the installation process is what the tool list is meant to deliver. The plugin itself is a VS Code extension published as teroshdl by the publisher teros-technology, and the manifest declares the required editor version as 1.74.0 or later, along with the category tags that place it under programming languages, snippets, formatters and linters.
What the plugin actually adds on top of syntax highlighting
The feature list divides into editor features and tool features, and the editor features are the ones you notice first.
There is syntax highlighting, and beyond that the usual language-server conveniences: go to definition, hover, and a hierarchy viewer plus a dependencies viewer for navigating a design. There is a template generator, code snippets and grammar, automatic documentation, and code formatting.
Two of them stand out for hardware work. The state machine viewer and the state machine designer are unusual features for a text editor extension, and they are the reason a hardware engineer would look at this plugin rather than at a generic language server. The Verilog and SystemVerilog schematic viewer covers the same ground for those two languages, drawing a schematic of a design from the source.
Then the checking side. There is an errors linter, and a separate style linter which is Verible, the style checking tool set. That is worth noting as a design decision: the style rules come from an existing open source project rather than from a house style invented inside the extension.
The auto repost and media features do not apply here, but the structure of the list does: each entry maps to either something the plugin does in the editor or to a tool it drives, and the whole thing hangs off the extension's views. The manifest contributes a TerosHDL view container in the activity bar and two panel views, one for the log report and one for timing, which is how tool output reaches you without leaving the editor.
Per-tool configuration lives in TOML files, one per backend
The examples directory at the top of the repository contains four configuration files, and their names tell you how the configuration model works: istyle.toml, s3sv.toml, standalone_vhdl.toml and verible.toml. Each is named after a tool or a mode, which is the natural fit for a toolbox whose backends are separate programs.
standalone_vhdl.toml points at a VHDL flow that stands on its own, verible.toml at the style checking tool, and s3sv.toml at a SystemVerilog flow. istyle.toml covers the style checker configuration. The pattern is that a backend has its own configuration file, and the plugin passes it through.
That is a much lighter integration model than a plugin that re-implements the tools, and it has a predictable consequence: the behaviour of any given tool inside the editor is the behaviour of the tool itself, configured by the file you already know. If Verible flags something, the flag comes from Verible.
The repository tree supports the picture of a plugin with a server side and a UI side. There is a server/ directory, a src/ directory for the extension itself, a snippets/ directory, syntaxes/ for the language grammars, an auto_package/ directory, a bin/ directory, an esbuild.js build script, configs/, resources/, docs/ and examples/. Testing is split between jest.config.json, a .mocharc.js file, a tests/ directory, a tests_impr/ directory and two standalone test files at the root, one of them a TypeScript file for a keepports diagram. The build pipeline is esbuild based and the main entry point is ./out/teroshdl/extension.js.
Contributing means forking, and the dev branch is the working branch
The contribution path is documented in five steps, and the fourth one is the detail worth catching: development happens on the dev branch.
The sequence is to make a fork, clone the fork URL, change into the vscode-terosHDL directory, and check out the dev branch, which the documentation says is the branch where development happens. After that it is npm install, and the tests run with npm run test, after which a pull request can be opened. Put together, the working part of the sequence is:
git clone [FORK URL]
cd vscode-terosHDL
git checkout dev
npm installYou should end up on the dev branch with the dependencies installed, and npm run test should then execute the suite before you open the pull request.
The repository's default branch is indeed dev, and the release history shows why that matters. The tags include a rolling latest tag dated 2026-10-11, then v8.0.3 from 2025-08-25 and v8.0.2 from 2025-07-27. So a numbered release and a rolling tag move on different schedules, and the manifest in the repository is at version 8.0.5, above the most recent numbered tag. A contributor working on dev is working on a version that is not the last numbered release, and the marketplace build is published from that branch.
The last push to the repository was on 2026-10-11, the same date as the latest tag, so the branch is current with the published rolling build.
Funded as open source infrastructure, maintained by two people
The funding note is worth reading because it tells you what kind of project this is. TerosHDL was funded through the NGI Assure Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology, under grant agreement number 957073.
That is public money funding open source tooling in a field that is not glamorous, which is the reason a vendor-free toolbox for HDL developers exists at all. It also suggests the tool set is chosen for the needs of a broad community rather than for one company's flow.
The project is managed by two people, Carlos Alberto Ruiz and Ismael Pérez, with their contact details published in the readme. Two maintainers for a toolbox this size, and one of them is described elsewhere in the project as a hardware engineer, is a reasonable but small team.
The licence is GPL-3.0, which for a plugin distributed through the Visual Studio Marketplace is the standard choice for a tool of this kind and carries the copyleft obligation on distribution. A company embedding parts of it in its own internal tooling would need to read the licence rather than assume the permissiveness of MIT, but the plugin itself is installed as a published extension, which is ordinary use rather than distribution.
The documentation is published separately at terostechnology.github.io/terosHDLdoc, with the main site at terostechnology.github.io.
Where TerosHDL is the wrong tool
The first limit is the most obvious one. TerosHDL does not ship the tools. If you do not have Vivado, ModelSim, Quartus or Verilator installed and licensed on your machine, the corresponding parts of the plugin do nothing for you, and a commercial simulator from a vendor still needs a vendor licence. The plugin makes the tools convenient, it does not make them affordable.
The second limit is language coverage. The features and the topics centre on VHDL and Verilog with SystemVerilog, and while the tool list includes GHDL and the Verilog tools, the description names the extension as an IDE for those two language families. A project in Chisel or SpinalHDL, or in a vendor-specific language, gets no language support from it.
The third limit is the coupling to a specific editor. Everything here is a VS Code extension, and while the underlying tools are editor-agnostic, the workflow features, the state machine designer, the schematic viewer and the log and timing panels are all VS Code surfaces. A team standardised on another editor cannot use them, and the parts that could be reused would have to be extracted from the server and plugin layers by hand.
The fourth is a packaging reality. The extension is published under a single publisher account, and the repository is the source, but the packaging directory is called auto_package, which points at a build that assembles the marketplace artifact. Anyone who wants to build their own version, or to reproduce the published binary from source, is doing something the project does not document in the readme. The dev flow documented here gets you a working development tree, not a reproducible packaging pipeline.
Editorial conclusion
TerosHDL is worth trying for an FPGA or ASIC engineer who already has simulators and linters installed and is tired of switching between a terminal, a waveform viewer and an editor, because the plugin's job is exactly that switching and it does it through a single activity bar view and a log panel. It is the wrong choice for someone who wants a single tool that replaces their EDA flow, and for a team that cannot install vendor tools on developer machines. Before you commit, check the three things that decide the outcome: that the tools you need are on the supported list, since simulators such as Vivado, ModelSim, VCS, Quartus and Xcelium are named individually and only the ones present on your machine will work; that the extension is installed from the Visual Studio Marketplace under the publisher teros-technology, since the repository has no install script; and that the version you get matches what you expect, with the marketplace manifest at 8.0.5 while the most recent numbered tag is v8.0.3 from 2025-08-25.
Frequently asked questions
How do I install TerosHDL for VS Code?
It is published on the Visual Studio Marketplace as the extension teroshdl under the publisher teros-technology, and the manifest requires a Visual Studio Code version of 1.74.0 or later. The project itself is a toolbox of separately installed tools, so the extension only helps once the tools you want to drive are present on your machine.
Which simulators and tools does TerosHDL support?
The supported list names Raptor, Vivado, ModelSim, GHDL, Verilator, Icarus, VCS, Yosys, VUnit, cocotb, Diamond, Icestorm, ISE, Quartus, Radiant, Spyglass, Symbiflow, Trellis and Xcelium among others. Configuration for each backend lives in its own TOML file, with examples for istyle, s3sv, standalone VHDL and Verible in the examples directory.
How do I contribute to TerosHDL?
Fork the repository, clone your fork, change into the vscode-terosHDL directory, check out the dev branch where development happens, then run npm install. Tests run with npm run test, after which you can open a pull request.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/terostechnology-vscode-teroshdl)Was this useful?