Silice: pipelines and parallelism for FPGA designs

Why Silice targets clocked FPGA algorithms

Silice addresses a specific gap between conventional software and low-level HDL. The README describes it as a language for hardcoding algorithms with pipelines and parallelism into FPGA hardware. Its intended users are engineers who need deterministic cycle behavior, per-cycle logic, or multiple operations in parallel, while still wanting syntax that resembles C and is familiar to Verilog designers.

The language provides high-level design primitives over a lower-level hardware description model. An engineer can combine an algorithm, a pipeline, and explicit cycle boundaries without expressing the entire design only as low-level HDL. A pre-processor runs at instantiation time, allowing parametric designs to reuse the same source with different constants or configuration choices.

This makes Silice relevant to FPGA controllers, signal processors, table-driven algorithms, processors, and small rendering systems. The repository lists VGA, HDMI, UART, SDRAM, SD card, and SPI flash components, plus RV32I processor and Doom or Quake rendering examples. Those examples demonstrate the range of projects represented in the repository, but they do not establish that every design is production ready.

Simulation is part of the intended workflow. The README says that an FPGA is not required to begin, because designs and outputs such as VGA signals can be simulated and visualized. That reduces dependence on physical hardware during early development, although simulation does not eliminate board-level integration work.

Silice scheduling, steps, and generated Verilog

Silice separates sequential updates from combinational work through operators and execution markers. The `:=` operator creates an assignment that is automatically updated on each rising clock. The blinky example places that assignment near the top of an algorithm, before other instructions. A `++:` step marker inserts a one-cycle delay.

The sine-table example shows why this distinction matters. After a block ROM address is assigned, `++:` waits one cycle before its `rdata` is consumed. The README says that instructions between step markers are evaluated in parallel in hardware. This gives the author direct control over latency rather than relying on software-style statements that only happen to execute in an order after synthesis.

The output boundary is Verilog. According to the README, a board framework supplies platform-dependent wrapper code, while Silice writes a Verilog output file. That downstream artifact can enter the proprietary or open-source FPGA flows represented by the included projects. The open-source path uses yosys, nextpnr, and Project IceStorm, including the repository's Ice40 and ECP5 examples.

Because compilation consumes board frameworks, Silice is not only a parser. The source design, framework, generated Verilog, and FPGA synthesis or implementation tools form one path. A framework mismatch can therefore affect pin mapping and platform integration, even if the core algorithm is valid. The repository contains framework documentation, but the README excerpt does not describe a board-independent deployment command.

Building the blinky project for a Mojo v3

The README points new users to GetStarted.md for setup and to the full blinky tutorial. Those files are present in the repository, along with platform-specific guides and dependency scripts for Linux, Windows, macOS, and YoWASP.

Once the documented environment is ready, the shortest complete exercise shown by the README is to build the included blinky project for the Mojo v3. From the repository root, enter the project directory and invoke its existing make target:

cd projects
cd blinky
make mojov3

The target invokes the project's documented build path. The example writes its generated Verilog into the pre-existing project before that project is compiled through the Xilinx ISE toolchain, according to the README. Readers following that path need the platform dependencies described by GetStarted.md. The source snippet alone does not document all prerequisites.

The design continuously increments a 28-bit counter and exposes bits 20 through 27 on `led`. At 50 MHz, the loop has one increment per clock, so the displayed pattern changes as the selected counter bits progress. The source can be written as follows:

algorithm main(output uint8 led) {
  uint28 counter = 0;
  led := counter[20,8];
  while (1) {
    counter = counter + 1;
  }
}

Initializers are mandatory constants. The `[20,8]` slice selects eight bits beginning at bit 20, and `:=` makes `led` track the counter after each rising clock. This exercise checks source compilation, framework selection, generated Verilog, and downstream FPGA compilation without introducing a complex algorithm.

Silice against direct Verilog authoring

