🏠

平台验证 PL 参考数据搬运器 (Platform Validation PL Reference Data Movers)

这个模块提供了一对 HLS 内核——MM2S（Memory-to-Stream）和 S2MM（Stream-to-Memory）——作为验证 Versal 平台数据通路的基础"管道工"。想象你正在验收一栋新房的水电系统：你不会直接搬进去住，而是先用水压测试仪检查管道是否漏水。这对内核就是硬件平台的"水压测试仪"：它们不做任何数据处理，只是单纯地把数据从 A 点搬到 B 点，帮助验证 PS（处理系统）、PL（可编程逻辑）和 AI 引擎之间的数据通路是否畅通、时序是否收敛、带宽是否达标。

架构全景

flowchart LR subgraph Host["Host (x86/ARM)"] B1["Source Buffer"] B2["Destination Buffer"] end subgraph Device["Versal Device"] subgraph PL["PL (Programmable Logic)"] M["mm2s_1
AXI MM -> AXI Stream"] S["s2mm_1
AXI Stream -> AXI MM"] end subgraph AI_E["AI Engine (Optional)"] P["Processing Kernel"] end end B1 -->|XRT| M M -->|axis| S M -.->|axis| P P -.->|axis| S S -->|XRT| B2 style M fill:#e1f5fe style S fill:#e1f5fe

组件职责

MM2S (mm2s_1)：从全局内存（DDR 或 PLRAM）读取数据，通过 AXI4-Stream 接口输出。它扮演"数据源"的角色，将平面化的内存数据转换为流式数据包，供下游处理单元消费。

S2MM (s2mm_1)：从 AXI4-Stream 接口接收数据，写入全局内存。它扮演"数据汇"的角色，将流式数据重新打包成连续的内存缓冲区，供主机读取。

这两个内核通常成对使用，构成一个"回环"测试通路：主机写入源数据 → MM2S 读入并输出为流 → S2MM 接收流并写回内存 → 主机读取并验证。如果数据完整无损，说明平台的数据通路（DMA、AXI 互连、内存控制器）工作正常。

数据流深度追踪

让我们跟随一个 4KB 的数据块，看看它从主机应用到验证完成的完整旅程：

1. 主机端准备（Host Setup）

// 主机代码（概念性示例）
size_t buffer_size = 4096;
auto src_buf = xrt::bo(device, buffer_size, mm2s.group_id(0));
auto dst_buf = xrt::bo(device, buffer_size, s2mm.group_id(0));

// 填充测试数据
std::vector<uint32_t> test_data(buffer_size / sizeof(uint32_t));
std::iota(test_data.begin(), test_data.end(), 0); // 0, 1, 2, ...
src_buf.write(test_data.data());
src_buf.sync(XCL_BO_SYNC_BO_TO_DEVICE);

这里，主机分配了两个缓冲区：src_buf 作为 MM2S 的源，dst_buf 作为 S2MM 的目的地。XRT（Xilinx Runtime）负责管理这些设备缓冲区的主机端内存分配和设备端地址映射。

2. 内核配置与启动（Kernel Launch）

// 设置 MM2S 参数：源缓冲区地址、读取长度、控制寄存器
mm2s(src_buf, buffer_size, /*control*/ 0);
// 设置 S2MM 参数：目的缓冲区地址、写入长度、控制寄存器  
s2mm(dst_buf, buffer_size, /*control*/ 0);

// 启动执行
mm2s.start();
s2mm.start();

// 等待完成
mm2s.wait();
s2mm.wait();

XRT 通过 AXI4-Lite 控制接口将参数写入内核的寄存器空间。MM2S 接收到源地址（64 位，由 syn.interface.m_axi_addr64=1 启用）和传输长度，开始从全局内存读取。

3. 设备端数据流（Device-Side Data Flow）

主机内存 (DDR)
    |
    | AXI4-Full (m_axi)
    v
[MM2S Kernel] 
    - 内部生成读地址（源地址递增）
    - 通过 m_axi 读取 64 字节突发（由 AXI 协议优化）
    - 数据进入内部 FIFO
    |
    | AXI4-Stream (axis)
    v
    数据包流（无地址，只有数据和有效信号）
    |
    v
[S2MM Kernel]
    - 从 axis 接收数据
    - 内部生成写地址（目的地址递增）
    - 数据进入写 FIFO
    |
    | AXI4-Full (m_axi)
    v
主机内存 (DDR)

这个流程展示了两个关键协议转换：

  • MM2S: 将基于地址的内存映射协议（AXI4-Full）转换为无地址的流协议（AXI4-Stream），剥离地址信息，只保留数据。
  • S2MM: 反向转换，为无地址的流数据重新生成地址信息，写回内存。

4. 验证完成（Verification）

// 同步设备缓冲区回主机
dst_buf.sync(XCL_BO_SYNC_BO_FROM_DEVICE);

// 读取并验证
std::vector<uint32_t> result(buffer_size / sizeof(uint32_t));
dst_buf.read(result.data());

if (test_data == result) {
    std::cout << "平台验证通过：数据完整性检查成功\n";
} else {
    std::cerr << "验证失败：数据不匹配\n";
}

如果源数据和目的数据完全一致，证明数据通路工作正常：DMA 控制器正确执行了读写，AXI 互连没有丢失数据，内存控制器工作正常，流控制信号（TLAST, TVALID, TREADY）被正确处理。

HLS 内核设计与配置详解

这两个内核的配置文件（.cfg）揭示了它们在 Vitis HLS 中的综合策略和优化目标。

内存接口策略（Interface Strategy）

syn.interface.m_axi_addr64=1
syn.interface.m_axi_auto_max_ports=0
syn.interface.m_axi_conservative_mode=1

这三项配置揭示了设计者对稳定性优先于峰值性能的明确选择：

64 位地址空间 (m_axi_addr64=1): 启用 64 位寻址，支持超过 4GB 的内存空间。这对于现代 Versal 平台的大容量 DDR 是必需的，允许内核访问整个设备内存空间。

自动端口扩展关闭 (m_axi_auto_max_ports=0): 禁止 HLS 工具自动为内存接口创建多个独立端口以并行访问。虽然多端口可以提高带宽，但会增加 AXI 互连的复杂性和资源消耗。关闭自动扩展意味着设计者接受更简单的拓扑，依赖 AXI 突发传输的效率而非并行端口。

保守模式启用 (m_axi_conservative_mode=1): 这是最影响性能但保证稳定性的设置。保守模式会限制 AXI 接口的突发长度和 outstanding transactions 数量，确保即使在较差的路由和时序条件下也不会违反协议。代价是带宽利用率降低（突发更短，等待时间更长）。

设计权衡: 这三个设置共同传达了一个信号：这些内核的首要目标是作为可靠的"参考基准"，而非性能优化的生产内核。在平台验证阶段，我们关心的是"数据能否正确传输"，而不是"能否达到理论峰值带宽"。保守设置确保了即使平台存在轻微时序偏差或布局拥挤，验证测试仍能通过（或能正确识别出真正的硬件故障而非时序收敛问题）。

数据流与时序策略（Dataflow Strategy）

syn.dataflow.strict_mode=warning

数据流（DATAFLOW）是 HLS 中实现任务级并行的关键优化，允许函数或循环以流水线方式并发执行。严格模式通常要求明确的生产者-消费者契约，防止潜在的死锁或数据竞争。

设置为 warning（而非 error）允许 HLS 工具在检测到潜在数据流违规时发出警告但继续综合。这再次体现了验证优先的哲学：我们更关心生成一个能运行的比特流来测试平台，而不是追求完美的 HLS 代码结构。这种宽松设置便于快速迭代和实验，代价是可能需要人工检查警告以确保没有真正的功能缺陷。

调试与可观测性（Debuggability）

syn.debug.enable=1
syn.rtl.deadlock_detection=sim
syn.rtl.kernel_profile=1
package.output.syn=true

这些配置将内核从"精简生产版"转变为"诊断工具"：

调试信息启用 (syn.debug.enable=1): 在生成的 RTL 中插入调试探针，允许在 Vivado 仿真或硬件调试会话中查看内部信号状态。这对于定位数据流停滞、AXI 协议违规或数据损坏至关重要。

死锁检测 (syn.rtl.deadlock_detection=sim): 在仿真中启用死锁检测逻辑，当数据流因循环依赖或协议违规而停滞时立即报警。在平台验证阶段，我们想知道平台是否能在任何情况下保持数据流动。

性能分析 (syn.rtl.kernel_profile=1): 插入性能计数器，测量内核实际运行时的带宽、延迟和利用率。这允许我们回答关键问题："平台实际达到了多少带宽？是内核瓶颈还是平台瓶颈？"

综合输出 (package.output.syn=true): 确保输出综合后的 RTL 报告，允许人工检查时序收敛、资源利用和性能估计。

设计权衡: 所有这些调试功能都消耗额外的芯片面积（探针、计数器、额外的逻辑），可能轻微降低性能，并显著增加比特流生成时间。在生产内核中，这些通常会被禁用以追求最小面积和最高性能。但对于平台验证参考内核，这些信息是主要交付物——我们需要通过这些工具来"看到"平台内部的行为。

在系统中的角色与依赖关系

与 AI 引擎开发的关联

从组件依赖关系可见，这两个 PL 内核被设计用于配合 AI 引擎（AIE）教程使用，特别是 02-super_sampling_rate_fir（超采样率 FIR 滤波器）设计教程。

External deps: AI_Engine_Development.AIE.Design_Tutorials.02-super_sampling_rate_fir.DualSSR16_hw.sw.Makefile.aie_control_xrt.cpp

这表明 platform_validation_pl_reference_data_movers 是 Versal 平台验证的"配套基础设施"。在实际系统中：

  1. MM2S 从 DDR 读取输入样本流，发送到 AI 引擎阵列进行 FIR 滤波处理
  2. AI 引擎 执行实际的数字信号处理（超采样率 FIR 计算）
  3. S2MM 从 AI 引擎接收处理后的样本流，写回 DDR

这种分工是 Versal ACAP 架构的典型范式：PL 处理数据搬运和 I/O，AI 引擎处理计算密集型算法。参考数据搬运器允许开发者在集成复杂 AI 引擎逻辑之前，先验证 PL-PS-DDR 这一"下半层"数据通路是否可靠。

与平台验证 AIE 参考数据搬运器的对比

模块树中显示有相邻模块 platform_validation_aie_reference_data_movers（注意是 AIE 而非 PL）。这暗示存在两个层次的验证：

  • PL 验证（本模块）：使用 HLS 编写的 PL 内核，验证 PL 逻辑、DMA 和 AXI 互连
  • AIE 验证（兄弟模块）：可能使用 AI 引擎内核或更简单的 AIE 数据搬运器，验证 AI 引擎阵列的接口和调度

这种分层验证策略允许问题隔离：如果 PL 验证通过但 AIE 验证失败，问题可能在 AIE 接口；如果 PL 验证就失败，问题在更基础的 DMA 或内存子系统。

与 HLS FFT 教程的潜在关联

模块树中 prime_factor_fft_hls_kernels 下包含 fft_dma_data_movers（dma_source_kernel 和 dma_sink_kernel），这些与本模块的数据搬运器在功能上类似，但针对 FFT 的特定数据重排需求进行了定制。

这种关系表明 platform_validation_pl_reference_data_movers 是通用参考实现，而 FFT 或其他特定算法教程中的数据搬运器是派生实现，增加了特定领域的优化（如位反转寻址、循环缓冲区管理等）。

使用模式与集成指南

基本使用流程

作为平台验证工具，这对内核的典型使用遵循以下步骤：

  1. 综合与打包

    # 使用 Vitis HLS 综合 MM2S 内核
vitis_hls -f mm2s.cfg

# 使用 Vitis HLS 综合 S2MM 内核  
vitis_hls -f s2mm.cfg

# 输出: mm2s_1.xo, s2mm_1.xo (Vitis 内核对象)

  2. 系统集成

    # 使用 v++ 链接器集成到平台
v++ -l -t hw_emu -g -o platform_test.xclbin \
    mm2s_1.xo s2mm_1.xo --config system.cfg

  3. 主机应用

    // 打开设备并加载 xclbin
auto device = xrt::device(0);
auto uuid = device.load_xclbin("platform_test.xclbin");

// 实例化内核
auto mm2s = xrt::kernel(device, uuid, "mm2s_1");
auto s2mm = xrt::kernel(device, uuid, "s2mm_1");

// 分配缓冲区
size_t size = 4096;
auto src = xrt::bo(device, size, mm2s.group_id(0));
auto dst = xrt::bo(device, size, s2mm.group_id(0));

// 初始化测试数据
std::vector<uint32_t> gold(size / sizeof(uint32_t));
std::iota(gold.begin(), gold.end(), 0);
src.write(gold.data());
src.sync(XCL_BO_SYNC_BO_TO_DEVICE);

// 启动内核
auto run_m = mm2s(src, size, 0); // buffer, size, control
auto run_s = s2mm(dst, size, 0);

// 等待完成
run_m.wait();
run_s.wait();

// 验证结果
dst.sync(XCL_BO_SYNC_BO_FROM_DEVICE);
std::vector<uint32_t> result(size / sizeof(uint32_t));
dst.read(result.data());

if (gold == result) {
    std::cout << "PASS: 平台数据通路验证成功\n";
} else {
    std::cerr << "FAIL: 数据不匹配，平台存在问题\n";
}

与 AI 引擎集成模式

当用于 AI 引擎系统验证时，数据流稍有不同：

Host Buffer -> MM2S -> [AXI Stream] -> AI Engine Array (FIR/FFT/etc) -> [AXI Stream] -> S2MM -> Host Buffer

在这种配置中：

  • MM2S 的输出直接连接到 AI 引擎的 PLIO 接口（而非 S2MM）
  • AI 引擎处理后的输出连接到 S2MM 的输入
  • 主机需要协调两个内核与 AI 引擎图的同步启动

这种集成模式的关键挑战是流控制（Flow Control）：AI 引擎的处理速率可能与 PL 数据搬运器不匹配。如果 AI 引擎处理较慢，它需要反压（backpressure）MM2S 的 AXI Stream 接口（通过 TREADY 信号）。反之，如果 AI 引擎输出过快，S2MM 必须能够反压 AI 引擎。

在平台验证阶段，使用简单的直通模式（MM2S 直接连 S2MM）可以验证 PL 侧的反压逻辑是否正常工作。当加入 AI 引擎后，如果出现问题，可以定位到 AI 引擎接口或 PL-AIE 边界，而非基础 DMA 通路。

关键设计决策与权衡

1. 保守时序 vs. 峰值性能

配置中的 syn.interface.m_axi_conservative_mode=1 是一个关键权衡。在 HLS 中，AXI 接口的保守模式会：

  • 减少每个突发传输的最大长度，防止过长的占用总线时间
  • 限制未完成的传输数量（outstanding transactions），降低对 AXI 互连的缓冲压力
  • 放宽时序要求，给布局布线工具更大的松弛度

代价：理论峰值带宽下降，因为更短的突发意味着更多的地址阶段开销，更少的连续数据传输。

收益：时序收敛更加稳健，对平台的速度等级变化、温度漂移和工艺偏差更不敏感。

为什么接受这个权衡？ 因为这些是验证内核，不是生产内核。在验证阶段，我们需要的是"在所有条件下都能工作的确定性"，而不是"在理想条件下达到最高速度"。如果验证内核在保守模式下失败，我们知道是平台有硬件问题；如果在激进模式下失败，我们不知道是平台问题还是时序太紧。

2. 调试设施 vs. 资源消耗

配置中启用了大量调试和性能分析设施：

syn.debug.enable=1
syn.rtl.deadlock_detection=sim
syn.rtl.kernel_profile=1
package.output.syn=true

这些选项会：

  • 插入额外的硬件探针，捕捉内部信号状态（增加 LUT/FF 使用）
  • 生成死锁检测逻辑，监控数据流停滞（增加复杂性）
  • 添加性能计数器，测量带宽和延迟（增加寄存器）
  • 输出详细综合报告，供人工分析时序和面积

代价：生成的 RTL 更大、更慢、更耗电。对于资源受限的设备，这些开销可能限制其他逻辑的实现。

收益：获得了对内核内部行为的完全可观测性。当平台验证失败时，我们可以精确看到数据在哪里停滞（是 MM2S 读内存卡住了，还是 S2MM 写内存卡住了？是 AXI 读通道没响应，还是流控制信号没握手？）。

为什么接受这个权衡？ 因为这些内核的价值在于诊断信息，而非它们执行的功能本身。一个不能告诉你它怎么失败的验证工具，在复杂硬件调试中几乎无用。在生产内核中，我们会移除这些调试设施以节省资源，但在验证阶段，我们"用面积买时间"（减少调试时间）。

3. 严格数据流检查 vs. 工具灵活性

syn.dataflow.strict_mode=warning

HLS 的数据流优化（#pragma HLS DATAFLOW）允许不同的函数或循环体并发执行，形成流水线。严格模式通常要求代码严格遵守生产者-消费者契约，防止潜在的死锁。

设置为 warning 意味着：

  • 工具允许一些边界情况的数据流拓扑，这些在严格模式下会被视为错误
  • 综合将继续，生成 RTL，而不是在检测到潜在问题时停止
  • 警告信息会被输出，提示工程师注意潜在问题

代价：生成的硬件可能在某些边界条件下出现未定义行为，或者数据流停滞（如果代码确实有缺陷但工具没有强制修复）。

收益：允许快速迭代，即使代码不是完美的数据流范式，也能生成可测试的硬件。对于参考设计和教程代码，这降低了学习门槛。

为什么接受这个权衡？ 因为这些是教学/验证内核，不是安全关键生产代码。我们更愿意生成一个"可能有问题但能跑"的设计，然后测试它是否真的有问题，而不是因为一个潜在的数据流警告就阻止整个验证流程。在真正的生产代码中，我们会修复所有警告，或者将严格模式设为 error。

新贡献者指南：陷阱与最佳实践

1. 区分"验证内核"与"生产内核"

最常见的错误：将这些参考数据搬运器视为性能基准，试图优化它们以达到理论峰值带宽。

真相：这些内核被故意配置为保守和可观测，而非快速。它们的目标是回答"平台能否正确搬运数据？"，而不是"平台能搬运多快？"。如果你发现这些内核的带宽低于预期，首先检查配置中的保守模式、调试设施和数据流严格性设置——这些都是故意的性能取舍。

最佳实践：如果你需要为实际应用开发高性能数据搬运器，应该：

  • 移除 conservative_mode，允许更长的 AXI 突发
  • 禁用 debug.enable 和 kernel_profile 以减少资源占用
  • 考虑手动控制 AXI 端口数量 (m_axi_auto_max_ports) 以提高并行度
  • 使用 strict_mode=error 确保数据流正确性

2. 理解 AXI Stream 的隐式契约

MM2S 和 S2MM 通过 AXI4-Stream 接口连接（可能在芯片内部直接连接，或通过 AI 引擎中转）。这个接口有一个隐式契约，容易被忽视：

数据包边界（Packet Boundary）：AXI Stream 使用 TLAST 信号标记数据包的最后一个字节。MM2S 在传输完指定数量的字节后会断言 TLAST。下游的 S2MM（或 AI 引擎）依赖这个信号来识别传输结束。

陷阱：如果在系统集成时修改了 MM2S 或 S2MM 的 RTL，改变了 TLAST 的生成逻辑，可能导致 S2MM 提前终止或无限等待。同样，如果连接的 AI 引擎逻辑不处理 TLAST 而直接传递，可能导致数据包边界丢失。

最佳实践：

  • 在验证阶段，使用协议分析器（如 ChipScope 或仿真中的 AXI VIP）监控 TVALID、TREADY、TLAST 的握手
  • 确保 MM2S 传输长度与 S2MM 预期接收长度匹配，或者实现显式的流控制协议
  • 如果通过 AI 引擎中转，确保 AI 引擎的 PLIO 接口正确处理 TLAST（或 TKEEP，如果使用字节掩码）

3. 内存对齐与突发传输的微妙之处

虽然配置启用了 64 位地址，但 AX AXI 突发传输的性能高度依赖于地址对齐和数据长度。

对齐要求：AXI4-Full 接口的最佳突发性能通常在 4KB 边界对齐的地址上实现（因为典型的 AXI 互连和内存控制器使用 4KB 页面或行大小）。如果 MM2S 的源地址或 S2MM 的目的地址没有对齐到缓存行边界（通常 64 字节），AXI 互连可能需要拆分突发，显著降低有效带宽。

陷阱：主机代码使用 xrt::bo 分配的缓冲区通常会自动对齐到设备要求的边界（通常是 4KB），但如果主机代码手动管理内存或使用 xrt::bo 的 flags 参数不当，可能导致次优对齐。

最佳实践：

  • 始终使用 XRT 的缓冲区对象 (xrt::bo) 而非裸指针，确保正确的设备内存分配和对齐
  • 如果可能，将传输大小设置为 AXI 突发长度（通常为 16 拍 × 64 字节 = 1KB，或更长）的整数倍
  • 在性能分析阶段，使用 XRT 的 profiling API 或内核的性能计数器（kernel_profile=1 启用）检查实际带宽与理论带宽的差距，识别是否因对齐问题导致性能下降

4. 理解保守模式的隐性假设

配置中的 conservative_mode=1 是一个"安全网"，但新贡献者需要理解它隐含的假设：

假设：平台可能存在轻微的时序违规、布局拥挤或信号完整性问题，但基本功能正常。

影响：保守模式通过限制突发长度和未完成事务数，减少了 AXI 互连的瞬时负载，降低了因时序问题导致的数据损坏风险。但它也掩盖了平台的真实带宽能力和时序余量。

陷阱：如果在保守模式下验证通过，开发者可能误以为平台"完全健康"。实际上，平台可能存在接近临界点的时序路径，在生产内核的激进 AXI 配置下可能暴露出问题。

最佳实践：

  • 将保守模式视为"通过/失败"的筛选器：如果在此模式下失败，平台有硬件或基础配置问题
  • 如果在此模式下通过，应进行第二阶段测试：逐步关闭保守设置（启用更长突发、更多未完成事务），测量平台的真实带宽上限和时序余量
  • 记录平台在保守模式下的性能基线，作为后续生产内核设计的参考（"生产内核不应期望超过参考内核 X 倍的带宽"）

5. 调试设施的性能开销意识

配置中启用的调试和性能分析设施（debug.enable=1, deadlock_detection=1, kernel_profile=1）在硬件中插入了额外的逻辑。

资源开销：这些设施通常消耗额外的 LUT（查找表）和 FF（触发器）来实现计数器、状态机和探针。在资源受限的小型设备上，这可能导致布局布线困难或时序恶化。

性能开销：性能计数器和调试探针可能增加关键路径的延迟，或引入额外的流水线级数，轻微降低最大运行频率（Fmax）。死锁检测逻辑可能增加数据通路的握手延迟。

陷阱：新贡献者可能将这些参考内核视为"标准实现"，直接复制到资源受限的生产设计中，然后困惑于为何资源利用率过高或无法收敛时序。

最佳实践：

  • 始终检查配置文件中的调试设置，理解它们对资源使用的影响
  • 如果将此设计作为自定义数据搬运器的起点，应创建一个"发布版"配置，移除所有调试设施：syn.debug.enable=0, syn.rtl.kernel_profile=0, 移除 deadlock_detection
  • 在资源规划阶段，为调试设施预留 10-20% 的额外 LUT/FF 余量（具体取决于 HLS 版本和目标设备）
  • 如果时序收敛困难，尝试关闭 kernel_profile，因为性能计数器通常是关键路径上的主要负担

总结：作为平台验证基石的设计哲学

platform_validation_pl_reference_data_movers 模块体现了硬件平台开发中的一个核心原则：验证基础设施应该优先考虑确定性、可观测性和可靠性，而非峰值性能。

这对 HLS 内核不是为生产工作负载设计的"最终产品"，而是为平台本身设计的"诊断工具"。它们的存在是为了回答三个基本问题：

  1. 连通性：数据能否从主机内存，经过 DMA 和 AXI 互连，到达 PL 逻辑？
  2. 完整性：数据在传输过程中是否保持不变（无位翻转、无丢失、无乱序）？
  3. 时序稳定性：在当前速度等级和温度条件下，数据通路是否能持续稳定工作？

通过保守的 AXI 配置、全面的调试设施和严格的代码生成选项，这对内核确保了当平台验证通过时，开发者可以对底层数据通路的健康度有高度信心。当验证失败时，丰富的调试和性能分析设施又能快速定位问题所在（是 DMA 配置错误？AXI 互连拥塞？还是内存控制器时序问题？）。

对于刚加入团队的新贡献者，理解这个模块的关键在于认识到它不是算法的实现，而是平台的验证。当你阅读这些 HLS 配置时，不要问"这段代码如何优化计算？"，而要问"这些设置如何帮助证明平台能可靠地搬运数据？"。这种思维转变将帮助你理解为什么看似"次优"的性能设置（保守模式、调试开销）在这里却是"最优"的设计选择。

在 Versal 平台的宏大图景中，这些参考数据搬运器是基础设施的基础设施——它们不处理信号、不运行神经网络，但它们证明了平台能够支持那些更复杂的任务。它们是数字世界的"水压测试仪"，在复杂的计算管道投入使用之前，确保基础数据 plumbing 是密封且可靠的。

On this page