Systolic Labs open hardware, near Paris

RISC-V Linux FPGA

Linux on a CVA6, and SMP firmware on a €30 module. Both on real silicon.

Systolic Labs builds open, auditable RISC-V platforms, and two of them already run. A complete 64-bit CVA6 SoC — soft-core, no hardened CPU — boots Linux 6.11.11 to an interactive BusyBox shell inside a Kintex UltraScale+. A dual-core Ibex SoC runs an unmodified Zephyr SMP kernel on a €30 Artix-7 module. Every figure on this page is measured on the board.

StatusBoth platforms boot on hardware today. Current work: moving the kernel image off the UART link and onto an SD card. Accelerator slots and the HBM2 scale-up come next.

Running
Linux 6.11 on CVA6 (RV64IMAC)
Running
2× Ibex · Zephyr SMP
Entry cost
from €30 for a working SoC
Next
NPU accelerator · HBM2 scale-up

01 Silicon

Two platforms, one ladder. An application-class core running a real Linux userspace, and a microcontroller-class SoC running real SMP firmware. Both validated on physical hardware — and the RTL underneath both is open and auditable.

Application-class — Linux 6.11 on a CVA6 SoC running

A complete 64-bit RISC-V SoC — CPU, DDR4 controller, interrupt and timer blocks, a UART and an accelerator slot — boots a real kernel to an interactive shell on a Xilinx Kintex UltraScale+ XCKU5P. Soft-core: there is no hardened CPU in the device. This is a mid-range FPGA running Linux off a core you can read.

CVA6 / KU5P platform configuration
FPGAXCKU5P-FFVB676-1-i · Kintex UltraScale+
CPU coreCVA6, RV64IMAC, Sv39 MMU · 1 hart
Extensionsrv64imac_zicntr_zicsr_zifencei_zihpm_zca
SoC clock50 MHz, MMCM from ui_clk 300 MHz
DDR41 GiB MT40A512M16 · 2400 MT/s · ui_clk 300 MHz (4:1) @ 0x1_0000_0000
Boot chainOpenSBI 1.8.1 → Linux 6.11.11 → BusyBox, static initramfs
PeripheralsUART 16550A @ 0x10010000 · accelerator slot @ 0x10000000 · CLINT
Bootloader128 KiB BRAM
ToolsVivado 2025.2

Measured on silicon — UART log

Software results measured on the KU5P board
Bootcomplete, to a BusyBox ~ # prompt
Usable RAM992 / 1022 MiB · 97 %
Kernel reserved27.6 MiB
sched_clock64-bit @ 50 MHz · 20 ns resolution
Tick timer250 Hz · 4 ms
BogoMIPS100 · lpj = 200,000
Local interrupts mapped64
OpenSBI image275,872 B
Kernel image11,097,600 B · 10.6 MiB
Device tree1,766 B
UART transfer115,200 8N1 · 32 B / 3 ms · ≈3.6× faster than before

Timing — post-route

Post-route timing results
Paths meeting constraints99.97 % · 827,998 endpoints, 231 violated
Setup WNS−0.178 ns
Setup TNS−15.3 ns
Whereui_clk 300 MHz domain only — the DDR4 bridge
SoC 50 MHz domainWNS +3.69 ns · clean
Hold WHS+0.012 ns · 0 violations

Resources — post-place, XCKU5P

Resource utilisation after placement
LUT, incl. distributed RAM161,688 / 216,96074.5 %
— logic LUTs only95,501 / 216,96044.0 %
Flip-flops65,057 / 433,92015.0 %
BRAM tiles61.5 / 48012.8 %
DSP48E2467 / 1,82425.6 %
MMCM / PLL2 / 2

Timing is not fully closed, and that is stated here on purpose. WNS is −0.178 ns with TNS −15.3 ns, confined to the 300 MHz ui_clk domain — the DDR4 bridge. The design boots and runs, but it is not a timing-clean signoff. Every other clock domain is clean and hold has zero violations. A page that only publishes its good numbers is not evidence.

What it demonstrates

  • A Linux-capable 64-bit RISC-V SoC fits in a mid-range UltraScale+ with no hardened processor.
  • Full boot out of DDR4 with kernel loaded at 0x100200000, MMU Sv39 and write-through caches.
  • A working atomic path (AMO) to DDR4 through an ATOP→RMW converter — the scheduler depends on it, and this is the class of bug that never shows up in simulation.
  • The accelerator slot is already mapped in the same design and reachable from Linux (devmem 0x10000000): the integration path for the NPU is in place.

