《FPGA Horizons Journal》第四期继续关注 FPGA 与 Adaptive SoC 的实际工程问题。本期内容从芯片供应链、云端 FPGA 安全、高性能 FPGA/SoC 架构，到老旧 FPGA 平台迁移、PCB 信号完整性、AI 辅助 EDA、UVVM 验证、空间辐射可靠性以及开源 FPGA 库，覆盖了 FPGA 开发从器件选择、架构设计、板级实现，到验证、安全和软件生态的多个环节。官网目前列出的 Issue 4 共 9 篇文章。

之前几期请查看：

00|近期时讯

本期没有。

01｜芯片短缺意味着 FPGA 设计需要一个 Plan B

Matt Hilbert，FPGA Horizons Journal Editor

FPGA 项目通常具有较长的开发周期，而 FPGA 本身又属于高度依赖供应链的器件。当某一型号 FPGA 出现供货紧张、生命周期变化或者交期不可控时，已经完成的硬件设计可能会面临重新选型甚至重新设计的问题。因此，这篇文章讨论的重点并不仅仅是“芯片短缺”，而是一个更现实的工程问题：FPGA 设计是否应该从一开始就考虑替代方案？

所谓 Plan B，并不是简单准备一颗备用 FPGA，而是需要在架构设计阶段考虑器件之间的可迁移性，包括逻辑资源、I/O、电气特性、封装、存储器接口以及 IP 和工具链等因素。对于复杂 FPGA 系统而言，如果设计过度依赖某一个具体器件，后期更换 FPGA 的成本可能非常高。

文章传递出的重要观点是，供应链风险应该进入 FPGA 项目的早期架构决策。与其等到芯片无法采购时再寻找替代方案，不如在设计之初就考虑第二器件、第二供应商或者可迁移架构。这样即使供应链发生变化，也能够通过预先规划降低重新设计的风险。

对于 FPGA 工程师来说，这实际上意味着“可迁移性”正在从一个软件层面的概念，变成硬件架构设计需要考虑的问题。

02｜如何让云端 FPGA “失效”

Dirk Koch，Heidelberg University

云 FPGA 的出现让用户可以像租用 CPU/GPU 一样远程使用 FPGA，但这种模式也带来了传统 FPGA 系统中不太明显的安全问题：当不同用户共享数据中心 FPGA 资源时，恶意用户是否能够通过 FPGA 配置影响硬件本身？

文章从一个非常反直觉的角度研究这个问题——不是想办法让 FPGA 工作得更高效，而是研究如何让 FPGA 尽可能消耗功率。研究人员通过构造高速振荡和局部高功耗结构，探索 FPGA 的功耗极限以及局部热点对器件可靠性的影响。相关研究甚至观察到了部分 FPGA 内部布线延迟明显增加的老化现象。

但文章最终得到的结论同样值得注意：现代数据中心 FPGA 并没有想象中那么容易被远程“烧坏”。研究虽然能够制造非常高的局部功耗和明显的器件应力，但由于 FPGA 内部结构本身具有较高的面积分散性，加上电源和热保护机制，很难简单地通过一个恶意用户设计直接永久摧毁整颗 FPGA。Adiuvo 对这项工作的总结也指出，研究更重要的价值在于揭示云 FPGA 的新攻击面，以及为什么需要设计扫描、资源限制和运行时健康监测机制。

因此，这篇文章真正值得关注的并不是“怎样破坏 FPGA”，而是它提醒云 FPGA 服务提供商：FPGA 的可编程性本身就是一个新的安全边界。云端 FPGA 需要像软件平台一样考虑恶意设计、资源隔离、功耗限制和运行状态监控。

03｜重新思考高性能 FPGA / Adaptive SoC 的构建方式

Mike Rather，AMD

随着 FPGA 逐渐发展为 Adaptive SoC，设计人员面对的已经不是简单的 LUT、BRAM 和 DSP 资源，而是处理器、可编程逻辑、高速互连、存储器以及 AI 加速资源组成的异构计算系统。

这篇文章从高性能 FPGA/Adaptive SoC 的架构角度出发，讨论如何重新思考系统构建方式。传统 FPGA 开发往往从 RTL 模块开始，然后逐步连接 IP、存储器和接口；但面对新一代异构器件，这种自底向上的设计方式越来越难以充分利用芯片资源。

因此，更重要的问题变成了：应该如何划分工作负载？哪些任务放在 CPU，哪些任务放在 FPGA Fabric，哪些任务适合专用加速资源？数据应该如何在这些计算单元之间移动？

