SpaceWire Interface in OnBoard Computing
- September 10, 2026
- CAVU Aerospace UK
Modern spacecraft generate and exchange increasingly large volumes of data between onboard computers, cameras, payloads, mass memory and other subsystems. SpaceWire has become one of the key communication technologies for spacecraft data-handling networks because it provides a high-speed, low-power, full-duplex serial interface designed specifically for onboard applications. The technology is defined by ECSS-E-ST-50-12C, while higher-level protocols such as RMAP and CCSDS packet transfer extend its capabilities.
System integrators need an integrated SpaceWire architecture for Microchip PolarFire SoC-based onboard computers, combining FPGA hardware acceleration with bare-metal and Linux software support. Supplier have to provide a complete hardware and software framework for integrating SpaceWire into an OBC and connecting it directly to the processor, DDR memory and spacecraft data-processing software.
An AXI4-Slave SpaceWire node for the Microchip PolarFire SoC computers
Scope: RMAP initiator/target, CCSDS packet handling, arbiters, FIFO and elastic buffers, clock-domain-crossing modules, and Libero Core wrappers, configured around the DDR_ARBITER mode.
Driver Code / Yocto Module
Two driver stacks are provided:
- Bare-metal HAL driver — core mpfs_spacewire driver and example application (HYPER configuration).
- Linux kernel driver — kernel module with UAPI, CCSDS / RMAP / General-Packet protocol libraries, device-tree files, test suite, and a Yocto/Meta recipe layer for CMA/DMA buffer configuration.
Software Documentation
- USER_API_GUIDE
- BAREMETAL_DRIVER_USER_GUIDE
- LINUX_DRIVER_USER_GUIDE
Detail coverage is detailed in space wire conformance.
Overall Conformance Declaration
Profile | Assessment | Declaration |
RMAP target node | Partial; READ & WRITE target profile | The implementation provides RMAP target READ and WRITE functions subject to the restrictions in Section 3. |
RMAP initiator node | Partial; READ & WRITE initiator profile | The implementation sends RMAP READ and WRITE commands and receives their replies subject to the restrictions in Section 4. RMAP read-modify-write is not supported. |
Combined RMAP node | Partial initiator & target implementation | The product implements both roles, but only the documented READ/WRITE subset and implementation profile are claimed by this report. |
CCSDS over SpaceWire | Conforms without format limitations | The implementation encodes, decodes, transmits, and receives the CCSDS packet formats specified for transfer over SpaceWire using protocol identifier 0x02. |
This wording is intentionally narrower than the model declarations in ECSS-E-ST-50-52C clause 5.8. It avoids claiming complete compliance where the product implements a constrained profile.
RMAP Target Node Conformance
ECSS Role Requirements
ECSS-E-ST-50-52C clause 5.7.1.3 requires a target to receive RMAP commands and send replies, discard replies received by a target-only node, and preferably record a “Reply Received by Target” error.
Requirement area | Status | Implementation assessment |
Receive RMAP commands | Supported | Hardware accepts RMAP READ and WRITE commands addressed to the configured target. |
Send RMAP replies | Supported | Target READ replies are generated in hardware; requested WRITE replies report success or rejection to the initiator. |
Prevent a reply from reaching the target function | Supported | The RX redirect classifies RMAP packets from the instruction field and routes replies to the initiator path. The target path therefore cannot receive an RMAP reply or a non-RMAP packet. This satisfies the intent of the target-only discard requirement by architectural isolation before the target function. |
Record “Reply Received by Target” | Not applicable to the implemented data path | A reply cannot reach the target function because it is routed to the initiator path. The optional error condition is therefore unreachable in normal hardware operation. |
Unsupported command or option handling | Partial | Unsupported or unauthorized requests are rejected. Reserved command codes within the supported command packet type are discarded instead of returning ECSS status 2 when a reply is requested. |
The product implements both roles, but the RX redirect provides role separation: RMAP commands are delivered only to the target function and RMAP replies only to the initiator function. Non-RMAP packets are delivered to the CCSDS/general path. “RMAP target function” remains the accurate profile name for this implementation.
Target Product Characteristics
Characteristic | Implemented profile |
Commands | Incrementing READ and incrementing WRITE |
Read-modify-write | Not supported by the current integration |
Transfer length | Minimum 8 octets; multiple of 8 octets; maximum encodable length is set by the 24-bit RMAP length field |
Buffer capacity | No protocol-engine buffer-size limitation beyond the RMAP length field; practical capacity is limited by the operating system resources and the buffer sizes allocated and configured by the software application |
Non-aligned length | Not accepted |
Non-aligned address | Not accepted by the current 64-bit target integration |
Address incrementation | Incrementing only |
Address modes | Absolute address or configured window-offset translation |
RX role isolation | The RX redirect sends only RMAP commands to the target path; replies and non-RMAP packets cannot reach the target function |
Accepted logical address | Configurable node logical address; the default application profile uses 0xFE |
Accepted key | Configurable 8-bit key; the default application profile uses 0x5A |
Accepted address range | Configured DMA target window |
System memory byte order | Little endian; the first received data octet is stored in the least-significant byte of a multi-octet memory value |
RMAP wire-field byte order | Multi-octet RMAP header fields are serialized in network byte order; this is distinct from the little-endian system memory representation |
Header CRC | Checked/generated by RMAP hardware |
WRITE data CRC | Checked by hardware; verified writes are committed only after a valid CRC result |
Unverified WRITE | Accepted data is staged and copied to final memory after successful framing |
Failed verified WRITE | Final memory remains unchanged; staged data is discarded |
Target WRITE buffering | One staging slot; accepted writes are serialized |
Receive-descriptor exhaustion | Tolerated by the system |
Target READ buffering | Reads final target memory directly and do not consume a receive descriptor |
Replies | Generated when requested; initiator completion reports target acceptance or rejection |
Error/status reporting | Generates ECSS status 0, 2, 3, 4, 5, 6, 7, 9, 10, and 12 for the applicable implemented paths. Status 1 is unused, status 8 is reserved, and status 11 is not applicable because RMW is unsupported |
Target Limitations Affecting the Claim
- The current integration is restricted to transfers of at least eight octets and to lengths and addresses aligned to eight octets.
- Only one WRITE can own the target staging area at a time.
- Reserved command codes within the supported RMAP command packet type are discarded rather than returning ECSS status 2 when a reply is requested.
Target Conclusion
The implementation is assessed as a partial RMAP READ and WRITE target function. It supports address translation, invalid-key and out-of-window rejection, unaligned-request rejection, verified and unverified WRITE handling, CRC-failure protection, READ-after-WRITE, EEP, cancellation, and final-memory protection.
RMAP Initiator Node Conformance
ECSS Role Requirements
ECSS-E-ST-50-52C clause 5.7.1.2 requires an initiator to send RMAP commands and receive RMAP replies, discard commands received by an initiator-only node, and preferably record a “Command Received by Initiator” error.
Requirement area | Status | Implementation assessment |
Send RMAP commands | Supported | Hardware initiator submits incrementing READ and WRITE commands through descriptors. |
Receive RMAP replies | Supported | READ and WRITE replies complete through the initiating descriptor; READ data is written to the descriptor’s reply buffer. |
Prevent a command from reaching the initiator function | Supported | The RX redirect classifies RMAP packets from the instruction field and routes commands to the target path. The initiator path therefore cannot receive an RMAP command. This satisfies the intent of the initiator-only discard requirement by architectural isolation before the initiator function. |
Record “Command Received by Initiator” | Not applicable to the implemented data path | A command cannot reach the initiator function because it is routed to the target path. The optional error condition is therefore unreachable in normal hardware operation. |
Detect unsuccessful transactions | Supported | Completion distinguishes local validation, link/termination, reply CRC, target rejection, arbiter, cancellation, and unsupported-command failures. |
As for the target profile, “RMAP initiator function” is more accurate than “initiator-only node” for a product containing both roles. The RX redirect nevertheless enforces the required role isolation before packets enter either RMAP function.
Initiator Product Characteristics
Characteristic | Implemented profile |
Commands | Incrementing READ and incrementing WRITE |
Read-modify-write | Not supported; rejected with an unsupported-RMW completion |
Transfer length | No fixed transfer-length limit |
Buffer capacity | Limited only by operating system resources and the buffer sizes allocated and configured by the software application |
Transfer alignment | Request length and target address must be aligned to eight octets |
Forward path | Supported; path bytes are in the SpaceWire range 1 through 31 |
Return path | Supported return-address lengths are 0, 4, 8, and 12 octets |
RX role isolation | The RX redirect sends only RMAP replies to the initiator path; RMAP commands cannot reach the initiator function |
Public software encoder return path | Fixed at zero octets |
Transaction identifier | 16-bit field supplied by the request |
Target logical address and key | Supplied per request; the default application profile uses target 0xFE and key 0x5A |
Header CRC | Appended and checked by initiator hardware; software-generated generic packets use the library CRC implementation |
WRITE data CRC | Appended by initiator hardware |
READ data CRC | Checked by initiator hardware; CRC failures are reported in completion status |
Reply destination | READ data uses the initiating descriptor’s reply buffer |
Completion | The initiating descriptor is authoritative for success or failure |
Error/status reporting | Reports local validation, command/reply link or termination errors, CRC errors, target errors, arbitration failures, cancellation, unsupported RMW, and received ECSS reply status codes |
Initiator Limitations Affecting the Claim
- The public RMAP encoder supports only incrementing READ (0x4C) and incrementing WRITE-with-reply (0x6C) requests and fixes the return path to zero octets.
- Supported return-address lengths are limited to 0, 4, 8, and 12 octets.
- RMAP read-modify-write is explicitly unsupported.
Initiator Conclusion
The implementation is assessed as a partial RMAP READ & WRITE initiator function. It supports forward and return path variants, CRC handling, target error reporting, peer EEP, cancellation, protected-memory handling, and explicit rejection of read-modify-write.
CCSDS Conformance Profile
Implemented Packet Profile
Characteristic | Implemented profile |
CCSDS format limitations | None |
Packet type | CCSDS Space Packet |
Primary header | Six octets |
Primary-header fields | Version, packet type, secondary-header flag, 11-bit APID, sequence flags, 14-bit sequence count, and packet data length |
Application transfer length | No fixed transfer-length limit |
Packet data-field length | 1 – 65,536 octets per packet |
Buffer capacity | Limited by operating system resources & buffer sizes allocated by the software application |
Buffer alignment | Descriptor and packet-buffer addresses must satisfy the system’s eight-octet alignment requirement |
Sequence count | Incremented per generated packet and wraps after 16,383 |
Multi-byte field order | Network byte order |
SpaceWire protocol identifier | 0x02 |
SpaceWire prefix | Destination logical address, PID 0x02, reserved byte 0x00, and user/application byte |
Path addressing | Supported on transmit; path octets must be 1 – 31 & consumed before receive delivery |
Receive representation | RX DMA begins with the CCSDS primary header followed by the data field; the four-octet SpaceWire prefix is consumed by hardware |
Secondary header | Flag is encoded/decoded; secondary-header contents and semantics are application-defined and are not interpreted by the helper |
Packet error control | No CCSDS payload CRC is checked by the current hardware; mission/application integrity checks are required |
Reassembly | Application responsibility |
Loss, duplication, and ordering | Application responsibility using command/transfer identifiers and CCSDS sequence fields |
CCSDS Conformance Declaration
- The implementation conforms to the SpaceWire CCSDS packet transfer protocol defined by ECSS-E-ST-50-53C without limitations on the supported CCSDS packet format.
- Buffer capacity and address alignment are system resource constraints and do not restrict the CCSDS packet format.
Applicable ECSS standards
- ECSS-E-ST-50-12C Rev.1, SpaceWire – Links, nodes, routers and networks, 15 May 2019.
- ECSS-E-ST-50-52C, SpaceWire – Remote memory access protocol, 5 February 2010.
- ECSS-E-ST-50-53C, SpaceWire – CCSDS packet transfer protocol, 5 February 2010.
