技术深度解析
Vidi的记录回放机制，是对FPGA开发中最棘手问题之一——非确定性调试——的回应。当FPGA设计失败时，失败往往取决于时钟周期、输入信号和内部状态转换的确切序列。传统的调试方法，如使用集成逻辑分析仪（ILA）或对布局布线后的时序模型进行仿真，要么太慢（仿真），要么侵入性太强（ILA消耗FPGA资源并可能改变时序）。
Vidi在更高的抽象层级上运行。它的工作原理是拦截主机CPU与FPGA之间通过AWS F1实例上PCIe接口进行的通信。其核心思想是将所有输入事务——包括AXI事务、寄存器写入和内存映射I/O——记录到一个跟踪缓冲区中。当遇到错误时，工程师可以将该确切输入序列回放到FPGA设计中，强制硬件重新执行相同的状态转换。这在概念上类似于软件中的确定性回放调试（例如Mozilla的rr或UndoDB的LiveRecorder），但应用于硬件。
该架构可能涉及一个轻量级的垫片层，插入在AWS FPGA Shell（管理PCIe和DRAM的FPGA静态部分）与用户的Custom Logic（CL）之间。此垫片将所有事务记录到存储在FPGA片内BRAM或外部DDR中的环形缓冲区中。在回放期间，垫片将记录的事务注入回CL，绕过实际的主机接口。关键的工程挑战是确保回放真正具有确定性：垫片必须保证没有外部信号（如温度、电压下降或异步复位）影响回放路径。Vidi可能通过冻结CL在回放期间的时钟，并仅在注入记录的事务时推进时钟来实现这一点。
一个关键的限制是，Vidi仅记录跨越PCIe边界的事务。它无法捕获并非由主机I/O触发的内部信号毛刺或状态变化。这意味着它对于调试与主机-FPGA通信、内存控制器交互或由输入流驱动的数据路径流水线相关的错误最为有效。对于由内部组合环路或亚稳态引起的错误，仍然需要传统的仿真或片上调试。
该项目托管在GitHub上的`efeslab/aws-fpga`仓库中，该仓库是官方aws/aws-fpga仓库的一个分支。官方仓库拥有超过1100颗星，并由AWS积极维护。相比之下，Vidi分支仅有5颗星，看起来是一个公开的研究或内部工具。它尚未更新以跟踪最新的AWS FPGA开发者工具包（HDK）版本，该版本包含对更新的Xilinx Virtex UltraScale+ VU9P FPGA和改进的内存接口的支持。这意味着采用Vidi的用户可能被困在较旧的工具链上，并错过AWS的关键错误修复或性能改进。
数据要点： 社区采用率低（5颗星 vs. 官方仓库的1100+颗星）表明Vidi要么知名度不高，要么尚未准备好投入生产，要么用例非常狭窄。然而，这个概念本身很有价值，如果集成到官方AWS HDK中，它可能会迅速获得采用。
关键参与者与案例研究
该领域的主要利益相关者是FPGA云提供商（AWS、Microsoft Azure、Alibaba Cloud）和FPGA工具供应商（Xilinx/AMD、Intel/Altera）。AWS凭借其使用Xilinx FPGA的EC2 F1实例，在云FPGA领域占据主导地位。官方aws/aws-fpga仓库是在这些实例上进行开发的事实标准。它提供了用于构建和运行自定义逻辑的HDK（硬件开发工具包）和SDK（软件开发工具包）。
Vidi由代号为“efeslab”的团体或个人开发。确切隶属关系尚不清楚，但该项目似乎来自学术或研究实验室。它代表了为解决AWS自身尚未优先解决的问题而做出的草根尝试。AWS的官方调试支持仅限于Xilinx的Vivado工具和AWS ILA（集成逻辑分析仪）IP，这些工具功能强大，但缺乏记录回放功能。
为了理解Vidi的定位，将其与现有的调试方法进行比较是有益的：
| 调试方法 | 确定性回放 | 资源开销 | 调试范围 | 设置复杂度 |
|---|---|---|---|---|
| Vidi记录回放 | 是（针对主机事务） | 低（CL中的垫片） | 主机-FPGA接口 | 中等（需要分支） |
| Xilinx ILA（Vivado） | 否 | 高（使用BRAM/FF） | 任何内部信号 | 高（需要重新综合） |
| 仿真（例如VCS、Questa） | 是 | 无（离线） | 整个设计 | 低（但速度慢） |
| AWS FPGA Shell调试（例如`fpga-describe-local-image`） | 否 | 无 | 状态寄存器 | 低 |
数据要点： Vidi占据了一个独特的利基——具有低资源开销的确定性回放——但其范围仅限于主机事务。