1. 为什么我要自己造一块AI加速器2023年的时候我在一个边缘计算项目里被一块推理卡坑得很惨。模型本身只有几兆大小算力需求也不算夸张但市面上能买到的通用方案要么功耗高得离谱要么延迟抖动大得没法做实时控制。那段时间我反复在想一个问题为什么不能针对自己的模型结构做一块专用的加速器这个念头一旦冒出来就压不住了。后来花了大概四个月从指令集定义、矩阵运算单元设计、存储层次规划到用FPGA做原型验证再到跑通一个简化版的卷积网络算是把整条链路走了一遍。这篇文章就是把这四个月里踩过的坑、做过的取舍、以及那些教科书上不会写的细节完整地摊开来讲。先说清楚定位这不是一篇教你流片做芯片的文章那需要千万级预算和完整的EDA工具链。这里讲的是一条从零开始、以FPGA为载体的AI加速器设计路径核心是理解加速器的架构逻辑用可综合的硬件描述语言把矩阵计算单元、数据搬运通路、控制状态机搭出来最终能在真实硬件上跑通推理。适合谁看如果你写过Python训练模型但对硬件设计只有模糊概念这篇文章会帮你建立从算法到电路的映射思维。如果你已经做过FPGA开发但没接触过AI加速器这里面的数据复用策略和脉动阵列设计思路会很有参考价值。如果你只是好奇手机里的NPU到底在干什么看完你会有个具象的认知。整个设计围绕一个核心矛盾展开矩阵乘法需要极高的数据吞吐但存储器的带宽和容量永远是瓶颈。AI加速器的本质就是在算力、带宽、面积、功耗这四个维度上找平衡点。后面所有的架构决策都是这个矛盾的展开。2. 先想清楚算什么东西从矩阵乘法到硬件映射2.1 神经网络推理的数学本质不管网络多复杂推理阶段的核心计算就是矩阵乘加。一个全连接层是Y WX b一个卷积层展开后也是矩阵乘法。区别只在于数据怎么排布、有没有权重共享。拿一个最简单的卷积层举例输入特征图是H×W×C卷积核是K×K×C×N输出是H×W×N。如果把它看成矩阵运算可以把每个输出像素位置对应的输入窗口拉成一个向量卷积核拉成矩阵就变成了输出矩阵 权重矩阵 × 输入矩阵。这个视角转换非常关键。因为一旦看成矩阵乘法硬件设计就有了统一的优化目标让乘加运算单元尽可能不停地工作同时让数据搬运的代价尽可能小。我当时的做法是先统计目标模型的算子分布。跑了一个轻量级的图像分类网络发现卷积层占了总计算量的92%以上全连接层不到8%。这意味着加速器的设计重心必须放在卷积上全连接层可以复用同一套矩阵运算单元不需要单独优化。2.2 为什么不用CPU或GPU而要自己设计这个问题我被问过很多次。CPU的问题在于它的架构是为通用性设计的大量的面积花在了分支预测、乱序执行、多级缓存一致性上真正做乘加运算的ALU占比很小。跑一个矩阵乘法CPU大部分时间在搬数据和控制流程算力利用率可能只有个位数百分比。GPU好很多它有大量的流处理器可以做并行乘加。但GPU的功耗和面积对于边缘设备来说还是太大而且它的编程模型是SIMT需要把矩阵运算拆成成千上万个线程调度开销和寄存器压力都不小。更关键的是GPU的存储层次是固定的你没法针对特定模型的数据复用模式做定制。NPU的思路就是把这些通用性全部砍掉只保留矩阵运算需要的最小控制逻辑把面积和功耗全部堆到乘加阵列和片上存储上。我实测下来同样一个卷积层在FPGA上做的专用加速器比同期的嵌入式GPU方案能效比大概高出三到五倍。当然这个数字跟具体实现和工艺有关但方向是明确的。2.3 确定加速器的能力边界在动手写第一行代码之前必须先把加速器的规格定死。我给自己列了一张表设计维度我的选择理由支持算子卷积、全连接、池化、ReLU覆盖目标网络全部算子数据精度INT8量化精度损失可接受面积和功耗大幅降低峰值算力约0.5 TOPSFPGA资源限制下的合理目标片上存储输入缓存权重缓存输出缓存减少对片外存储的访问接口AXI4方便与处理器和DMA对接时钟频率100MHzFPGA时序收敛的稳妥选择这张表看起来简单但每一项背后都有取舍。比如为什么选INT8而不是FP16因为FP16的乘法器面积大概是INT8的四倍而目标模型的量化精度损失在1%以内完全能接受。为什么峰值算力定0.5 TOPS因为我用的FPGA有大约2000个DSP切片每个切片一个时钟周期做一个乘加100MHz下理论峰值就是0.4 TOPS左右定0.5是留了点余量。这里有个经验规格不要定得太满。我第一次设计时想把所有算子都支持结果控制逻辑复杂到状态机根本写不下去。后来砍掉了转置卷积和空洞卷积只保留最核心的几种反而顺利跑通了。3. 矩阵运算单元加速器的心脏怎么搭3.1 从单个乘加器到脉动阵列最朴素的矩阵乘法硬件实现就是一堆乘加器排成一行每个时钟周期取一行权重和一组输入算完累加。但这样有个致命问题权重和输入数据需要反复从存储器读取带宽根本扛不住。脉动阵列的思路是让数据在计算单元之间流动而不是每次都从存储器取。想象一排工人站在传送带旁边每个工人手里拿着一个权重输入数据像流水一样从左边传进来每经过一个工人就做一次乘加结果往右边传。这样输入数据只需要从左边进一次权重只需要预先加载一次数据复用率极高。我设计的阵列是8×8的也就是64个乘加单元。每个单元包含一个INT8乘法器、一个32位累加器、以及若干寄存器用于暂存数据和权重。阵列的输入是8个激活值和8个权重输出是8个部分和。为什么选8×8因为FPGA的DSP切片数量有限64个乘加单元已经占用了大部分资源。而且8×8的阵列对应的数据位宽和缓存大小比较匹配再大就会导致缓存溢出反而降低效率。3.2 数据流设计权重固定还是输出固定脉动阵列有三种经典数据流权重固定、输出固定、行固定。我选的是权重固定原因是卷积层的权重可以预先加载并保持不变而输入数据不断变化。权重固定意味着权重只需要在换层时重新加载推理过程中不需要反复搬运权重节省了大量带宽。具体实现上每个乘加单元有一个权重寄存器在层初始化阶段通过配置通路把权重写进去。推理阶段输入数据从阵列左侧流入每个周期向右移动一格。部分和从阵列底部流出进入累加器。这里有个细节部分和的位宽。INT8乘INT8的结果是16位但累加多个乘积后位宽会增长。我用了32位累加器理论上可以累加65536个乘积而不溢出。对于目标网络的卷积核大小这个位宽绰绰有余。3.3 乘加单元的电路细节单个乘加单元的结构其实不复杂但有几个地方容易出错。乘法器我用的是Booth编码的INT8乘法器综合后大约占用一个DSP切片。累加器是一个32位加法器带一个寄存器。关键路径在乘法器和加法器之间需要插入流水线寄存器来保证时序收敛。我一开始没加流水线综合后时序报告显示最高频率只能跑到60MHz左右。后来在乘法器和累加器之间插了一级寄存器频率直接上到120MHz。代价是延迟增加了一个周期但对于推理任务来说吞吐量比延迟重要得多。还有一个坑是符号扩展。INT8是有符号数乘法结果需要正确地进行符号扩展后再累加。我第一版忘了处理负数导致推理结果完全错误。后来在乘法器输出后加了一个符号扩展逻辑问题解决。// 乘加单元的核心逻辑简化版 module mac_unit( input clk, input rst_n, input signed [7:0] activation, input signed [7:0] weight, input signed [31:0] partial_sum_in, output signed [31:0] partial_sum_out ); reg signed [15:0] product; reg signed [31:0] accum; always (posedge clk or negedge rst_n) begin if (!rst_n) begin product 16b0; accum 32b0; end else begin product activation * weight; accum partial_sum_in {{16{product[15]}}, product}; end end assign partial_sum_out accum; endmodule这段代码里{{16{product[15]}}, product}就是符号扩展把16位乘积扩展到32位。少了这个负数乘法就会出错。4. 存储层次比算力更关键的瓶颈4.1 为什么存储设计决定加速器上限有个数据很能说明问题在典型的矩阵乘法中每做一次乘加运算需要读取两个操作数。如果操作数都从片外DRAM读取那么算力再高也没用因为DRAM带宽根本喂不饱计算单元。我算过一笔账8×8阵列在100MHz下每秒需要8×8×100M 6.4G次乘加。每次乘加需要两个INT8操作数就是12.8GB/s的数据吞吐。而一块普通的DDR3带宽大概在8GB/s左右根本不够。所以必须靠片上缓存来复用数据把片外访问降到最低。这就是存储层次设计的核心目标让数据在片上多待一会儿被尽可能多的计算单元复用。4.2 输入缓存、权重缓存与输出缓存的分工我设计了三块片上缓存输入缓存存放当前层的输入特征图。大小是16×16×32字节对应一个较大的输入窗口。输入数据从片外一次性搬进来然后在阵列计算过程中反复读取。权重缓存存放当前层的权重。大小是8×8×32字节对应阵列一次能处理的权重块。权重在层初始化时加载推理过程中只读。输出缓存存放部分和和最终输出。大小是16×16×32字节。部分和在阵列计算过程中累加最终结果写回片外。三块缓存都用双端口BRAM实现一个端口给计算阵列读一个端口给DMA写。这样数据搬运和计算可以并行不会互相阻塞。缓存大小的选择有个经验公式输入缓存至少要能放下阵列一次计算所需的全部输入数据否则阵列会频繁等待数据。我选的16×16×32对应的是阵列处理一个16×16输出块所需的输入窗口刚好匹配。4.3 数据复用策略卷积窗口的滑动技巧卷积计算有个天然的数据复用机会相邻的输出像素共享大部分输入数据。比如一个3×3卷积输出像素(i,j)和(i,j1)的输入窗口有6个元素是重叠的。我的做法是在输入缓存里维护一个滑动窗口。当阵列计算完一个输出块后窗口向右滑动只需要从片外加载新进入窗口的那一列数据而不是重新加载整个窗口。这样片外访问量能降低到原来的三分之一左右。权重那边的复用更简单同一层的权重对所有输出位置都是一样的所以权重缓存只需要在层切换时更新一次。这也是权重固定数据流的优势所在。实测数据用了滑动窗口复用后片外带宽需求从12.8GB/s降到了4.2GB/s左右普通的DDR3就能满足。这个优化对整体能效比的贡献比单纯增加计算单元还要大。5. 控制逻辑与指令调度让数据流听话5.1 状态机设计从加载到写回的全流程加速器的控制核心是一个有限状态机管理整个推理流程。我把它分成五个状态IDLE等待启动信号。LOAD_WEIGHT从片外加载当前层的权重到权重缓存。LOAD_INPUT从片外加载输入数据到输入缓存。COMPUTE启动脉动阵列进行矩阵乘加部分和写入输出缓存。WRITE_BACK把输出缓存的结果写回片外然后跳转到下一层或回到IDLE。状态之间的跳转条件需要仔细设计。比如COMPUTE状态什么时候结束我的做法是维护一个计数器记录已经完成的输出块数量当计数器达到当前层的总块数时跳转到WRITE_BACK。这里有个容易忽略的点层与层之间的依赖。下一层的输入是上一层的输出所以必须等WRITE_BACK完成后才能开始下一层的LOAD_INPUT。我在状态机里加了一个层计数器确保顺序执行。5.2 指令集设计用微码描述每一层为了让加速器能灵活支持不同的网络结构我设计了一套简单的微指令。每条指令描述一个层的配置字段位宽含义opcode4算子类型卷积/全连接/池化input_addr16输入数据在片外的起始地址weight_addr16权重在片外的起始地址output_addr16输出数据在片外的起始地址input_size16输入特征图尺寸kernel_size8卷积核尺寸stride4步长channel_in8输入通道数channel_out8输出通道数这些微指令在推理开始前由主控处理器写入加速器的指令缓存。加速器逐条读取指令配置状态机执行对应的层。这样换一个网络只需要重新生成微指令序列硬件不需要改动。微码的好处是灵活坏处是需要额外的指令缓存和译码逻辑。我权衡后觉得值得因为如果每换一个网络都要重新综合硬件那开发效率太低了。5.3 流水线冲突与数据冒险的处理脉动阵列是深度流水线结构数据从输入到输出要经过多个周期。如果控制逻辑没有处理好就会出现数据冒险。我遇到的一个典型问题是当阵列还在计算上一个输出块时输入缓存已经被新数据覆盖了。原因是LOAD_INPUT和COMPUTE两个状态没有正确同步。后来我加了一个双缓冲机制输入缓存分成两块一块给当前计算用一块给下一块数据加载用。当计算完成时切换缓冲区的角色。权重缓存也有类似问题但因为权重只在层切换时加载冲突概率低很多。我的做法是在LOAD_WEIGHT状态时暂停阵列等权重加载完成后再启动COMPUTE。这些同步逻辑写起来很琐碎但少一个就会导致结果错误。我的建议是画一张完整的时序图把每个状态下的数据流向都标清楚然后再写代码。6. 用FPGA把设计跑起来从仿真到上板6.1 仿真验证先让行为模型跑通在写可综合代码之前我先用Python写了一个行为级的模拟器。这个模拟器不关心时序只验证算法逻辑给定输入和权重计算输出和PyTorch的结果对比。这一步非常关键。因为硬件调试的成本远高于软件如果算法逻辑本身有问题上板后根本无从查起。我的模拟器大概200行Python实现了卷积、池化、全连接的前向计算以及INT8量化。量化是个容易出问题的地方。我用的对称量化把浮点权重和激活值映射到[-127, 127]的整数范围。缩放因子根据每层的最大值动态计算。模拟器里跑出来的精度损失在0.8%左右可以接受。模拟器跑通后我用Verilog写了一个对应的行为级模型用相同的测试向量验证。两个模型输出一致后才开始写可综合的RTL代码。6.2 综合与实现时序收敛的实战技巧综合的时候遇到了几个典型问题。第一个是资源超限。8×8阵列加上三块缓存BRAM和DSP的使用率都超过了80%。我不得不把输入缓存从16×16×32缩小到12×12×32牺牲了一点数据复用率换来了资源余量。第二个是时序违例。关键路径在乘法器和累加器之间组合逻辑延迟太大。我插了两级流水线寄存器把路径切成三段频率从60MHz提到了110MHz。代价是阵列的填充延迟增加了两个周期但吞吐量提升明显。第三个是布线拥塞。脉动阵列的互连非常密集布局布线工具经常报拥塞。我的解决办法是给阵列加区域约束让它集中在一个区域减少长距离布线。另外把权重加载通路和激活值通路分开布局避免互相干扰。综合报告里我重点关注三个指标LUT使用率、DSP使用率、BRAM使用率。目标是都控制在85%以内留出余量给后续修改。最终实现下来LUT用了72%DSP用了81%BRAM用了78%算是比较健康的水平。6.3 上板实测性能与功耗的平衡上板测试用的是Xilinx的Zynq开发板PS端跑Linux负责加载数据和启动加速器PL端就是我的加速器设计。实测性能在100MHz时钟下跑一个约50M MAC的卷积网络耗时约12ms等效算力约0.42 TOPS。功耗方面PL端动态功耗约1.8W加上PS端总共约3.5W。能效比大约是0.12 TOPS/W。这个数字跟专用ASIC比差很远但考虑到FPGA的工艺和架构限制已经达到了我的预期。更重要的是整个设计流程走通了从算法到硬件到实测每个环节都摸清楚了。一个实测发现输入缓存的命中率对性能影响极大。当输入特征图尺寸不是缓存大小的整数倍时滑动窗口会频繁失效导致片外访问量激增。后来我在数据排布时做了padding让每层输入都对齐到缓存边界性能提升了约20%。7. 踩过的坑与设计迭代中的教训7.1 量化精度损失比预想的大第一版设计我用了INT4量化想着面积能再小一半。结果跑出来的分类准确率掉了15个百分点完全不可用。后来分析发现INT4对权重分布的表示能力太弱很多小权重直接被量化成零。改回INT8后精度恢复。但我也学到了一件事量化位宽不是越小越好要看权重的实际分布。如果权重集中在零附近低位宽会丢失大量信息。后来我加了一个逐通道的缩放因子让每个输出通道有自己的量化参数精度又提升了0.3个百分点。7.2 状态机的死锁问题调试阶段遇到过一次死锁加速器卡在COMPUTE状态出不来。用逻辑分析仪抓信号发现输出块计数器的值比预期少了一个导致状态机永远等不到完成条件。根因是边界处理。当输出特征图的尺寸不能被阵列大小整除时最后一块的输出块尺寸会小于阵列大小。我的计数器逻辑没有处理这种情况导致计数错误。修复方法是在微指令里增加一个有效输出块数字段状态机根据这个字段判断是否完成而不是根据理论计算值。这个坑让我意识到硬件设计里所有边界条件都必须显式处理不能像软件那样靠运行时判断。因为硬件没有异常处理机制一个边界错误就会导致整个系统挂死。7.3 带宽估算与实际差距设计初期我估算片外带宽需求是4GB/s选了DDR3。但实测发现峰值带宽需求到了6GB/sDDR3偶尔会成为瓶颈。原因是我的估算没有考虑DMA的效率损失。实际DMA传输有握手开销、仲裁延迟、刷新周期有效带宽大概只有理论值的70%。后来我把输入缓存加大提高了数据复用率才把峰值带宽压回4GB/s以内。教训是带宽估算要留至少50%的余量因为实际系统中的开销远比理论模型复杂。8. 如果重新来过架构优化的几个方向8.1 从8×8到16×16阵列扩展的代价如果FPGA资源允许把阵列从8×8扩展到16×16峰值算力能翻四倍。但代价是互连复杂度呈平方增长布线拥塞会非常严重。而且缓存大小也要相应增加否则数据供应跟不上。我的建议是不要盲目扩大阵列。先算清楚缓存带宽能不能支撑再决定阵列大小。一个经验法则是阵列的输入带宽需求不能超过缓存带宽的80%否则阵列会经常饿死。8.2 加入稀疏化支持跳过零权重目标网络量化后有很多零权重如果能跳过这些零算力利用率能提升不少。实现方法是在权重缓存里加一个有效位掩码阵列遇到零权重时跳过乘加。但这样会增加控制逻辑的复杂度而且稀疏模式不规律时跳过逻辑本身的开销可能抵消收益。我试过一版在稀疏度50%的情况下性能只提升了15%左右不太划算。如果稀疏度能到80%以上可能值得做。8.3 多核架构用多个小阵列替代一个大阵列另一个思路是用四个4×4的小阵列替代一个8×8的大阵列每个小阵列独立处理不同的输出通道。这样互连更简单布线更容易而且可以灵活分配任务。缺点是权重需要复制多份缓存面积增加。而且多个阵列之间的同步需要额外逻辑。我目前还在评估这个方案初步仿真显示在通道数较多的层上多核架构的效率更高。9. 一些实操层面的建议如果你也想动手做一块自己的AI加速器我有几个具体的建议。先从仿真开始不要急着上板。用Python或C写一个行为模型把算法逻辑验证清楚。硬件调试的时间成本是软件仿真的十倍以上前期多花时间在仿真上后期能省大量调试时间。规格要砍到最小可用。不要想着支持所有算子先支持一个卷积和一个全连接跑通一个最简单的网络。我第一版想支持七种算子结果三个月都没跑通。后来砍到两种两周就上板了。存储设计比计算设计更重要。花在缓存大小、数据复用、带宽估算上的时间应该比花在乘加单元上的时间多。计算单元是规则的存储访问模式是不规则的后者才是难点。时序收敛要提前考虑。写RTL的时候就要想好哪里插流水线不要等综合报违例了再改。关键路径通常在乘法器、加法器、多路选择器这些组合逻辑上提前规划好流水线级数。留足资源余量。FPGA资源用到90%以上时布局布线会变得极其困难时序也很难收敛。控制在80%左右比较稳妥给后续优化留空间。最后说一个心态上的体会设计加速器是个系统工程涉及算法、架构、电路、工具链多个层面。不要指望一次成功迭代是常态。我前后改了五版才达到可用的状态每一版都解决了上一版暴露的问题。这个过程本身比最终的性能数字更有价值。