Microcontroller-class — Zephyr SMP on a €30 module running

The gen1-ibex-a branch carries a complete SoC on a Colorlight i9+ v6.1 module (Artix-7 XC7A50T, 8 MB SDRAM, 25 MHz): two Ibex RV32IMA cores, a 64-bit AXI4 crossbar, an SDRAM controller, a CLINT, a 16550 console, a RISC-V-spec interrupt controller, a cross-core LR/SC exclusivity monitor, and free slots for an accelerator (NPU) and a DMA. Above it runs Zephyr RTOS v4.1.0 in SMP — unmodified kernel — with an interactive shell on the console.

Measured on the board

Results measured on the Colorlight i9+ board, gen1-ibex-a branch
Cross-core atomics — LR/SC20,000 / 20,000 exact
Cross-core atomics — AMO20,000 / 20,000 exact
Interrupt-driven console (PLIC)400 / 400-byte burst, 0 FIFO overruns
Console throughput — interrupt11,697 B/s
Console throughput — polled136 B/s · ×86 slower
SMP stress, 6 concurrent threadsPASS · no lost IPIs
Timing signoff — WNS+9.954 ns
Timing signoff — WHS+0.050 ns
LUT utilisation57.5 %
Block RAM0
Commits on the branch307
Zephyr applications8
Binaries in git history0

Every figure has a trace in the repository: console capture, checksum, timing report. Hold margin is consolidated by constraint — 0.159 → 0.197 ns physical — behind automated validation gates. The accelerator slots are wired and validated; the NPU itself is not instantiated yet, and this page will keep saying so until it is.

Why it is different

  1. Silicon, not a promise. Each claim ships with its evidence: UART log, console capture, checksum, timing report. The numbers above come off the board, not out of a model — and the one figure that is not clean is printed alongside the ones that are.
  2. A gated, reproducible flow. Cycle-accurate co-simulation → bitstream (timing, resource and sha256 gates) → physical silicon. Testbenches have a mutation mode, because a test that cannot fail proves nothing. A pre-flight lint catches bugs invisible in simulation — it intercepted a dual-driver signal that Vivado's DRC rejected.
  3. A cheap way in. The microcontroller-class proof runs on a €30–50 module and a JTAG dongle. No proprietary development board, no expensive tool licence — and the same engineering discipline on both platforms.
  4. Ready for heterogeneous compute. Both tiers already expose mapped accelerator and DMA slots, and cross-core coherency is validated on the small one: the "CPU + accelerator on the same fabric" brick is in place.

Where it stands

Proven on silicon

  • Linux 6.11.11 to userspace on CVA6 / KU5P
  • Full boot from DDR4, MMU Sv39, AMO path
  • Zephyr SMP boot on the €30 module
  • Atomics, SMP stress, timing signoff

In progress

  • SPI master to boot from SD card — the 11 MB kernel currently takes ~17 minutes over the 115,200 baud UART link
  • RTL written, integrated and simulated; engine proven on silicon
  • Blocker: identifying the four physical pins on the bench. Lab wiring, not design.

Next

  • FAT stack and boot from SD
  • Accelerator slot bring-up (NPU, DMA)
  • Closing timing on the 300 MHz DDR4 bridge
  • HBM2 scale-up on the Alveo path

02 Platform

The platform targets the buyers that closed silicon excludes or overcharges: European research groups, integrators under GDPR and AI Act pressure, and anyone who needs a datapath they can actually read.

Two things that never meet in commercial silicon are combined here. A software-recompilable RISC-V core gives an open, auditable instruction path and no vendor lock-in — and it is already proven up to a Linux userspace on a plain soft-core. A systolic-array NPU built on FPGA fabric will give a datapath that survives model changes by recompiling — instead of a silicon respin or a new part number. Underneath both sits HBM2 bandwidth that most competing small accelerators simply do not have.

The design posture is deliberate about what this is not:

  • Not a GPU competitor. On raw TOPS/$ and TOPS/W, dedicated edge-AI parts win, and any claim otherwise is marketing.
  • Not a commodity edge-AI part. Camera-tile inference in volume belongs to Hailo and Axelera.
  • Not a cloud service. It is a card and a toolchain, on your bench or in your rack.

What it wins on is the combination those alternatives cannot offer: an auditable open RTL path, a reconfigurable datapath, HBM-class bandwidth in a 75 W half-height card, and a provenance that stands up to a procurement filter written as "no third-country-controlled supplier".

03 Hardware

Proven — Kintex UltraScale+ XCKU5P running Linux

KU5P platform specifications
FPGAXCKU5P-FFVB676-1-i · Kintex UltraScale+
CPUCVA6 RV64IMAC · Sv39 · 1 hart · soft-core
Memory1 GiB DDR4 (MT40A512M16) · 2400 MT/s
ClocksSoC 50 MHz · ui_clk 300 MHz
RuntimeOpenSBI 1.8.1 → Linux 6.11.11 → BusyBox
ToolsVivado 2025.2

Proven — Colorlight i9+ v6.1 running Zephyr

Colorlight i9+ platform specifications
DeviceArtix-7 XC7A50T
Memory8 MB SDRAM
Clock25 MHz
Cores2× Ibex RV32IMA · 64-bit AXI4 crossbar
RuntimeZephyr RTOS v4.1.0, SMP, unmodified kernel
Cost€30–50 module + JTAG dongle

Next — AMD Alveo U50 not in hand

The scale-up target, chosen on price per gigabyte-per-second rather than peak spec. Purchased only when a client, a lab engagement or a grant requires local HBM hardware.

Alveo U50 specifications
CardAMD Alveo U50 (A-U50-P00G-PQ-G)
DeviceVirtex UltraScale+ VU35P, 16 nm
Memory8 GB HBM2 · 316 GB/s peak
Logic872 K LUTs · 5,952 DSP slices
On-chip51.8 Mb BRAM + 180 Mb UltraRAM
Host linkPCIe Gen3 x16 / 2× Gen4 x8 (CCIX)
FormatHalf-height, half-length, single slot, passive · 75 W

Portability. AMD has issued the end-of-life notice for the U50 (XCN26004): last-time-buy 30 October 2026, last-time-ship 2 April 2027. That closes the new-and-warranted channel only — the used market is unaffected. The design is kept portable at RTL level to the U55C (16 GB, 460 GB/s) and V80 (32 GB, 820 GB/s).

04 Log

Working notes, dated when the work lands. No roadmap theatre.

  1. Market and positioning study

    Four verticals scored on sales friction and willingness to pay. Conclusion: lead with academic and R&D prototyping, keep edge AI and defence behind it, do not attack the data centre. Positioning fixed as CVA6-first.

  2. HBM FPGA sourcing audit

    Every FPGA with on-package HBM2/HBM2e compared on bandwidth, LUT count, price and lifecycle status. Alveo U50 selected as the scale-up reference: best bandwidth per watt per euro in the 2026 market.

  3. Prototyping cost model

    AWS F2 (VU47P) against a local U50 for the bring-up phase: compile, simulation and hardware-in-the-loop budgets. Result — the cloud path costs less than the electricity and cooling argument for a local card, until sustained bandwidth testing starts.

  4. Getting the kernel off the UART link

    The 11 MB kernel image takes about 17 minutes to push over the 115,200 baud console — tolerable for bring-up, unusable for iteration. An SPI master to boot from SD is written, integrated and simulated, with the engine proven on silicon. Remaining work is identifying four physical pins on the bench: lab wiring, not design.

  5. FAT stack, then the accelerator slot

    Filesystem on SD, closing timing on the 300 MHz DDR4 bridge, then instantiating the first accelerator in the slot that is already mapped.

05 Work with me

Design services

FPGA and accelerator systems engineering: RTL bring-up, SoC integration, RISC-V integration, Linux/BSP bring-up, HBM and DMA shells, benchmarking with honest numbers. Fixed-scope or day rate.

Research access

For labs and academic groups using CVA6, Ibex, Chipyard or Tiny Tapeout flows: design support, a reproducible build-and-signoff flow, and measured results you can cite.

Email [email protected]

I am one engineer. If the scope is real, I will tell you what I can deliver and what I cannot — that conversation takes less time than a proposal.