Direct Verilog authoring is the clearest documented alternative. Verilog represents the destination format and is already familiar to part of Silice's intended audience. A team with mature Verilog components and established coding standards may prefer to keep algorithms, testbenches, wrappers, and integration files in one language rather than introduce Silice source and then inspect generated Verilog.

Silice changes the authoring model. Its explicit `++:` markers make clock boundaries visible in the source, and its instantiation-time pre-processor is intended for parameterized designs. The high-level primitives can also keep an algorithm, pipeline, and per-cycle logic in one coherent source. Those are source-level conveniences, not evidence of faster synthesis or smaller bitstreams. The README supplies neither timing results nor resource comparisons with hand-written Verilog.

The generated-Verilog boundary also affects debugging. Engineers may need to inspect the result when diagnosing board integration or understanding how parallel statements became circuitry. Documentation for optimization is available in learn-silice/Guidelines.md, while ChangeLog.md records rare breaking changes and recovery instructions. A project that cannot accommodate syntax changes, generated output inspection, or board-framework maintenance is likely to find Silice cumbersome.

Silice is therefore not simply an alternative syntax for every HDL task. It is most compelling when the algorithm is naturally expressed as clocked steps and parallel work, and when simulation is acceptable during design refinement.

Simulation freedom, board constraints, and incomplete guidance

The ability to simulate without an FPGA is a genuine limitation reducer, but it does not make deployment hardware independent. The README says designs and outputs can be simulated and visualized, yet its concrete build example still targets a Mojo v3 and explains that a framework contains FPGA-dependent wrapper code. Users who only need simulation should follow the simulation instructions in learn-silice and the referenced guides rather than assume that `make mojov3` is universally applicable.

Board availability is another constraint. The board catalog names IceBreaker, de10-nano, ULX3S, Fomu, and IceStick, but the catalog is not the same as evidence that every board works equally with every feature. Peripheral compatibility depends on the framework and hardware. The README does not provide a complete support matrix, timing constraints, or a universal first-build procedure for each listed board.

Documentation is uneven by design. The main README calls the mega-tutorial "still being written," while syntax questions are directed to a specific GitHub issue. Core behavior is explained well enough to understand `:=`, `++:`, block ROM access, and the blinky flow, but areas such as resource optimization, less common board setup, and complete formal-verification operation are not documented in the README excerpt.

Formal verification is listed as a native capability, but no command or workflow appears in the README excerpt. It should not be treated as ready for adoption until the relevant guide demonstrates how to run it and how failures are interpreted.

Licence, maintenance, and Silice upgrade exposure

Silice uses a custom licence in LICENSE.md. GitHub classifies the repository licence as other because that file does not map cleanly to a standard category. The repository also contains LICENSE_GPLv3 and LICENSE_MIT, but the README directs readers to LICENSE.md for project licence details. Engineers need to determine from that file which components, examples, or separately licensed portions they may use and under what conditions. This article does not interpret the licence terms.

The repository is not archived, and its last push was on 2026-09-10. The README states that Silice is under active development. That status is supported by both the maintenance facts and the repository's own project-status statement. There are no GitHub releases, so version selection cannot be based on a release feed in the repository information.

Upgrade cost is a real adoption concern. ChangeLog.md explicitly documents rare breaking changes and how to recover from them, which implies source or build adjustments may occasionally be necessary. Designers should also expect framework, FPGA toolchain, and board-definition dependencies to participate in integration. Simulation can help identify algorithmic timing issues after a language change, but the repository text does not promise compatibility across unreleased revisions.

Editorial conclusion

Silice fits engineers who already have a defined clock-level algorithm and want to prototype it through simulation or place it on a supported FPGA board. It is a poor fit for designers who need an undocumented install-independent workflow or cannot accept a custom licence and Verilog-centered toolchain. Before adoption, inspect LICENSE.md, confirm the relevant board framework in frameworks/boards/boards.json, and build the smallest simulation or blinky target for the intended platform.

Frequently asked questions

Official sources

1. Issues
2. README
3. sylefeb/Silice on GitHub