极客工场

Appearance

共 7,452 字预计阅读约 25 分钟

FPGA 专家 27：云端 FPGA——把 FPGA 变成可租用的云实例 ​

本文是 fpga/ 专家层第 30 篇。主机驱动/用户态栈见 专家 29，PR 分片见 专题 03，比特流安全见 专家 24。

一、云化带来的三个变化 ​

本地板面对的是"下载线 + 物理管脚"；云 FPGA 面对的是：弹性租用、镜像化交付、与陌生租户共用机房。因此整个链路变成：

bash
用户 CL ──HDK 定制流程──► 加密 DCP ──提交──► 厂商后台实现+DRC+安全审查
                                                  │ 生成
                                                  ▼
                              AGFI（镜像 ID，可版本化，类比 AMI）
                                                  │ 启动实例时安全加载
                                                  ▼
   云主机(vCPU/内存/网络) ◄─Shell(PCIe/DMA/DDR/管理)─ FPGA(CL 用户逻辑)

二、Shell / CL 分层 ​

AWS F1 式 Shell / CL（Custom Logic）分层（第 6 张）
Shell（厂商地基）Custom Logic（用户）
内容PCIe、DMA、DDR、中断、时钟复位、管理/虚拟接口加速器本体
谁写云厂商，锁定租户
接口标准 AXI（SH_CL 等）只允许连约定端口
代价占面积、划定资源框适配接口、受资源/时钟约束

好处：跳过 PCIe 量产驱动、多主机管理这些硬骨头；代价：面积税 + 不能任意用物理资源。

三、为什么必须"审查后由平台生成比特流" ​

受信比特流流水线：用户拿不到配置密钥（第 7 张）

租户的 FPGA 逻辑物理直连主机内存与管理网络，一旦可任意加载，就能伪造 DMA 攻击主机。所以安全链是：

  1. HDK 流程产出加密 DCP，不含最终配置；
  2. 厂商后台跑实现、时序签核、安全 DRC（禁入资源、时钟、接口合规）；
  3. 通过才发布 AGFI，平台管理通道加载；
  4. 运行时主机 IOMMU 限定 DMA 范围，管理/租户网络分离。

四、多租户：时间复用、空间独占 ​

多租户隔离：时间墙与空间墙（第 8 张）

FPGA 没有 CPU 式硬件虚拟化，主流方案是一片 FPGA 同时只给一个租户，实例释放后再安全清理分配给下一家。PR 多分区方案因侧信道/资源争用隔离弱，商业云不用于强隔离。

五、选型账本 ​

  • 上云：峰谷明显、SaaS 化加速、批量验证/教学、数据本来就在云上、省前期投入。
  • 自建：满载 7×24（租金 > 买价）、需要丰富物理 IO、非云支持器件、强数据驻留/物理合规、需定制 Shell。
  • 隐藏成本：CL 适配 Shell 的工程、迭代一次镜像的后台构建时间、按实例时长计费下的架构利用率。

六、云 FPGA 的多租户隔离机制：时间、空间与故障三道墙 ​

公有云把 FPGA 变成一种可按需租用的资源，本质难题是如何在同一片物理资源、同一台服务器上，让彼此不信任的租户安全共享，且互不感知、互不伤害。隔离要同时回答三个问题：空间上一个租户能不能读到或影响另一个租户的逻辑与数据；时间上一个租户的使用会不会让另一个租户的性能、延迟变得不可预测；故障上一个租户的设计把芯片搞挂、把服务器搞崩，会不会波及邻居和宿主机。三道墙都成立，云 FPGA 才敢成为商品。

空间隔离在 FPGA 上比在 CPU 上难得多。CPU 借虚拟化硬件（特权级、MMU、IOMMU）天然能限制一个虚拟机可触达的内存和设备，而 FPGA 给租户的是“在硅片上排布电路”的能力——一段自由组合逻辑理论上可以驱动任何管脚、访问任何互联、构造任何时序。云厂商的答案是 Shell/CL 分层：租户的逻辑只能存在于一个被严格框定的可重构区域（PR 分区），分区边界用一组物理上固定、宽度和协议都由 Shell 规定的接口（静态逻辑与动态分区间的 partition pin、专用 AXI/PCIe 通道）封死。租户拿不到访问 DDR 控制器、PCIe 硬核、时钟/复位树、JTAG 和配置端口的权限，这些全在 Shell 手里。实现层面还会用网表级设计规则检查（DRC）：在生成比特流前扫描租户提交的设计，确认它没有越界例化禁止资源、没有驱动静态区域信号、没有占用保留管脚、没有布设会破坏隔离的时钟通路。这道检查是强制性的，且通常只接受源码/加密网表而不是现成比特流——因为只有厂商工具重跑一遍实现，才能真正保证布局布线没有绕过隔离边界。

时间/性能隔离决定了云 FPGA 能否承载对 QoS 敏感的业务。常见策略有两种。其一是空间独占：一片 FPGA 在任一时刻只租给一个租户，重配置时整片清空，邻居之间物理上完全不共享可重构资源，性能完全隔离，代价是粒度粗、成本高（小用例也要为整卡付费）。其二是时间复用：同一片 FPGA 按时间片在不同租户的镜像间切换（配合部分重配置只换 CL 分区，秒级完成），提高利用率，但切换有开销、缓存和片上状态要在切换间清空以防泄漏，且一个租户无法获得持续满载的性能保证。更细的空间分片（一片 FPGA 切多个相互隔离的小分区同时出租）在研究和部分产品中出现，但受限于硬核（PCIe/DDR 控制器）难以真正按区切分、跨分区时序与隔离验证复杂，目前仍非主流。无论哪种，Shell 还会对 PCIe 带宽、DDR 带宽做配额或仲裁，防止一个租户占满物理 I/O 把邻居饿死。

故障隔离与宿主机保护是云厂商最在意的底线。租户设计可能让 FPGA 进入非法状态：时钟被搞得停振、总线锁死、功耗拉到超限导致过流、持续发起非法 PCIe 事务、甚至让卡进入需要整机掉电才能恢复的状态。Shell 和板卡管理（板载 BMC/MCU、电源/温度监控、独立看门狗）构成防线：功耗温度越限时降频或下电、PCIe 事务由 Shell 代理并过滤非法访问、检测到 CL 卡死时由宿主机触发一次分区级重配置而不必重启整机、严重情况把卡从主机摘除并迁移租户。这里的关键设计目标是任何单个租户镜像都不应拥有“搞挂宿主机/影响物理邻居”的能力，恢复动作要能由云平台自动完成。这些机制看似与加速逻辑无关，却是 FPGA 能上云的真正前提，也是自研板卡上云时最难补齐的部分。

理解三道墙，也就理解了为什么云 FPGA 的“灵活性”是被严格约束的灵活性：你能自由设计计算管道，却不能自由选择管脚协议、不能随便加自己的 PCIe 核、不能独占 DDR、不能任意接时钟。评估是否上云时，要把这些约束当作硬边界，而不是“将来可以申请开放”的软限制——凡是设计依赖直连特定电气管脚、自定义 PHY、独占多卡硬连线或非标准时钟拓扑的，往往根本无法装进云 Shell 的分区模型，这类需求更适合裸金属/bare-metal FPGA 实例或自有板卡。

七、开发与交付流水线：从 RTL 到云端可加载镜像 ​

云 FPGA 交付流水线（比本地上板多三段）（第 9 张）

云上 FPGA 的开发体验，刻意被设计成尽量接近“开发一个软件服务”：代码进版本库、走 CI、产出可部署制品、通过 API 加载到卡上、运行并被监控。但在这条软件化的表面之下，每个环节都夹着 FPGA 特有的重流程。理解从 RTL 到云端可加载镜像的完整链路，才能正确估算开发周期、设计团队协作方式、并避开“以为像部署容器一样快”的错觉。

