Icestudio: drawing an FPGA circuit and flashing a board from the same file

Three steps, and step two is where the hardware constraint lives

Icestudio describes itself as a design tool focused on newcomers to the FPGA world, and the introduction is three steps: draw your circuit, upload it to your favourite open source FPGA board, and you are done.

That sequence is the product. There is no separate build system to learn, no project file format to discover, and no command line to get wrong, because the editor is what produces the bitstream and programs the board.

The scope is narrower than the wording suggests, though. The word that matters is open. The topics attached to the repository include lattice and icestorm, and the collection of screenshots is built around boards like the Alhambra II and the iceBreaker, with a peripheral collection called iceK supplying the hello world examples.

So the tool is a visual front end to a specific open FPGA ecosystem rather than a vendor neutral schematic capture tool. That is a fair trade for open hardware, and it is also the boundary to check before you plan around it.

It runs on Linux, macOS and Windows, and the homepage is icestudio.io with the documentation in a separate wiki repository.

The toolchain is in the postinstall script

Icestudio is a JavaScript application packaged as a desktop program, and package.json describes the whole build process as a list of npm scripts.

The one that matters on a fresh checkout is postinstall:

sh scripts/postInstall.sh && grunt getcollection && npmpd && patch-package && cd app && npm install

Several setup steps run in sequence. A shell script runs from the scripts/ directory, the getcollection Grunt task pulls the example and block collections, npmpd is invoked, patch-package applies the patches held in the patches/ directory, and a nested npm install runs inside the app/ directory because the frontend has its own dependencies.

Development uses start, which runs setupDevEnv and then grunt serve. Packaging is per platform: buildLinux64, buildWindows, buildOSX, buildOSXARM64 and buildAarch64, each a grunt dist call with a different platform argument, and the OSX ARM64 target additionally passes a cpu flag. The build backend is grunt-nw-builder, so the desktop shell is NW.js rather than Electron.

Quality tooling is minimal and telling. jshint exists, and prettier is wired to both a local script and a bot variant that tees modified files to a temporary list, which suggests formatting is enforced by automation. There is no test script in package.json.

The version field in package.json reads 1.0.0.PRw, matching the nightly release names rather than a clean semantic version, and build.info sits at the repository root as the version marker the badges read.

Translations are a first class part of the project

The README carries a generated language table with completion percentages, and it is the most structured part of the document. English and Spanish are complete, Ukrainian is at 94 percent, Czech at 80, German at 70, French at 69, Japanese at 64, Russian at 63, Italian and Taiwanese at 60, Turkish at 59, Basque and Chinese at 58, Korean at 58, Catalonian at 56, Dutch and Galician at 53, and Greek at 51.

The workflow behind those numbers is gettext rather than a JavaScript i18n library. The script preptext runs grunt gettext and then scripts/update_translations.sh, while compiletext runs grunt compiletext, and grunt-angular-gettext is the plugin that ties it to the Angular frontend.

If you contribute, the instructions are in a wiki page titled Translating Icestudio.

For adopters, the completion percentages indicate which interface translations are complete and which are still partial.

Nightly builds versus a stable tag that is two years old

The release list is the most awkward part of this project to report honestly.

The two most recent releases are v1.0.0.PRw-20260821 dated 2026-08-21 and v1.0.0.PRw-20260813 dated 2026-08-13, both named as nightly builds. Below them sits v0.12 from 2024-06-21, which is the most recent numbered stable release in the list.

The last push was on 2026-08-21, the same date as the newest nightly, and the default branch is develop rather than main. The repository is not archived.

Reading those facts together: development is current, the two newest listed releases are nightlies, and the most recent numbered release is v0.12 from mid 2024. The version badges in the README distinguish a stable version from a work in progress version, which is an admission of exactly this split.

There is also a long contributor history in the README, going back per version rather than as a single list, with Juan González (Obijuan) and Carlos Venegas Arrabé appearing across nearly every release from 0.7 upward. Version 0.7 credits seven contributors, 0.8 credits eleven, 0.11 credits twelve. The project is not a one person effort, and the continuation file is long enough that the credits are presented as a table instead of a list.

What the editor is for, and where it stops

The examples tell you what the tool is good at. Hello world projects from the iceK collection for the Alhambra II and the iceBreaker. An IceMem collection. An SPI controller for a four digit seven segment display, documented in a separate technical notes repository in Spanish. Complete processors: a RISC-V CPU, a Z80 CPU, and the Nand2tetris Hack CPU.

The pattern is a progression from a blinking LED to a working processor, and every stage of it is a project somebody else already built in this format. For a workshop or a course, that library is the actual product. The tool is the part you install.

The limit follows from the same progression. A graph of blocks that flashes an LED and a graph of blocks that runs a Z80 are not the same kind of artifact. At some point the block representation stops being more readable than the Verilog it generates, and at that point you are reading generated code and editing the source instead. The README does not document that boundary, which means you will find it yourself mid project.

There is also no vendor story here. Nothing in the README describes targeting a Xilinx or Altera or AMD device, and the toolchain topics name Icestorm and Lattice. If your hardware is elsewhere, this editor will not help you, whatever the diagram looks like.

The GPL-2.0 licence is standard and unambiguous for redistribution, and a prettier configuration, a jshintrc and a VS Code directory, which are signs of an ordinary contributor workflow rather than a polished release process.

Editorial conclusion

Adopt Icestudio if you teach FPGA design, prototype on Lattice iCE40 boards, or want students to reach a blinking LED without writing a toolchain command, since the editor and the board programmer are one workflow. Do not adopt it if you need to target a vendor toolchain it does not describe, if your team wants Verilog files as the source of truth rather than a block graph, or if you need a stable numbered release for reproducible delivery, because the current stable tag in the list is v0.12 from 2024-06-21 and everything newer is a nightly. Before committing, confirm your board appears in the supported list and download the example project the README links for that board rather than starting from a blank file.

Frequently asked questions

Official sources

1. FPGAwars/icestudio on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases