Satellite in low Earth orbit with a glowing data-strobe SpaceWire link running through its avionics bay

SpaceWire Reloaded: Open-Source SpaceWire Core for FPGAs

A vendor-neutral SpaceWire link core in both VHDL and Verilog, with an AXI4-Lite register block, AXI4-Stream N-Char bridges, portable clock-domain crossing, a dual-language cocotb regression, and an Arty A7 hardware example.

View on GitHub All projects & IP cores

What SpaceWire Reloaded is

SpaceWire is the point-to-point link that ties instruments, mass memory, and on-board computers together on most European and many international spacecraft. SpaceWire Reloaded is an open-source implementation of its link layer for FPGAs: data-strobe encoding, link initialisation and disconnect, credit-based flow control, N-Chars, and TimeCodes, wrapped in the AXI interfaces the rest of an FPGA design already speaks.

Diagram: the user design controls SpaceWire Reloaded over AXI4-Lite and exchanges N-Chars over AXI4-Stream TX and RX; inside the core, N-Char bridges, a link controller, registers, and selectable TX/RX front ends cross three clock domains and drive the SpaceWire data and strobe pairs through LVDS drivers to a remote node or router
AXI in, SpaceWire out: control over AXI4-Lite, N-Chars over AXI4-Stream, data-strobe pairs to the link.

Built on SpaceWire Light, reworked for today's flows

The link-layer RTL descends from Joris van Rantwijk's SpaceWire Light (2009–2013) and keeps its proven encoder, decoder, and link state machine. What held that project back for new designs was everything around the core: an AMBA integration bound to GRLIB and LEON3, a single language, and a tool flow from another era. SpaceWire Reloaded removes that integration entirely and replaces it with an AXI layer written from scratch, adds the Verilog twin of the VHDL source, and wraps the vendor primitives so the same RTL builds on Xilinx, Intel, and Lattice parts. The original upstream README is preserved alongside so the history stays visible.

The core keeps a simple internal control/data interface below the AXI wrapper, so further bus wrappers (AHB/APB, or an AXI-DMA data path) can be added without touching the SpaceWire logic.

Verification and measured results

The regression is a dual-language cocotb suite: the same tests run against the Verilog source with Icarus Verilog and the VHDL source with GHDL. It loops the physical TX/RX pins back through the real core and covers EOP, EEP, empty packets, back-to-back packets, stalls at packet boundaries, reset during streaming, disconnect and reconnect, and TimeCode transfer over AXI4-Lite. A 23-configuration sweep mirrors the original SpaceWire Light bench across clock, divider, receiver and transmitter implementation, and input rate. A cocotb SpaceWire line driver injects disconnect, double-ESC, parity, and credit errors and checks the sticky error bits, singly and as a back-to-back burst.

Two AXI protocol checker layers run throughout: a repo-local checker for ready/valid stability, response ordering, byte strobes, and the N-Char terminal-beat contract, plus the handshake checker built into a fork of cocotbext-axi that rides inside every bus functional model. A SpaceWire monitor decodes the transmitted character stream and asserts exchange-level conformance: NULL before FCT, FCT before Run, TimeCode priority over data, eight N-Chars of credit per FCT, and no transition to Run on line noise. Functional cover points are gated in CI, and Verilator reports 99.3% line coverage of the core and AXI wrappers, with branch, expression, and toggle coverage tracked separately.

Resource cost on an Artix-7 (xc7a100t-1, Vivado 2025.2, out of context):

Configuration Source LUTs FFs RAMB18 System clock Fmax
Generic RX/TX, 20 MHz Verilog 365 369 2 175 MHz
Generic RX/TX, 20 MHz VHDL 358 369 2 181 MHz
Fast RX/TX, 50/100 MHz Verilog 525 548 2 171 MHz
Fast RX/TX, 50/100 MHz VHDL 538 548 2 169 MHz

A few hundred LUTs, one block-RAM tile for the two N-Char FIFOs, no DSPs, and the two language sources within a few percent of each other. In hardware, the Arty A7-100T example runs a link in internal or Pmod loopback, brings it up from a small AXI-Lite master engine, and is verified over JTAG with fpgacapZero, whose logic analyzers capture the data and strobe lines directly.

Need RMAP? Our cores sit on top

Most SpaceWire nodes speak more than raw packets: instruments, mass memory, and payload controllers are read and written through the Remote Memory Access Protocol (RMAP). bard0 design offers RMAP initiator and target cores as our own IP, built to sit directly on the AXI4-Stream N-Char interface of SpaceWire Reloaded and to map RMAP commands onto AXI memory transactions in your design. Contact us to know more about the feature set and deliverables.

Ask about RMAP cores

Frequently asked questions

VHDL or Verilog?

Either. Both sources live in the repository, are kept in parity by CI, and run the same cocotb regression. The Arty example ships in both languages too.

Which layers of SpaceWire does it cover?

The link layer: signal encoding, link initialisation, flow control, N-Chars, and TimeCodes. Routing and higher protocol layers sit above it. For RMAP, see our RMAP cores below.

What clocks does it need?

A system clock, a receive sample clock, and a transmit bit clock, treated as mutually asynchronous and crossed through gray-coded pointers and two-flop synchronisers. The startup divider is derived from the clock parameters and elaboration aborts if the clock cannot produce the mandatory 10 Mbit/s handshake rate, so a wrong clock choice fails early rather than on the bench.

Can bard0 help?

Yes. SpaceWire Reloaded is maintained by bard0 design. We supply the RMAP cores above and help teams build satellite payload and instrument electronics around the link, from camera and sensor front ends with our MIPI CSI-2 Aggregator and FPGA ISP to on-hardware debug with fpgacapZero.


Clone the core, run the regression, and bring up a link on an Arty in an afternoon. When the design grows into RMAP, routing, or a full payload controller, we build that with you.

View on GitHub Contact us

We use analytics and marketing tools to analyze traffic and improve our services. By clicking "Accept", you agree to our use of these tools.