第一步是获取并钉住 Shell 版本。云厂商发布 Shell（含静态逻辑、仿真模型、接口约束、综合用的黑盒 stub、驱动和工具链），租户针对某个 Shell 版本开发 CL。Shell 不是稳定不变的：它会随宿主机固件升级而更新，新版本可能改时序、改接口、改可用资源。工程上必须把 Shell 版本当作编译器版本一样显式锁定，在 CI 里记录、在镜像元数据里登记，避免出现“上周综合的镜像这周加载行为变了”。厂商通常会保证一段兼容窗口，并提供多个 Shell 版本并存，但“随时跟随最新”不是好策略。

第二步是基于仿真模型的开发与验证。Shell 提供它那一侧的仿真模型（PCIe DMA、DDR、管理接口的 BFM/VIP 或软件协同仿真环境），让租户在没有真实卡的情况下，把自己的 CL 与 Shell 模型对接做端到端仿真。这一步能抓住绝大多数接口协议错误、地址映射错误、DMA 描述符错误，且比上云调试快几个数量级。专业团队会在仿真阶段就跑通完整的软件栈（用同一套驱动/runtime 代码连仿真模型），这样上云后软件侧几乎不改。把仿真当“可做可不做”、指望直接上云卡调试，是云上开发最昂贵的反模式——每次综合以小时计、每次上板窗口都要排队，调试反馈循环极其缓慢。

第三步是综合实现与厂商级设计规则检查。租户综合自己的 CL（链接 Shell 提供的黑盒 stub），通过时序和资源自检后，按云厂商规定的打包格式提交“待审查设计”（加密网表或源码）。与本地开发不同，最终的布局布线和比特流生成由厂商平台完成：平台把 CL 放进固定 PR 区域、与某一版 Shell 拼合、跑全套隔离 DRC、再生成比特流。这个“审查—构建”过程可能耗时数十分钟到数小时，且是异步的（提交任务、等结果）。因此本地必须先把资源、时序、时钟、接口检查全部做干净，任何 DRC 失败都要重走一遍，迭代成本远高于本地。理解这条，就理解了为什么云 FPGA 开发要“仿真极度充分、本地门禁极度严格、把昂贵的云端构建次数降到最低”。

第四步是制品化、版本化与加载。通过审查的设计被固化为一个不可变镜像制品，带全局唯一 ID、与 Shell 版本和源码 commit 绑定。加载到某张卡通常是调用云 API（或宿主机上的管理工具）：平台校验权限、把镜像写入卡、执行（部分）重配置、返回就绪。重配置期间该卡不可用，因此生产系统要么用多卡轮流升级、要么接受秒级到分钟级窗口。镜像还可能需要预注册、按区域复制（FPGA 镜像往往是区域/机型相关的，不能假设跨区域通用）。把比特流当镜像、把加载当部署、把版本当不可变制品，是云 FPGA DevOps 的核心心智，也与 20 比特流烧录与四方版本一致 manifest/门禁 的版本治理一脉相承。

第五步是运行期管理与可观测。加载后，租户通过 Shell 暴露的标准通道（PCIe BAR、DMA、中断、厂商 runtime）与自己的逻辑通信，监控数据分两层：平台层（卡是否在线、温度、功耗、重配置事件、健康状态）由云厂商提供；业务层（加速器内部计数、吞吐、错误、自定义指标）要租户在 CL 里自己埋点并经寄存器/驱动导出。云端尤其要处理“邻居噪声”和“平台维护”：宿主机可能被云平台热迁移/维护、卡可能被强制重配置、实例可能被抢占，应用必须能检测 FPGA 状态丢失并重新加载镜像、恢复上下文，而不是假设一次加载永久有效。把“镜像随时可能需要重新加载”作为常态来设计，是云上 FPGA 服务可靠运行的必要条件。

八、安全模型深度：从比特流信任链到侧信道 ​

云 FPGA 的安全模型要回答一个 CPU 云也面对、但在 FPGA 上尖锐得多的问题：云厂商凭什么相信租户提交的电路是无害的，租户又凭什么相信自己的比特流和密钥不会被窃取或篡改。这是一个双向信任问题，且因为交付物是“物理上直接驱动电气信号的电路”，攻击面与纯软件云有本质区别。

对租户的约束——为什么必须由厂商生成比特流。如果允许租户直接上传比特流，云厂商就等于允许对方在自己的数据中心里运行任意“电路级程序”，它可绕过任何软件隔离：驱动保留管脚、监听片上其他区域的信号（比特流可以物理连接到可布线资源）、构造过载、利用信号泄露。因此主流云 FPGA 不接受成品比特流，而接受源码或加密网表，由厂商工具在受控环境中重新实现并执行隔离 DRC：检查设计只使用了分配给它的区域和资源、没有连接保留端口、时钟和复位来自 Shell 而非自造、没有例化可窥探静态逻辑的探针。加密网表（厂商工具能读但人看不到）兼顾了 IP 保护——很多 ISV 不愿把核心 RTL 源码交出去。这道“审查后由平台生成比特流”的环节是整个信任链的技术基石，宁可牺牲一部分灵活性也要守住。

对租户的保护——比特流与密钥的机密性、完整性。租户（尤其卖加速器的第三方 ISV）担心自己昂贵的硬件 IP 被云平台或同主机的他人复制，也担心运行时数据和密钥泄露。防护手段包括：比特流加密（利用 FPGA 的电池备份密钥/BBRAM 或 eFuse 密钥，比特流在片上解密，平台运维人员即使拿到镜像文件也读不到内容）、镜像完整性校验与签名（防止被篡改后加载）、器件认证（镜像绑定特定器件/区域）。运行时，CL 私有的片上 RAM 内容在重配置/时间复用切换时必须清零，防止下一个租户从残留状态里恢复敏感数据。租户密钥的 provisioning 是另一个难点：理想路径是密钥从租户 KMS 经安全通道直接注入卡内加密引擎，连宿主机和云平台软件都接触不到明文，这对金融、机密计算类负载至关重要。

侧信道与共享物理介质的风险，是 FPGA 云安全研究里最前沿也最棘手的部分。当多个租户的电路共享同一片硅或同一套电源/缓存/PCIe 通道时，理论上可能通过功耗、时序、缓存访问时间、甚至把 FPGA 逻辑当作传感器来推断邻居信息；恶意电路还可能构造电压毛刺影响共享电源。完全杜绝这类物理层串扰极难，因此多数商用云选择**空间独占（一卡一租户）**作为最稳妥的隔离形态，从根上避免同片共享；时间复用时则保证区域间不共享可重构布线资源、清空所有状态、并对功耗做硬限制。评估云 FPGA 方案时，对安全敏感的负载应明确确认是“整卡独占”还是“分区/时间共享”，并据此判断风险，而不能只看厂商宣传的“硬件隔离”四个字。

供应链与生命周期安全也不能漏。Shell、工具链、固件、驱动都是信任链的一环：要验证来源签名、钉住版本、纳入漏洞管理（厂商发布 Shell 安全补丁后需要重新综合镜像并滚动更新）；镜像从构建到加载的每一跳都要可审计（谁提交、谁批准、何时加载到哪张卡）；废弃镜像和旧 Shell 要有退役计划，因为一个长期不更新的 FPGA 镜像可能带着多年前的接口漏洞一直跑在生产里。把 FPGA 镜像纳入和软件制品同级别的供应链安全治理（签名、漏洞跟踪、退役），是云 FPGA 走向成熟的标志。

总的来说，云 FPGA 的安全不是某一个功能，而是一条从源码审查、受控构建、比特流加密、物理隔离、密钥注入到运行时清零和审计的完整信任链。任何一环假设“别人会保证”都会成为突破口。对采用方而言，最实际的做法是：优先整卡独占、用官方加密交付与 KMS 集成、把镜像当有生命周期的制品管理、并在架构上假设宿主机/云软件是不可信的（敏感数据只在卡内解密处理）。

九、成本、性能与可移植性：云 FPGA 的真实账本 ​

自建 vs 上云决策：按负载形态选型（第 10 张）

决定“上不上云 FPGA、怎么用最划算”，需要把三类账算清楚：金钱账（实例与镜像成本、持续负载 vs 突发负载）、性能账（云 Shell 带来的损耗、与裸金属/自有卡的差距、与 GPU/ASIC 替代方案的对比）、可移植性账（锁定云厂商 Shell 与接口的代价）。只算其中一类，往往会得出后来后悔的结论。

金钱账的关键是区分开发期与生产期、突发与常驻。FPGA 云实例通常按卡/小时计费，价格不菲，而 FPGA 开发中的综合实现以小时计、上板调试也占用实例——如果开发团队每人 24 小时挂一台昂贵实例做调试，账单会很快失控。正确姿势是：绝大多数功能验证在本地仿真和便宜的开发板/小规模实例上完成，云实例只在真正需要厂商环境（最终 DRC、端到端联调、性能标定）时按需开启、用完即释放，并用 CI 把昂贵的云端构建自动化、排队化。生产期则要对比负载形态：突发、弹性、短期项目（验证概念、赶一次大促、给客户做 PoC）极适合上云，省下的是自购卡、服务器、机房和运维的固定成本；7×24 高占用的常驻负载（一条跑三年的数据处理流水线）往往自购板卡摊薄后更便宜，云的溢价主要买的是弹性和免运维。很多团队忽略了镜像构建、跨区域复制、闲置卡这些隐性成本，做预算时应把它们单列。

性能账要扣除 Shell 损耗并与替代方案正面对比。云 FPGA 不是“整颗芯片都归你”：一部分 LUT/BRAM/DSP 和高速资源被 Shell（PCIe DMA、管理、静态逻辑）占用，留给 CL 的只是其中一部分；时钟、DDR 带宽、PCIe 队列也由 Shell 仲裁。因此云上加速器的实际可达性能通常比同芯片的裸金属卡低一截（资源打折、I/O 经过 Shell 多一级、可能还有虚拟化开销）。评估时必须用目标云实例上的实测而非芯片手册峰值来建模，尤其要测端到端延迟（包含主机→Shell DMA→CL→回写的全路径，见 专家 31 的 roofline 方法），因为 Shell 这一级的 DMA 与仲裁往往是瓶颈而非算力。更重要的是诚实地和替代方案比：对规则、稠密、张量类负载，现代 GPU 软件栈成熟、弹性供给好、开发快，常是更优解；FPGA 的甜区仍是低延迟流式、不规则/位级并行、需要定制流水线且批量不足以流片 ASIC 的场景。为了“用 FPGA 而用 FPGA”，在云上尤其容易亏。

可移植性账是云 FPGA 最隐蔽的长期成本。你的 CL 深度绑定了某一家的 Shell：PR 分区尺寸、自定义接口（往往是厂商私有 AXI 变体/管理消息）、DDR 与 PCIe 的接入方式、仿真模型、驱动/runtime、镜像格式和加载 API，全都不可移植。换一家云、甚至同一厂商换一代实例（Shell 大改），都可能要重写接口层、重新调时序、重做验证。降低锁定的工程做法是严格分层：把与云厂商耦合的部分收敛到一个薄薄的“平台适配层”（Shell 接口、DMA、runtime/加载 API），核心算法管道只依赖标准 AXI-Stream/AXI4 接口和清晰的数据契约，可在仿真、自有板卡、任意云上复用；业务软件通过一套自研的、与厂商无关的 runtime 抽象（open/enqueue/wait）调用，后端可替换。这样即使云厂商变化，重写的只是适配层而非整个加速器。立项时就应评估“这个核心 IP 是否计划跨云/上自有硬件长期存在”，若是，则平台无关层的投入从第一天就值得。

做决策的综合框架可以浓缩为几个问题：负载是否落在 FPGA 甜区且与 GPU/CPU 有明确实测优势？需求是突发弹性还是常驻（决定云 vs 自购）？团队是否有能力承担 Shell 锁定，还是应把核心 IP 平台化？安全上是否必须整卡独占、密钥能否安全注入？性能目标是否基于云端实测而非裸芯片峰值？把这五问答清楚，再结合一次小规模 PoC 的真实账单和端到端性能数据，远比看市场材料可靠。云 FPGA 是一个强大但约束明确、锁定真实、成本结构特殊的选项，用得对能把硬件加速能力像软件一样弹性交付，用得错则会在账单、性能和可移植性上同时吃亏。