文章所体现出的趋势是，现代 FPGA 的性能提升越来越依赖系统架构，而不是单纯提高时钟频率。尤其对于 Adaptive SoC，需要同时考虑计算、内存和数据移动，把整个系统作为一个统一的计算平台进行设计。

换句话说，未来 FPGA 性能优化的重点会逐渐从“怎么把 RTL 写快”，转向“怎么把整个异构系统组织得更合理”。

04｜从传统 FPGA 迁移到现代可扩展平台

Rachael Peterson，Concurrent Technologies Plc

大量工业和嵌入式系统仍然运行在较老的 FPGA 平台上。这些系统通常已经经过多年验证，硬件、FPGA 逻辑和软件之间存在大量依赖，因此迁移到新一代 FPGA 并不是简单地更换一颗芯片。

文章讨论的核心就是Legacy FPGA Migration。迁移过程中需要同时面对硬件接口、IP、时序约束、存储器架构、软件驱动以及开发工具链等问题。尤其是那些已经长期运行的工业设备，最大的价值往往不是 FPGA 本身，而是多年积累起来的稳定性和经过验证的软件生态。

因此，现代化迁移并不意味着“推倒重来”。更加现实的方法是分析原有系统中哪些部分必须保持不变，哪些部分可以重新设计，然后逐步迁移到新的、可扩展的平台。

文章的核心结论可以理解为：FPGA 平台升级的难点不在于新器件有多先进，而在于如何在保留已有设计价值的同时获得新平台的性能、可维护性和生命周期优势。

05｜验证 FPGA 设计：布局后信号完整性的作用

Dan Binnun，E3 Designers

高速 FPGA 系统中，仿真通过并不意味着 PCB 最终一定能够稳定工作。随着 FPGA I/O 速率不断提高，PCB 走线、连接器、过孔、阻抗、串扰以及材料参数都会影响最终的信号质量。

文章重点讨论 Post-layout Signal Integrity（布局后信号完整性）。完成 PCB 布局以后，通过实际的走线和器件参数建立完整的信号通道模型，可以检查高速信号在真实 PCB 上是否仍然满足设计要求。

但文章的重点并不是说“布局后分析就够了”，恰恰相反，布局后的分析更应该被视为验证和确认。真正高效的方法是尽可能把信号完整性问题前移，在布局之前就对器件、层叠、走线和高速通道进行分析。Issue 2 中该作者关于 pre-layout signal integrity 的文章也强调了这种“shift left”的思想。

因此，本篇文章实际上强调了一个完整的设计闭环：前期分析用于避免问题，布局后分析用于验证最终实现是否符合预期。对于高速 FPGA PCB，信号完整性已经不是 PCB 完成后的附加检查，而应该贯穿整个设计流程。

06｜Introducing Ash：用于处理 EDA 文件的开源 AI 助手

Kevin Hubbard，Black Mesa Labs

EDA 工程中存在大量文本和结构化数据，包括综合报告、实现报告、时序报告、日志、约束文件以及各种设计数据库。很多时候，工程师并不是缺少工具，而是需要花大量时间从这些文件中找到真正重要的信息。

Ash 的思路就是利用 AI 帮助处理这些 EDA 文件，让工程师可以更加自然地查询和分析设计数据。它代表了一种非常值得关注的方向：让 AI 不只是生成 HDL 代码，而是直接参与 FPGA/EDA 工程数据的理解和分析。

对于 FPGA 开发而言，这种能力尤其有价值。例如面对一个复杂的实现报告，工程师真正需要的是快速找到时序失败路径、资源占用异常或者约束问题，而不是人工翻阅大量报告文本。

因此，Ash 所代表的意义不仅是一个 AI 工具，而是 EDA 工作方式可能发生变化的一个缩影：未来工程师与 FPGA 工具链之间的交互，有可能从传统的“运行工具—查看报告”，逐渐转变为“向 AI 提出问题—AI 从设计数据中寻找答案”。

开源链接：

https://github.com/blackmesalabs/eda_ai_assist

07｜隐藏的验证错误，以及 UVVM 如何发现它们

Marius Elvegård，Inventas

FPGA 验证中最危险的问题往往不是明显的功能错误，而是那些在常规测试下没有暴露、但在特定条件下才会出现的隐藏问题。

文章以 UVVM 为基础，讨论如何通过更加系统化的验证方法发现这些问题。传统测试往往根据几个预先设计好的输入向量判断输出是否正确，但真实系统的输入情况远比测试用例复杂。只有增加随机化、覆盖率分析、边界条件测试以及更加系统的验证组件，才能提高发现隐藏问题的概率。

