把AES-256-GCM放进可编程逻辑还是交给硬化安全引擎，通常被当成资源与性能的取舍。SCU200评估平台上的一次实测给出了具体刻度：两条路径加密结果逐字节一致，但端点延迟相差14.7倍，LUT占用相差97.8%。
演示在SCU200上搭了一个单端口以太网端点：UDP帧从GEM0进入，载荷用AES-256-GCM加密，认证后的响应以1 Gb/s从同一线路返回。数据路径里没有处理器、没有MicroBlaze、没有ARP和TCP/IP协议栈，只做包头重建与端点交换。分流靠UDP目标端口完成，端口4000走PL流式实现，端口4001走PMC硬化引擎，切换不需要写寄存器、不需要软件介入，所选路径还会回显在认证头里。整个工程可用Vivado 2026.1从TCL重现，仓库附带Questa自检回归和Python主机校验工具。
两条路径各发500个包并全部校验，结果与独立软件AES-256-GCM进程逐字节一致。主机侧看到的平均往返时间是11.896 ms对11.988 ms，差距不到0.1 ms，已被Windows、Npcap和USB协议栈的抖动淹没。硬件计时才露出真相：PL引擎处理一个包1.304微秒，125MHz下约163个时钟周期；PMC路径19.4微秒、约2397个时钟周期，单包慢14.7倍。开销来自过桥、寄存器编程和存储转发缓冲，不是AES本身。吞吐上PL约76.7万包每秒，PMC约5.2万包每秒。
资源账同样直白：流式PL的AES-GCM层次占用31,618个LUT、4,227个触发器和126个RAMB18；完整PMC封装器含序列器、两个2,048字节暂存缓冲区、桥接AXI控制器和寄存器序列器，只用707个LUT、379个触发器和2个RAMB18，LUT减少97.8%，因为AES运算落在固定硬化硅片上。官方给出的选择原则是：需要持续线速和微秒级延迟、数据始终留在PL内，用流式实现；架构节省或固定硅片安全边界更重要，用PMC引擎。Spartan UltraScale+在同一器件上同时提供两条路。
对国内做板卡和高速接口的工程师，这次演示的价值不在某个IP，而在选型刻度：硬化安全引擎能显著压低逻辑占用，但事务式访问的延迟代价必须提前算进链路预算，尤其是多包连续负载场景。工具链侧，工程依赖Vivado 2026.1与SCU200板定义，主机侧要PowerShell、Python 3.10以上和Npcap，属于可复现但绑定特定器件的流程。若项目使用同系列Spartan UltraScale+，两条路径可并存，先按延迟和资源两条线分别评估再定；其他器件是否提供对等硬化引擎，素材未涉及。