An open toolchain brings browser-based design to older Xilinx FPGAs

Field-programmable gate arrays, or FPGAs, are chips whose logic can be configured after manufacture. To use one, a developer describes a circuit in a hardware description language, then runs software that maps the design onto the chip and creates a bitstream: configuration data that tells the FPGA how to operate.

Maló describes Silinx, an open implementation flow for selected Xilinx Spartan-3E and Spartan-6 devices. It combines Yosys, which synthesizes hardware designs, with nextpnr, which places circuit elements and routes their connections. Both are compiled to WebAssembly, allowing the flow to run in a browser or in Node.js. The paper identifies Silinx as AGPL-3.0 licensed; the separate silinx-fpga npm package is listed as Apache-2.0 licensed.

A central challenge is determining which configuration bits control which chip features. The author built a database by observing outputs from ISE’s documented XDL and bit-generation tools, using experiments that measured groups of routing connections efficiently. The router receives only connections whose configuration bits have been measured. If the bitstream writer encounters a feature it has not measured, it refuses to produce a bitstream rather than guessing.

ISE serves as a reference for checking results. For the same placed and routed design, Silinx’s bitstream is compared byte for byte with the one produced by ISE, and ISE’s design-rule checker (DRC) checks the design’s legality. The paper reports successful checks on examples across the supported devices and on tests of specific features. It also reports programming a Basys2 board with a bitstream built without running Xilinx tools during that build.

These checks have limits. A clean DRC supports the legality of routing, but does not assess placement quality or detect an incorrect lookup-table equation. The paper describes a separate research check that simulates the converted design cycle by cycle and compares every flip-flop to check for that kind of error.

For a performance comparison, the paper reports results for 67 open-source designs targeting the Spartan-3E XC3S1200E. The comparison with ISE covers the 45 designs that both flows built at all three matching optimization goals. Across those shared designs, geometric-mean results show that Silinx used 15% fewer FPGA slices at the Area goal, 21% fewer at Speed, and 20% fewer at Fast. Slices are configurable logic resources on the chip; these averages do not mean every design used fewer.

Timing was measured on a smaller set: 39 or 40 designs were timed by both flows, depending on the goal. On those designs, Silinx’s geometric-mean critical paths were 14% shorter at Area and 8% shorter at Speed. At Fast, they were 12% longer. The averages conceal differences between designs, and the paper notes examples where Silinx was slower. In particular, the Fast strategy can leave deep logic paths comparatively slow.

The comparison has important coverage limits. Xilinx’s synthesis tool, XST, could not read 15 of the 67 designs, while seven more failed during ISE’s constraint step. The paper reports that Silinx could build most of these cases, but they cannot be counted as designs built by both flows. In the measured version, one design also failed in Silinx at Area and Fast; a later nextpnr release built it, but that result was not part of the comparison. The performance averages therefore describe the shared subset, not all 67 designs.

Evidence also differs by chip family. Spartan-6 examples were checked for byte-identical bitstreams and clean DRC, but the paper does not present a Spartan-6 performance comparison with ISE across a design corpus. It says some DCM and PLL configurations beyond those measured are not covered. The detailed quality comparison concerns one Spartan-3E model and one ISE version. Browser execution has a trade-off too: the paper says WebAssembly is slower than native code.

The source is an arXiv paper, and this evidence alone does not establish its peer-review status. The measurements and validation described here are reported by the author; they do not establish performance across every supported chip, design, or configuration. The work presents a browser-accessible route for building designs on selected older devices, with ISE used as a reference for bitstream and legality checks.