eFPGA集成评估实战：用Aurora从工程搭建到SoC落地

1. 为什么 eFPGA 项目最好先做软件评估Aurora 出现的背景做 SoC 的人应该都有同感一颗芯片里要不要放 eFPGA往往是个争论很久的问题。硬件团队说加一块可编程逻辑流片后还能改稳了软件团队说这东西面积不小、时序不好收敛、功耗也不好估两边说得都有道理但真正拍板的时候谁手里都没有足够的数据支撑。ArcticPro eFPGA IP 这种嵌入式 FPGA 方案解决的就是想在 SoC 里加入可编程能力但又不想外挂一颗独立 FPGA的需求。可是要把这个 IP 集成进自己的芯片不是一个加进去就行的决定你得知道它用多少面积、能跑到多少频率、功耗大概多少、和自己的标准单元库配不配。这些数据从哪里来靠芯片厂家的规格书只能拿到大概范围靠自己的后端工程师去预评估又耗时很长这时候你就需要一套专门的评估软件Aurora 就是干这个的。我最早接触 Aurora Software是在评估一个带图像预处理加速功能的边缘计算 SoC 项目。团队已经确定要把 ArcticPro eFPGA IP 放进去但具体选多大 configurable logic block 规模的配置、配多少个 DSP 和存储器宏单元完全没概念。当时如果直接按最大规模去集成后端压力很大而且有些逻辑资源和嵌入式 BRAM 的数量其实用不到那么多白白浪费 Die area。后来用 Aurora 做了一轮轮评估才发现这个工具的真正价值不是能画个版图而是它能在 RTL 还没有完全定稿的早期阶段用接近真实实现的精度帮你算清楚 IP 尺寸、时序裕量、功耗分布和验证策略。这篇文章就把我从工程建立到报告解读的完整过程写下来适合正在考虑集成 ArcticPro eFPGA IP、或者对 eFPGA 评估方法感兴趣的数字前端和后端工程师参考。需要说明的是Aurora 本身不是用来写 RTL 的也不是一个完整的 ASIC 设计工具链。它更像是eFPGA 专用评估器你给它一堆设计输入和约束它告诉你这块 eFPGA 在这个设计上大概是什么表现。这意味着你的工作流程会和用 Vivado 开发独立 FPGA 有很大差别后面我会专门讲这部分差异。2. Aurora 评估工程从零搭建核心步骤与参数选择2.1 先想清楚评估目标再动手建工程评估目标这件事听起来像废话但实际操作中太容易被忽略。Aurora 工程建立的第一步不是导入 RTL而是确认你评估的目的是什么。目的不同参数配置差很远。以我那次图像预处理项目为例我关心的核心问题是在某个固定算法负载下eFPGA 需要多大逻辑规模、最高能跑到多少频率以及功耗会不会超过系统预算。所以我把评估目标分解成了三项面积评估给定某个 logic capacity 的 ArcticPro 配置能否放得下目标设计资源利用率是否在合理区间。时序评估在预期工作频率例如 200MHz下能不能收敛关键路径在哪里。功耗评估动态功耗、静态功耗和配置功耗分别占多少是否需要额外的功耗管理策略。如果你只是想在两个不同规模的 IP 配置之间做对比那评估目标就更简单但需要在同一组约束下跑通两个工程才有可比性。我见过不少人上来就按最大规模配置觉得反正越大越不容易出问题结果面积报告出来远超预算还要推翻重来。正确的做法是先用一个偏小的配置跑第一轮拿到资源利用率数据后再决定要不要升级规模。2.2 工艺节点、IP 配置和宏单元数量的选择逻辑ArcticPro eFPGA IP 的可配置参数主要包含逻辑块规模、DSP 单元数量、嵌入式存储容量、IO 数量等。Aurora 里建立评估工程时需要根据你的集成目标选择对应的工艺节点比如 12nm、16nm 或 22nm 这类后端工艺库和 IP 配置版本。选择工艺节点时要注意一个隐蔽的坑Aurora 中的工艺节点要和你的 SoC 后端标准单元工艺库对齐不能图省事随便选一个接近的节点。因为 eFPGA 的面积和时序评估严重依赖标准单元库的驱动强度、布线资源延迟和金属层信息用错节点会直接导致评估结果偏乐观或偏悲观。我们当时一开始用了 12nm 的库跑评估后来发现后端团队实际用的是 12nm 的低功耗变种库阈值电压分布不一样重新跑了一轮才得到可信的数据。宏单元数量的设置同样需要谨慎。嵌入式存储器和 DSP 的数量不能只按算法需要多少个乘法器来拍脑袋。比如图像处理里常见的 3x3 卷积你可以用 DSP 实现乘法累加也可以用 LUT 逻辑搭建分布式算术结构。两种方式对资源的需求差别很大而且会影响后续布线拥塞度。Aurora 的好处是你可以把 RTL 里显式例化的 DSP 和 BRAM 宏单元数量先填进去再把其余综合映射到通用逻辑的一部分让工具自动安排最后在报告里对比两种分配策略的结果。2.3 RTL 导入与映射不是所有代码都适合直接评估Aurora 支持的 RTL 输入一般是 Verilog 或 SystemVerilog综合和映射流程里有几个需要特别注意的地方。首先eFPGA 的架构和独立 FPGA 有区别更接近可编程逻辑阵列 宏单元的组合。你用 Xilinx FPGA 时习惯写的mul操作符在 Aurora 里可能会被自动映射到 DSP 宏单元你写的if (addr 10h3FF)这种大扇出比较逻辑工具会把它转换成 LUT 查找表网络。这意味着RTL 里尽量避免依赖特定厂商原语比如 Xilinx 的BUFG、DSP48E、BRAM_TDP_MACROAurora 不认识这些需要你自己改成通用的行为级描述或者调用 ArcticPro 对应的宏单元原语。其次代码风格对评估结果影响非常大。我踩过的一个典型例子是组合逻辑环路。RTL 里有个隐藏的组合反馈路径在功能仿真时可能永远不触发但综合工具会把它保留下来导致映射结果出现一个很长的组合逻辑链时序分析报出很大的负裕量。Aurora 对这类问题不会帮你排除它只会如实报告。所以导入前最好用nLint或 SpyGlass 之类的工具做一次静态检查把 latch、组合环、多驱动这类问题清掉再进评估流程。2.4 布局布线与时序约束这一轮决定评估可信度RTL 映射完成后Aurora 会执行布局布线。这个阶段你提供的约束越贴近真实 SoC 集成环境评估结果越有参考价值。时序约束方面至少要覆盖时钟周期约束、输入输出延迟约束和时钟分组约束。不少 eFPGA 设计会接入 SoC 的 AXI 总线那么 AXI 接口的输入建立时间和输出延迟就要按总线频率和外部逻辑的时序要求来设不能只约束内部逻辑的频率。我见过有人只约束了核心时钟频率 200MHz结果 AXI 侧接口变成关键路径工具为了收敛不得不把内部逻辑推后最终报告的 Fmax 降到了 150MHz 左右。所以说不是你设了 200MHz 约束就代表能跑 200MHz工具会告诉你真实的时序裕量是多少但前提是约束要全面。如果第一轮布线出现时序违规先不要急着改 RTL。Aurora 的布线报告里会给出关键路径的路径延迟优先看是不是高扇出网络比如全局复位、时钟使能引起的。eFPGA 里全局资源和独立 FPGA 不同它的时钟网络和复位网络密度有限如果 RTL 里大量使用异步复位往往会导致复位网络拥塞。把异步复位改成同步复位后再跑一轮时序往往会明显改善。2.5 评估报告的导出与后端交接布局布线跑完后Aurora 会导出面积、功耗、时序等报告。在实际项目里这些报告不只是给硬件工程师看还要交给后端团队做物理集成评估。所以导出时要注意格式和信息的完整性最好同时导出版图示意图、宏单元分布图和引脚分布信息方便后端工程师评估 IP 与标准单元区之间的走线资源。另外Aurora 评估工程本身也应该作为交付物之一归档。因为后续你可能会改动 RTL 或约束重新评估时如果工程文件缺失一切都要重来。我们项目组后来规定每一版评估必须把工程配置、RTL 版本、约束文件的 commit hash 一起记录下来这样报告出了问题还能追溯。3. 评估报告怎么看从资源占用率到 Die area 的换算逻辑3.1 逻辑资源与面积别只盯 LUT 数量Aurora 的报告第一页通常是资源利用表列出 LUT、FF、DSP、RAM块、IO 的使用数量和利用率。很多从 FPGA 开发转过来的人第一反应是看 LUT 利用率有没有超过 80%如果没超过就觉得放得下。这个思路在 eFPGA 评估里不适用因为 eFPGA 的硬核面积最终要摊到整个 SoC 的面积里去你需要关注的是绝对面积而不是利用率。打个比方一个 LUT 资源利用率 60% 的评估结果看起来还有余量但 eFPGA 的面积是固定的你买的是整块可编程阵列不是按用量计费。剩余 40% 的逻辑资源在流片后虽然可以被后续软件更新利用但在当前版本产品里它不会让芯片面积变小。所以正确的面积评估方法是用 Aurora 报告里的 IP 总面积数字结合后端给出的标准单元面积密度估算出 eFPGA 在整颗 Die 中的占比再判断是否可接受。如果面积太紧张可以调整两个地方一是 IP 配置里的逻辑阵列行列数二是宏单元比例。比如图像算法需要用很多小型 SRAM但如果你选择的 eFPGA 配置里嵌入式存储器数量偏少工具可能会把存储功能映射到 LUT 构建的分布式 RAM 中这会急剧膨胀逻辑资源需求。把存储器宏单元数量提升后LUT 数量下降总面积反而可能更小。3.2 时序分析Fmax 不是唯一的指标Aurora 报告中的时序部分会列出 WNS最差负裕量、TNS总负裕量、Fmax 等信息。这些指标当然重要但在 eFPGA 评估里你更要注意的是时序裕量的分布情况。举个例子某次评估一个 AES 加密模块整体 Fmax 达到了 250MHz看起来不错。但打开分路径时序报告后发现关键的 S-box 组合逻辑路径裕量只有 50ps而其他路径都有几百 ps 的余量。这意味着只要后端集成时给 eFPGA 供电稍微有点噪声或者温度接近工作极限这条路径就可能先失效。这种单点脆弱的设计在独立 FPGA 上可能问题不大因为逻辑资源多可以调整布局密度但在 eFPGA 上布局密度受 IP 阵列固定结构限制可调整空间有限。因此看到 Fmax 达标的同时还要检查关键路径裕量是否均匀。另外跨时钟域路径的处理也要在评估阶段就注明。eFPGA 内部的异步 FIFO 或握手同步器在 Aurora 里如果约束不当会被工具当成普通时序路径去收敛导致大量面积浪费。正确做法是在约束文件里显式声明set_clock_groups -asynchronous告诉工具这些路径不需要严格收敛。如果不做这个声明工具可能会用加长布线的方式去满足不必要的时序要求白白降低其他区域的布线资源可用性。3.3 功耗分析动态功耗之外还有一块容易被忽略的配置功耗功耗报告一般会分成三块动态功耗、静态功耗漏电功耗、配置功耗。前两项大家比较熟悉配置功耗是 eFPGA 特有的它来自 IP 上电后加载配置 bitstream配置数据写入配置存储器这个动作。这个配置功耗虽然在流片后的正常运行阶段几乎可以忽略但在上电顺序设计和功耗预算分配时必须考虑。如果你的 SoC 在启动阶段对峰值电流有严格限制比如 USB 供电或小容量电池供电配置 bitstream 加载瞬间的电流尖峰可能造成电压跌落。我就在一次评估中遇到过这个问题eFPGA 逻辑规模较大配置文件有几百 KB上电加载时间约几毫秒这期间功耗是正常工作的好几倍。后来和系统团队商量后把加载操作放到主电源稳定之后并且分片加载 bitstream才把尖峰压下来。Aurora 的功耗评估还支持活动因子设置。默认的活动因子通常假设所有节点以一定频率翻转比较悲观。如果你对自己设计的信号翻转率有把握可以在功耗分析选项里设置门控时钟数据或指定模块的活动率功耗数字会更接近实际。但要注意改动活动因子后要记录清楚不然拿两个不同设置的报告对比会得出错误结论。3.4 与后端集成相关的报告物理信息才是后端最关心的说到后端集成Aurora 报告里的物理信息模块非常关键但很多前端工程师容易忽略。这部分会给出 IP 的引脚位置、电源域划分、时钟输入输出端口位置以及 eFPGA 阵列和 SoC 其他逻辑之间的边界带宽。后端工程师拿这些数据做 floorplan 时要判断 eFPGA 应该放在芯片的哪个位置、周围留多少布线通道、电源网格怎么铺。如果评估阶段就能给后端一个初步的 eFPGA 物理模型他们就能更早评估布线拥塞避免后期集成时发现 eFPGA 周围走线资源不足导致时序难以收敛。4. 从 Vivado 开发习惯迁移过来你需要纠正的几个概念4.1 Aurora 不是又一个 FPGA 综合工具很多有 Xilinx Vivado 或 Intel Quartus 经验的工程师第一次打开 Aurora 时最大的困惑是这个工具怎么没有那么多 IP catalog 这种困惑来自对工具定位的误解。Vivado 完整的 FPGA 开发流程面向的是独立 FPGA 芯片你写 RTL、综合、布局布线、生成 bitstream然后下载到芯片里运行。而 Aurora 面向的是 eFPGA IP 评估它更像是在芯片还没流片之前模拟 eFPGA 将被集成到 SoC 中的表现所以你不需要关心最终如何下载 bitstream而是要关注的是这块 IP 在真实设计中到底能不能满足指标。这意味着 Aurora 的很多功能是评估导向的比如快速面积扫描、宏单元数量敏感性分析、功耗快速估算等这些功能在独立 FPGA 开发里你不会用到但在 eFPGA IP 选型和集成阶段非常有用。尽早转换这个认知后面使用工具的过程会顺畅很多。4.2 别把 Aurora 的IP和 Vivado 的IP混为一谈还有一个很容易混淆的概念。在 Vivado 里IP指的是像 AXI DMA、FIR Compiler、FIFO Generator 这样的功能模块。在 eFPGA 语境里IP 通常指 ArcticPro eFPGA 本身它是一个卖给你集成到 SoC 里的可编程逻辑阵列而不是一个具体功能的控制器。Aurora 评估的核心不是测试某个 IP 功能是否正确而是验证这块 eFPGA IP 在你的 SoC 场景下是否选型正确。所以如果用户搜索 Vivado IP 核的用法然后用同样的思路去搜索引擎找ArcticPro IP 例程大概率找不到自己想要的东西。ArcticPro 提供的不是可综合的功能模块代码而是物理 IP 和对应的评估环境。你要拿自己的设计去评估它而不是从官方例程里找一个模块直接用。不过有一点是相通的Aurora 也提供了一些加速器模块的示例工程设计比如数字信号处理、数据包处理、神经网络加速等这些例程可以帮你快速了解评估流程但不能直接拿来做生产级 RTL。4.3 从芯片选型思维转变成配置调优思维独立 FPGA 开发中芯片型号是固定的工程师考虑的是如何在这么大的资源里把设计塞进去。eFPGA 评估则不同IP 规模可以配置调整问题变成了配置多大的 IP 才能恰好满足设计需求同时不浪费面积和功耗。这个思维的转变反映在操作上就是需要多跑几轮评估对比不同配置。我习惯用 A/B 对比方式保持 RTL 不变分别用 LUT 密集型和 DSP 优化型配置跑两轮然后对比面积、功耗和时序结果。Aurora 支持把多轮评估的结果导出成表格对比这种工作习惯能帮你更好地理解 eFPGA 架构的灵活性。5. 我在 eFPGA 评估期间踩过的六个坑5.1 约束文件里的时钟周期不等于你要的工作频率这个坑最隐蔽。如果你的 SoC 里 eFPGA 的工作时钟由外部 PLL 提供PLL 的输出频率可能带一些抖动和不确定性。评估时我一开始只给了 200MHz 的周期约束结果真实场景里 PLL 输出有约 2% 的偏差加上时钟树插入延迟时序收敛裕量被吃掉了不少。建议在评估阶段就按目标频率乘 1.1 到 1.15 做周期约束留出余量。这个余量在独立 FPGA 开发里也很重要但在 eFPGA 上更关键因为 eFPGA 没有独立的时钟管理单元资源时钟树延迟相对更大。5.2 LUT 利用率 70% 看着很低但布线可能已经挤爆了eFPGA 的布线资源和独立 FPGA 不一样。独立 FPGA 通常有丰富的布线资源利用率到达 80% 都不一定难布但 eFPGA 的布线通道数量往往比同规模独立 FPGA 少因为它的布线资源密度要平衡面积和灵活性。我在某个计算密集型设计里LUT 利用率只有 68%但布线拥塞报告显示某些区域的布线需求超过了可用通道的 1.2 倍导致布局布线后的时序变得很差。怎么提前发现这个问题在 Aurora 的布线报告里查看拥塞热力图尤其注意那些有大量多路选择器MUX和宽位宽数据通路的模块。如果拥塞区域集中在个别行列可以考虑调整 RTL 中逻辑的位置分组或者换一个宏单元数量更均衡的 IP 配置。5.3 时序修复不能只依赖工具要理解为什么第一次跑出时序违规我习惯性地像在 Vivado 里那样打开重定时retiming和逻辑复制选项让工具自己优化。这在独立 FPGA 上通常有效但在 eFPGA 评估里容易遇到反效果。原因在于 eFPGA 的 LUT 资源和触发器的位置是固定的工具能做的前瞻和逻辑复制范围受限。与其依赖工具优化不如回到 RTL 层面找问题。举个例子一个用于视频缩放的多级插值滤波器RTL 里为了代码整洁把三次乘加操作写成了三层 if-else 结构。综合后的逻辑层级看着不高但映射到 eFPGA 的 6-LUT 架构后每一级 if 判断都变成了一个 LUT关键路径穿过三个 LUT 还加上了布线延迟。后来我把 if-else 展开成活性的数据通路选择逻辑又用流水线寄存器在每级乘法之后打了一拍Fmax 直接从 180MHz 提升到 260MHz。5.4 功耗报告里的默认活动因子和实际差很多Aurora 默认会根据工作频率自动估算活动因子但这个默认值往往偏高因为它假设大部分内部节点在每个时钟沿都会翻转。对于视频信号处理这种数据相关性很强的设计很多 D 触发器在相当长的时间内并不翻转比如全零或静止画面的像素数据。我测试过一个案例用默认活动因子估算的功耗是 25mW实测评估通过详细 RTL 功耗分析工具只有 17mW。但反过来在高负载信号处理模块里默认活动因子反而可能偏低。所以功耗数字要当作范围来看而不是精确值。如果功耗预算是硬指标建议用多个活动因子设置各跑一轮取悲观值做设计余量。5.5 验证模型要和 Aurora 评估同步更新别各跑各的eFPGA 集成项目里数字验证团队会用 ArcticPro 提供的周期精确模型或者 RTL 仿真模型来验证你的设计集成到 SoC 后的功能。这个模型和 Aurora 评估使用的网表是从同一个 IP 配置导出的吗我在初期的项目里没有注意同步验证组用的是上一版 IP 配置的模型Aurora 里已经换成了新配置结果两边对不上白白浪费了两周调试时间。建议在项目启动时就约定好每次更新 IP 配置必须同步导出新的仿真模型并更新验证环境Aurora 评估工程也同步更新。这两个动作要作为一个整体提交不能只更新其中一个。5.6 版本管理不止管代码还要管配置、约束、报告最后一个坑跟技术关系不大但影响很大。eFPGA 评估过程中会持续调整 IP 配置、约束文件和 RTL 版本每一轮的评估报告如果不做严格的版本管理后面回顾时就很容易混乱。我后来自己会遵守一个习惯每一项配置或约束的改动都单独提交一次 commitcommit message 里注明改动目的和预期的指标变化每个正式报告的 PDF 或 Excel命名时加上日期和配置版本号比如area_report_20250107_cfg_v2.3.xlsx。这样几个星期后再翻出来还能清楚地知道每一份报告对应的是哪一版设计怎么改出来的。6. 评估完成之后怎样把结论落实到 SoC 集成Aurora 评估报告出了不代表工作就结束了。真正重要的是把评估结论转化成后续 SoC 集成的指导和约束。根据我的经验至少要输出三份可执行的交付物第一份是集成规格建议。明确写出 IP 配置版本、工艺节点、宏单元数量、建议摆放区域、时钟和复位连接方式、电源域划分建议。后端和系统集成工程师拿到这份文档可以直接开始做 floorplan 和电源规划。第二份是时序约束模板。Aurora 评估过程中使用的时序约束经过调整后可以整理成一份标准的约束文件模板提供给后端做时钟树综合和时序签核时使用。这个模板要包含所有跨时钟域声明、输入输出延迟约束、伪路径声明避免后端工程师重新摸索。第三份是风险清单。把评估中发现的时序风险点、功耗风险点、布线拥塞区域都列出来标注影响程度和建议措施。比如某个关键路径在评估中裕量偏小建议在 SoC 集成时让这条路径对应的布线区域离 eFPGA 边界近一些缩短跨边界走线延迟。我个人在实际操作中的体会是eFPGA 评估这件事30% 的精力花在工具操作上70% 的精力花在理解设计真实需求、设定合理约束、解读报告隐含信息上。Aurora 本身做得很流畅但它的输出质量完全取决于你的输入质量。所以如果你想真正用好这套评估流程不要急着追求跑完一轮报告先想清楚每个参数设置背后的理由这比多跑几十轮盲目的参数扫描有用得多。