Keep the CPU Out of the Data Path: RDMA, RoCEv2 and RNIC in High-Bandwidth Media Systems
Ahead of IBC2026, a look at the part of the broadcast pipeline that gets less attention than it deserves: how video data actually moves between the parts of a system.
Managing Director & Tech Advisor
at Promwad GmbH
We spend a lot of design time on codecs, resolution, and end-to-end latency. But before any frame is processed, it has to travel between the FPGA, the server, the GPU, memory, and the network.
Those buffers are no longer small. A single uncompressed UHD 4Kp60 flow carries roughly 9.6 Gbps of 10-bit 4:2:2 video essence — with RTP/IP/Ethernet overhead and the associated essences, a full 10–12 GbE provisioned for one picture. HD sits at about 2.4 Gbps. Multiply by the number of flows in a facility and the arithmetic gets uncomfortable fast.
The traditional approach is to copy that data through the CPU and the operating system network stack. It works, but it spends processing cycles on moving bytes rather than on the actual video work, and every copy, context switch and interrupt adds variance. In broadcast, variance is the real problem. Systems here don't just need low latency; they need latency you can predict.
One technology, and the two layers that make it usable
The technology: RDMA (Remote Direct Memory Access) lets one node read or write another node's memory without involving the CPU or the operating system on the data path. Buffers are registered once; transfers are issued directly to the transport engine, and the kernel is bypassed entirely. The result is less copying, lower latency, and more stable throughput under load.
RDMA grew up in high-performance computing, where this problem surfaced first: the interconnect was fast enough, but the host software in the middle was not.
The standard: RoCEv2 (RDMA over Converged Ethernet v2) is the open specification, published by the InfiniBand Trade Association, that defines how RDMA is carried over ordinary Ethernet — encapsulated in UDP/IP.
That one decision is what makes it practical for broadcast: UDP/IP is routable, so the same mechanism scales beyond a single rack, across switches and between rooms, on the network infrastructure a facility already operates. No separate fabric, no second cabling plant.
The implementation: an RNIC inside the FPGA. The endpoint that terminates RoCEv2 in hardware is an RNIC — an RDMA-enabled network interface controller. In the data centre this is normally an ASIC-based adapter on a server's PCIe bus, and for server-to-server traffic that is exactly right. For broadcast it is the wrong place.
The broadcast data does not originate in host memory; it originates in the FPGA, where ST 2110 or SDI is deserialised, framed and processed. Putting the RNIC behind a PCIe hop reintroduces the staging we set out to eliminate. So the question we started from was narrower: which RDMA implementations put the RNIC inside the FPGA itself?
ERNIC (Embedded RDMA Enabled NIC) is AMD's answer to that question. It is a hardware IP core that places the full RoCEv2 and RDMA transport inside the FPGA or Adaptive SoC — queue pair handling, packetisation and reliability all live in programmable logic, adjacent to the video pipeline. There is no host NIC in the path and no software transport layer to schedule, the data movement is deterministic because it is implemented in hardware.
ERNIC Core IP block diagram. Source: ERNIC™ AMD Profile
Read together: a technology that removes the copy, an open standard that makes it routable, and an implementation that puts both in the same silicon as the video pipeline.
What this looks like in a media system
The same building blocks support several distinct data paths:
- FPGA to remote host — ST 2110 ingest and capture feeding a processing cluster without staging every frame through host memory (see MXL SDK integration).
- Remote host to FPGA — playout, graphics insertion and encoder offload, where the accelerator has to be fed continuously and on time.
- Distributed accelerator pools — several FPGA nodes shared as a common resource across a facility rather than dedicated per channel.
In each case the pattern is the same: large video buffers move with low and, more importantly, predictable overhead.
Where the real engineering sits
RoCEv2 is mature, but it is not plug-and-play. Performance depends on the network beneath it: priority flow control and ECN configured correctly across every switch in the path, congestion behaviour tuned for bursty video rather than storage traffic, MTU and pacing chosen so RDMA traffic coexists with ST 2110-21 shaping and PTP timing rather than fighting it.
A zero-copy data path is only as deterministic as the fabric carrying it. That integration work — across RTL, drivers, network configuration and system validation — is where projects succeed or stall.
Where Promwad fits
Promwad is a European R&D partner for OEMs and product companies, with 22+ years in electronics design services and a team of 100+ engineers. High-throughput data movement on AMD FPGA and Adaptive SoC platforms is one of the areas our broadcast team works in, covering the full path: architecture and feasibility, ERNIC IP integration, DMA and datapath RTL, driver and verbs-level software, board design, and benchmarking under realistic media load.
Hardware design and embedded systems development sit under one roof, which matters here, because the failure modes in RDMA systems rarely respect the boundary between the two.
Client Review
Talk to our engineers
If you are a broadcaster, operator or OEM planning your next modernisation step, the question worth asking is not how to get more out of the CPU, it is how to keep the CPU out of the data path almost entirely.
Book an Expert Call with our FPGA and broadcast engineers, or meet us in person at IBC 2026, 11–14 September, RAI Amsterdam — Made in Germany hall, booth 8.C32c.
Book a meeting with the Promwad team at IBC 2026:
Our Case Studies
