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.

A SpaceWire link configured at 200 Mbit/s delivers a maximum of 160 Mbit/s (20 MB/s) of user bytes in one direction. The difference is character-level overhead: every eight-bit data value is carried in a ten-bit SpaceWire data character. SpaceWire is full duplex, but link flow control must also be considered when both directions carry continuous traffic. Each receiver returns one flow-control token (FCT) for every eight normal characters it accepts, and those FCTs use capacity in the opposite direction. Consequently, a continuously saturated bidirectional link has a payload budget of approximately 142.22 Mbit/s (17.78 MB/s) in each direction, or 284.44 Mbit/s combined. Packet termination characters and any routing, RMAP, CCSDS, IP, TCP, or application headers reduce the available application payload further.

TCP/IP and Ethernet Capacity

The theoretical TCP goodput of a 1 Gbit/s Ethernet connection is lower than its physical line rate. With a conventional 1500-byte Ethernet MTU, IPv4, and a TCP header without options, each full-size segment carries 1,460 bytes of TCP payload. The complete Ethernet transmission consumes 1,538 bytes on the wire: a 1,518-byte Ethernet frame (14-byte header, 1,500-byte payload, and 4-byte frame check sequence), plus an 8-byte preamble and start-frame delimiter and a 12-byte inter-frame gap.

TCP payload efficiency = 1,460 / 1,538 = 94.93%

Theoretical TCP goodput = 1,000 Mbit/s x 94.93% = 949.3 Mbit/s

This calculation assumes full-size TCP segments and excludes TCP options, ARP traffic, and application-level framing. IPv6, TCP timestamps, smaller writes, and short packets reduce the payload efficiency further. Conversely, this overhead is normally amortised effectively for large streaming transfers.

Linux testing of the PolarFire SoC GEM interface has produced approximately 580-620 Mbit/s of usable TCP payload throughput, with about 610 Mbit/s as the typical result. This is approximately 64.3% of the 949.3 Mbit/s standard-MTU theoretical TCP goodput, reflecting the practical limits of the software, DMA, memory, and protocol-processing path rather than the 1 Gbit/s Ethernet PHY alone. At the 200 Mbit/s SpaceWire line rate, four simultaneously bidirectional SpaceWire links require approximately 568.9 Mbit/s of aggregate TCP payload bandwidth:

4 links x 142.22 Mbit/s per receive direction = 568.88 Mbit/s

At a 1,460-byte TCP payload size, this traffic consumes approximately 599.3 Mbit/s on the Ethernet wire. It fits within the measured 610 Mbit/s TCP payload throughput, leaving approximately 41.1 Mbit/s (6.7%) of payload headroom for the traffic pattern and gateway framing. The PolarFire SoC provides two GEM interfaces, allowing the design to distribute four SpaceWire links to each Ethernet interface. To operate all eight links concurrently with equivalent bidirectional traffic, the SpaceWire line rate is configured at 160 Mbit/s. This reduces the per-direction payload budget to approximately 113.78 Mbit/s and the aggregate receive bandwidth of four links on one GEM to approximately 455.1 Mbit/s:

4 links x (160 Mbit/s x 8/10 x 8/9) = 455.11 Mbit/s

Using the second MSS Ethernet interface therefore increases the gateway from four to eight SpaceWire ports while keeping the aggregate traffic within the demonstrated TCP/IP capacity of each GEM.

Why TCP/IP is appropriate for this gateway

TCP/IP is well suited to the gateway’s purpose: transferring SpaceWire data from embedded hardware to Linux-hosted applications over conventional Ethernet infrastructure. It allows the same gateway to be accessed through standard network equipment and operating-system interfaces, rather than requiring a dedicated host adapter or a custom userspace network stack.

TCP provides an ordered, reliable byte stream. It detects lost or corrupted Ethernet frames, acknowledges received data, retransmits missing data, and applies end-to-end flow control when an application cannot keep up. These properties are valuable when SpaceWire data is transported across a host network, where packets may be delayed, dropped, or reordered beyond the direct SpaceWire link. TCP also permits multiple independent client connections, which makes it practical to separate telemetry, commanding, monitoring, and test tools without changing the SpaceWire hardware interface.

The gateway retains responsibility for the real-time boundary between the two transports. SpaceWire packets are discrete packets, whereas TCP is a byte stream and does not preserve message boundaries. The gateway protocol therefore includes packet framing and length information so that the receiving application can reconstruct each original SpaceWire packet. Receive buffers and DMA descriptors absorb short scheduling delays in Linux, while the gateway manages back-pressure and descriptor availability at the SpaceWire side.

TCP/IP is not intended to replace SpaceWire’s deterministic link behaviour inside the embedded system. Instead, it provides a reliable and interoperable interface at the system boundary: SpaceWire is used where low-latency point-to-point transport is required, and TCP/IP is used where data must be delivered to standard Linux applications, development tools, and network-connected ground-support equipment.