UVVM 的价值在于建立可复用的验证基础设施，让测试平台能够持续扩展，而不是每一个模块都重新编写一套测试环境。

文章最终强调的并不是“多写测试”，而是提高验证的质量和针对性。一个成熟的验证流程应该能够告诉开发者哪些功能已经覆盖、哪些场景没有测试，以及哪些问题可能只在特殊条件下出现。

这对于复杂 FPGA 系统尤其重要，因为设计规模越大，仅靠人工编写测试向量越难保证验证完整性。

08｜验证 AMD Versal AI Edge Gen 2 处理系统的单粒子事件抗扰能力

Pierre Maillard、Abhijitt Dhavlle，AMD

在航空航天等辐射环境中，FPGA 和 SoC 面临一个普通地面系统很少遇到的问题：单粒子事件（Single Event）可能导致系统出现瞬态甚至功能异常。

文章针对 AMD Versal AI Edge Series Gen 2 的处理系统开展单粒子事件抗扰验证。与传统功能测试不同，这类测试关注的是系统受到辐射粒子影响之后是否仍然能够保持正确运行，以及错误是否能够被检测和恢复。

这类验证的重要性在于，现代 Adaptive SoC 已经把处理器、FPGA Fabric、存储器和其他计算资源集成在一起，因此可靠性问题也从单个 FPGA 逻辑单元扩展到了整个处理系统。

文章体现出的核心思想是：面向特殊应用的 FPGA，可靠性必须通过实际的故障场景进行验证，而不能只依赖普通功能仿真。 对空间、高空和其他辐射环境应用来说，系统需要同时考虑错误检测、容错机制以及故障后的恢复能力。

这也与 FPGA Horizons 前几期关于空间计算和辐射可靠性的文章形成了连续的技术脉络。

09｜通过开源 FPGA 库实现设计可移植性

Oliver Bründler，Open Logic Maintainer

FPGA 生态长期存在一个问题：不同厂商拥有不同的器件架构、工具链和 IP 生态。一个设计在某一家 FPGA 上实现得很好，并不意味着它能够轻松迁移到另一家 FPGA。

文章从开源 FPGA 库的角度讨论如何改善这种情况。通过将设计中的通用逻辑和算法部分抽象出来，并尽量减少对特定厂商 IP 的依赖，可以提高设计在不同 FPGA 平台之间的可移植性。

这种思想对于开源 FPGA 生态尤其重要。一个真正具有生命力的开源 FPGA 项目，如果只能运行在单一器件或者单一工具链上，其复用价值会受到很大限制；而更加通用的库和组件则可以让同一套设计思想在不同平台上持续演进。

因此，文章讨论的不只是“开源库”，更是 FPGA 软件生态中的一个核心问题：如何降低对单一 FPGA 厂商工具和器件架构的绑定，让 FPGA 设计真正具备跨平台复用能力。

总结

FPGA Horizons 第四期的 9 篇文章涉及的领域非常广，但背后其实存在一条比较清晰的主线。

从芯片供应链和老旧 FPGA 迁移，到高性能 FPGA/Adaptive SoC 架构；从PCB 信号完整性和系统验证，到AI 辅助 EDA 和开源 FPGA 库；再到云 FPGA 安全和空间辐射可靠性，这些文章共同说明，今天的 FPGA 开发已经很难再被简单理解为“写 RTL、跑综合、过时序”。

一个真正复杂的 FPGA 系统，需要同时考虑器件供应、系统架构、PCB、验证、软件、AI 工具、安全和可靠性。

尤其值得关注的是，本期出现了几个非常明显的趋势：一是 FPGA 正在从单纯的可编程逻辑向 Adaptive SoC 和异构计算平台发展；二是 AI 开始进入 EDA 工程本身；三是云端 FPGA 带来了新的安全问题；四是空间和高可靠性应用推动 FPGA 验证从功能正确进一步走向可靠性和抗故障能力验证；五是开源生态正在尝试解决 FPGA 长期存在的平台绑定问题。

参考

https://www.fpgahorizons.com/journal/issue4/

往期精选 

 

 

FPGA技术江湖广发江湖帖

无广告纯净模式，给技术交流一片净土，从初学小白到行业精英业界大佬等，从军工领域到民用企业等，从通信、图像处理到人工智能等各个方向应有尽有，QQ微信双选，FPGA技术江湖打造最纯净最专业的技术交流学习平台。

FPGA技术江湖微信交流群

加群主微信，备注姓名+学校/公司+专业/岗位进群

FPGA技术江湖QQ交流群

备注姓名+学校/公司+专业/岗位进群