十、常见坑与上云自检清单 ​

结合云 FPGA 的隔离、交付、安全、成本四条主线，把高频坑和上云前应逐项确认的检查点汇总如下。

隔离与合规类坑：误以为云 FPGA 像云主机那样可以自由接外设、自定义管脚，结果设计依赖的电气接口在 PR 分区里根本不可得；以为能上传现成比特流，实际必须交源码/加密网表走厂商构建；没确认是整卡独占还是时间/空间共享，就在多租户环境处理高敏感数据。正解是早期通读目标 Shell 的资源/接口/隔离白皮书，把“哪些资源归租户、哪些归 Shell、隔离形态是什么”当作设计输入而非事后确认。

交付流程类坑：跳过仿真直接上云调试，每次迭代付几小时构建费和排队时间；本地没跑干净时序/资源/DRC 就提交，反复被云端打回；Shell 版本不锁定，宿主机升级后旧镜像行为变化；把镜像当成跨区域/跨实例可通用，部署时才发现不兼容。正解是仿真优先、本地门禁齐全、Shell 版本钉死并写入镜像元数据、按区域和机型分别构建登记。

运行期可靠性坑：假设一次加载永久有效，遇到宿主机维护、实例抢占、卡被重配置时业务直接崩；没有检测 FPGA 状态丢失和自动重载镜像的逻辑；业务指标没有埋点，线上性能异常无从定位。正解是把“镜像可能随时需要重新加载、上下文可能丢失”当常态，实现状态检测、自动重新配置和上下文恢复，并在 CL 内埋业务计数、在软件侧接云监控。

安全与密钥坑：把第三方 RTL 或自研 IP 以明文源码交出且无保密通道；密钥经宿主机明文中转；时间复用切换后依赖片上残留状态。正解是优先加密网表与比特流加密、用 KMS 到卡的密钥注入、不依赖跨重配置残留状态、把 Shell/固件/驱动纳入签名与补丁管理。

成本与性能坑：开发期长期挂昂贵实例；用芯片峰值而非云端实测做性能承诺；没扣 Shell 的资源和 I/O 开销；没和 GPU/裸金属做端到端对比就押注 FPGA；常驻负载长期付云溢价不自购。正解是仿真/本地为主、云实例按需用、PoC 阶段同时测端到端性能和真实账单、按突发/常驻决定租或买。

可移植性坑：核心算法管道直接调用厂商私有接口和 runtime，导致跨云/换代时整体重写。正解是平台适配层与标准 AXI 数据面分离、自研厂商无关 runtime 抽象、核心 IP 在仿真和多目标上持续回归。

上云前自检清单：①已确认目标 Shell 版本并锁定，资源配额、接口、时钟、隔离形态满足设计；②CL 与 Shell 仿真模型端到端跑通，软件驱动/runtime 在仿真中即验证；③本地时序、资源、时钟、接口 DRC 全绿，无保留资源占用；④已通过厂商审查并成功由平台生成比特流，镜像 ID 与 commit/Shell 版本绑定；⑤明确整卡独占/共享形态，安全模型（比特流加密、密钥注入、清零）满足数据分级要求；⑥有镜像加载失败/丢失后的自动重载与上下文恢复；⑦业务指标与平台健康指标均可观测，有告警；⑧预算按开发期按需实例 + 生产期租买对比核算；⑨核心算法在平台无关层，厂商耦合收敛到适配层；⑩有 Shell/固件补丁后的镜像重建与滚动更新流程。逐项打勾后再进生产，能把云 FPGA 特有的隔离、交付和运维风险挡在上线之前。

总结 ​

云端 FPGA 用"厂商 Shell 地基 + 用户 CL 逻辑 + 加密 DCP 提交 + 审查生成 AGFI + 平台安全加载"把硬件加速器变成云实例；隔离靠整卡时空独占、IOMMU 和镜像审查；弹性和免运维是收益，面积税、接口约束和长期租金是代价。