SpaceWire
DESCRIPTION
SpaceWire is commonly used as a data-handling network between processors and instruments, mass memory devices, and telemetry interfaces. The protocol is full-duplex and uses two signals: data and strobe. The clock is encoded across these two signals and can be recovered by XORing the received data and strobe inputs. For two connected SpaceWire nodes in a valid link state, the link must remain active at all times by transmitting NULL characters, even when no payload data is being transferred.
Clock recovery by XORing strobe and data is straightforward in ASIC implementations, but it can be more challenging in FPGA designs. The main challenge is timing closure and timing verification at higher data rates, which can affect deterministic latency.
Microchip RTG4 and RT-PolarFire FPGAs provide clock-recovery mechanisms that improve sampling precision and timing robustness. With the SpaceWire IP core for RT-PolarFire devices, applications can implement up to four SpaceWire nodes operating at up to 400 Mbps.
REMOTE MEMORY ACCESS PROTOCOL
RMAP is an application-level protocol used to read from and write to memory-mapped registers or memory regions in remote nodes across a SpaceWire network. SpaceWire provides the transport path, while RMAP defines the command and response format used to perform remote access operations.
From a protocol-stack perspective, SpaceWire handles link signaling, character encoding, flow control, routing through network addresses, and packet delivery between nodes. While, RMAP sits above SpaceWire and defines higher-level transactions such as read, write, read-modify style sequences, status reporting, and error codes.
This layering allows system designers to keep the network transport and the remote-access behavior separate.
Because RMAP is carried inside SpaceWire packets, it inherits SpaceWire’s low-latency, full-duplex communication model while adding deterministic command semantics for control, configuration, and instrument data handling.
LOGICAL ADDRESSING & PATH ADDRESSING
SpaceWire supports two common routing/addressing approaches, and both can be used with RMAP:
Path addressing:
- The packet contains an explicit sequence of output-port choices (a route) used hop-by-hop.
- It is simple and deterministic for fixed topologies, but routes must be updated if network paths change.
Logical addressing:
- The packet carries a destination logical address, and each router uses an internal routing table to forward it.
- It is easier to scale and maintain in larger networks, since routes can be changed in router tables without changing end-node software.
In many systems, path addressing is used for tightly controlled links and early bring-up, while logical addressing is preferred for operational networks that need flexibility and easier reconfiguration.
SpaceWire on OBCs
CAVU’s OnBoard Computers support SpaceWire compliance with ECSS-E-ST-50-12C (Rev. 1) and can operate at up to 200 Mbps. We offer RMAP implementations as either a software application or a hardware-accelerated IP core for higher speed and greater data throughput.
The upcoming PIC64-HPSC (High-Performance Spaceflight Computing) processor from Microchip, deployed in OBC-64, includes seven SpaceWire nodes. All seven nodes support the RMAP protocol. One PIC64 node in the OBC-64 also supports Emergency Access Mode, which guarantees command and/or telemetry access for custom mission-defined applications during partial system failure, degraded performance, or other anomalies. The SpaceWire nodes are capable of operation up to 200 Mbps.
SPACEWIRE IP AND LINUX DRIVERS
CAVU’s SpaceWire IP and software stack support standard packet-based workflows, including CCSDS over SpaceWire and Remote Memory Access Protocol (RMAP), as well as custom packet formats. The same interface can be used to send and receive application packets, access RMAP memory targets, or expose the on-board computer as an RMAP-accessible memory resource.
Multiple SpaceWire ports can be connected concurrently, allowing one on-board computer to collect sensor data, control spacecraft subsystems, and communicate with several independent nodes. Our camera module demonstrates this capability by transferring 5 MP image frames at 3.75 frames per second over a 200 Mbit/s SpaceWire link.
The IP also supports link-fault and protocol testing. Software can deliberately terminate a packet or transmit an error end-of-packet (EEP) marker, enabling applications to validate error handling and recovery behaviour before deployment.
PROTOCOL FLEXIBILITY
This flexibility supports several common deployment models without a proprietary data format:
- Sensor acquisition: receive high-rate instrument or camera data as application packets.
- On-board control: send commands and receive status from distributed spacecraft subsystems.
- RMAP initiator: read from or write to a remote RMAP target.
- RMAP target: expose local memory for access by another SpaceWire node.
- Gateway operation: forward packet data from SpaceWire to a Linux or Ethernet-connected application.
LINUX-READY PACKET HANDLING
Real-time serial links and general-purpose operating systems operate on different timescales. The FPGA continues to receive SpaceWire traffic while Linux schedules drivers, processes interrupts, and services applications. Multi-descriptor DMA and in-flight packet queues bridge this difference by allowing multiple packets to be transferred without requiring the processor to service every character or every packet immediately.
SPACEWIRE-TO-TCP/IP GATEWAY BANDWIDTH
The gateway transports SpaceWire traffic to Linux through the PolarFire SoC Media Access Subsystem (MSS) Gigabit Ethernet MACs (GEMs). This provides a practical route for connecting multiple SpaceWire nodes to standard TCP/IP applications while retaining the deterministic, point-to-point behaviour of each SpaceWire link.
