Putting AES-256-GCM in programmable logic or handing it to the hardened security engine is usually treated as a resource-versus-performance trade-off. A measurement on the SCU200 evaluation platform gives concrete numbers: the two paths produce byte-identical encryption results, but endpoint latency differs by 14.7x and LUT usage differs by 97.8%.
The demo builds a single-port Ethernet endpoint on the SCU200: UDP frames enter through GEM0, the payload is encrypted with AES-256-GCM, and the authenticated response returns at 1 Gb/s over the same line. There is no processor, no MicroBlaze, and no ARP or TCP/IP stack in the data path—only header reconstruction and endpoint switching. Steering is done by UDP destination port: port 4000 uses the PL streaming implementation, port 4001 uses the PMC hardened engine. Switching requires no register writes and no software intervention, and the selected path is echoed in the authentication header. The entire project can be reproduced from TCL with Vivado 2026.1, and the repository includes a Questa self-checking regression and a Python host verification tool.
Each path sent 500 packets, all of which were verified, and the results were byte-identical to an independent software AES-256-GCM process. The average round-trip time observed on the host was 11.896 ms versus 11.988 ms—a gap of less than 0.1 ms, already swamped by jitter from Windows, Npcap, and the USB stack. Hardware timing reveals the real picture: the PL engine processes one packet in 1.304 microseconds, about 163 clock cycles at 125 MHz; the PMC path takes 19.4 microseconds, about 2,397 clock cycles, or 14.7x slower per packet. The overhead comes from crossing the bridge, register programming, and store-and-forward buffering, not from AES itself. Throughput is about 767,000 packets per second for PL and about 52,000 packets per second for PMC.
The resource accounting is equally blunt: the streaming PL AES-GCM hierarchy occupies 31,618 LUTs, 4,227 flip-flops, and 126 RAMB18s; the full PMC wrapper—including the sequencer, two 2,048-byte staging buffers, the AXI bridge controller, and the register sequencer—uses only 707 LUTs, 379 flip-flops, and 2 RAMB18s, a 97.8% reduction in LUTs, because the AES operations run on fixed hardened silicon. The official selection guidance is: use the streaming implementation when sustained line rate and microsecond-level latency are required and data must remain inside the PL; use the PMC engine when architectural savings or a fixed-silicon security boundary matter more. Spartan UltraScale+ offers both paths on the same device.
For engineers in China working on boards and high-speed interfaces, the value of this demo is not in any particular IP but in the selection scale: a hardened security engine can significantly reduce logic usage, but the latency cost of transactional access must be budgeted into the link ahead of time, especially in multi-packet sustained-load scenarios. On the toolchain side, the project depends on Vivado 2026.1 and the SCU200 board definition, and the host side requires PowerShell, Python 3.10 or later, and Npcap—a reproducible flow, but tied to a specific device. If a project uses the same Spartan UltraScale+ family, the two paths can coexist; evaluate latency and resources separately before deciding. Whether other devices offer an equivalent hardened engine is not covered by the source material.