2026年FPGA春招，成电硕士做AI加速方向，面试官问如何用Verilog实现一个支持动态稀疏性的卷积加速器？求设计思路和代码框架

面试官问这个八成是想看你有没有落地过稀疏推理。动态稀疏最难的是运行时才知道哪些权重是零，所以地址映射不能写死。常见做法是预先把非零权重按行/列打包进BRAM，同时存一份坐标索引表。计算时，每个PE读索引表拿到有效权重对应的输入地址，直接从SRAM里抓数据。这样一来，乘累加单元只对非零对做运算，省DSP也省功耗。代码框架可以拆成三个模块：索引管理器、数据分发器、MAC阵列。索引管理器用FSM解析稀疏模式，每次发一个有效权重的地址对。注意时序收敛，索引表深度别太大，否则LUT吃紧。你准备用多少并行的PE？这个会影响地址冲突的处理策略。

你提到Eyeriss，方向是对的，但动态稀疏和静态稀疏实现差异很大。面试官大概率想考察两点：一是你对数据流和存储器分层的理解，二是处理非规则计算时控制逻辑的折衷。设计思路上，我建议分三步。第一，选索引格式。位图适合稠密度较高且对齐的场景，每个权重附带1bit标志，查表简单但处理连续零时浪费BRAM；坐标列表（CSR/CSC）适合高稀疏率，但地址解析逻辑更复杂。第二，计算单元复用。用一组PE，每个PE内部配一个乘法器和累加器，通过使能信号控制是否执行。关键是把索引表和输入数据解耦——索引表存的是输入特征的地址偏移量，而不是绝对地址，这样当卷积窗口滑动时，只更新基地址即可。第三，应对冲突。动态稀疏意味着多个PE可能同时请求同一输入数据，解决办法是加一个简单仲裁器或者让索引管理器预判冲突、提前分发。代码框架上，顶层分四个部分：sparse_controller（读索引并解码）、data_fetcher（根据偏移量取输入）、mac_array（N个PE并行）、output_buffer（写回结果）。控制路径用两级流水，索引解析和MAC计算错开一拍。一个常见的坑是时序——索引表用BRAM时，读延迟会导致流水线气泡，建议把索引表做成双端口读或者用寄存器搭小表。另外面试官可能会追问你数据复用的粒度，比如你是按行复用还是按通道复用，这个会影响带宽利用率。你目前是打算用HLS还是纯Verilog？如果选HLS，动态稀疏的索引管理反而更难控制，个人建议先用Verilog写好关键模块再转HLS优化。你有跑过实际模型验证吗？比如用ResNet-50的稀疏化版本做仿真，看看DSP节省率和吞吐量之间的trade-off。

面试官问这个，八成是想听你说清楚地址映射怎么动态做。别一上来就写代码，先画一个索引管理器+PE阵列的框图，说明白位图或CSR怎么存、每次读几个非零权重、冲突怎么仲裁。成电硕士的话，顺便提一嘴你用过Xilinx的AI Engine或者HLS做过稀疏化试验没，能加分。

动态稀疏最麻烦的不是省DSP，而是控制逻辑把时序吃垮了。个人建议别一上来就搞全动态，先做一个静态稀疏的版本（比如每层固定剪枝率，权重按非零排进BRAM），跑通了再往索引表里加一个valid信号让PE只在非零对干活。你问代码框架的话，核心模块就三个：地址生成器（读索引表）、数据分发器（从SRAM按偏移取特征）、MAC阵列（每个PE配一个使能门控）。注意仲裁器别写太复杂，简单轮询或者用一个FIFO排队就行，否则综合出来频率上不去。海思那边比较看重资源占用汇报，面试时主动提一句你的设计在UltraScale上大概能用多少LUT和DSP，会比光讲思路强。你打算用几个并行PE？这个数字直接决定地址冲突概率和仲裁器深度。

从实际工程角度说，动态稀疏加速器在FPGA上落地有个常被忽略的坑——非零权重的分布是随机的，但BRAM的读写端口是固定的。你用CSR格式存索引，那就意味着每个时钟周期可能读到的非零个数不确定，MAC阵列要么空闲要么排队，吞吐量上不去。Eyeriss那种行静态卷积窗口的思路其实更适合权重稀疏率比较稳定的场景，动态稀疏的话我倾向于用位图+预解码：把每个卷积窗口的权重位图提前读到一组移位寄存器里，然后通过一个priority encoder一次吐出M个非零位对应的坐标，这样MAC阵列的利用率能拉到接近100%。代价是位图占的BRAM比CSR多，但时序好收敛很多。面试官如果追问怎么处理输入特征图的多播冲突，你可以说把输入SRAM做成多bank，每个bank对应一个PE组，索引表里存的是bank号+偏移量，这样不用全局仲裁器。另外提一句，寒武纪那边比较看重低功耗设计，你可以在回答里带一笔门控时钟或者数据选通信号，说明哪些模块在零权重多的时候可以关掉。你现在做仿真验证用的随机稀疏还是真实剪枝模型？后者能暴露更多边界情况，建议提前跑一轮。

面试官问这个，核心是想看你有没有真正动手搭过稀疏数据流。动态稀疏的痛点不在计算本身，而在地址冲突——多个PE同时读到同一个输入地址时怎么办。我的做法是让索引表存的是bank号+局部地址，输入SRAM切成4到8个bank，每个bank独立读写。这样冲突概率降到很低，仲裁器只需要一个简单的round-robin，不会吃掉时序。你写代码的时候先别管MAC阵列多大，先把索引管理器+多bank数据分发器调通，用几个testbench把连续零和随机稀疏两种case覆盖到，面试时能讲清楚这个设计取舍就很加分了。你打算用几个bank？

从工程落地的角度说，动态稀疏卷积在FPGA上最容易被忽略的是「有效计算密度」这个概念。你省了DSP，但控制逻辑和地址仲裁占用的LUT可能把省下来的资源又吃回去了。我建议你分两步走：第一步，先做一个静态稀疏的版本，把权重按层预先排好，非零值连续存进BRAM，每个卷积窗口配一个固定长度的索引表，这样地址映射是确定的，时序很好收敛。第二步，在静态版本基础上引入动态稀疏支持，做法是在每个PE前加一个valid信号和一个小FIFO，权重非零时才从FIFO取出对应的输入地址去抓数据。这样控制逻辑是渐进式增加的，出了问题也好定位。代码框架上，顶层就三个模块：地址生成器（读索引表并广播地址）、数据分发器（多bank SRAM + 仲裁）、PE阵列（每个PE含乘法器+累加器+使能门控）。注意仲裁器不要写复杂的状态机，一个简单的priority encoder加一个流水线寄存器就够了，否则综合出来频率掉到200MHz以下很难看。面试官如果追问资源占用，你可以主动说在Xilinx KU系列上，8个PE大概用3000 LUT和16个DSP，索引表深度控制在512以内。你用的板子型号是什么？不同器件的BRAM块大小不一样，索引表深度设计差别还挺大的。

其实可以换个角度想：动态稀疏不一定非要全动态。面试官问这个问题，很多时候是想看你有没有意识到「稀疏模式可以在运行时被提取并缓存」。一个比较实用的折衷方案是：在每层计算开始前，先用一个预扫描模块把这一层权重的非零位置读出来，生成一张位图存进分布式RAM，然后整个卷积过程就按照这张位图来调度。这样地址映射逻辑在层与层之间是静态的，只在一层开始前更新一次，控制逻辑复杂度大幅降低，代价是多花几十个时钟周期做预扫描。对于典型的VGG或ResNet层来说，这个开销基本可以忽略。你可以在面试时提一句这个思路，说明你考虑过控制逻辑和计算效率之间的trade-off，而不是一味追求纯动态。另外写代码时注意位图用移位寄存器实现，比BRAM读出延迟小，更容易收时序。你准备用哪个网络做验证？不同层的稀疏率差异很大，预扫描模块的FIFO深度要跟着调。

你提到Eyeriss，这是个很好的参考起点，但动态稀疏和静态稀疏在实现上差异很大。动态稀疏最核心的难点不是省DSP，而是怎么让地址映射跟上权重非零位置的变化。我建议你别一上来就写全动态的代码，先做一个混合方案：每层计算开始前，用一个小FSM扫描权重位图，把非零位置的坐标和对应输入地址提前存进一组分布式RAM里，作为这一层的静态索引表。这样在整个卷积层计算过程中，地址映射是确定的，PE只管按索引表取数和做乘累加，控制逻辑简单很多，时序也容易收敛。代价是每层开始前多花几十个周期做预扫描，但对于VGG或ResNet这种层数不深的网络来说几乎没影响。代码框架上，顶层分成三个模块：索引管理器（负责预扫描和生成索引表）、数据分发器（多bank SRAM加轮询仲裁）、PE阵列（每个PE配一个使能门控）。注意仲裁器别写复杂状态机，一个简单的round-robin配合FIFO排队就行，否则综合出来频率上不去。面试时如果能主动提一句你在UltraScale上大概估过LUT和DSP用量，会比光讲思路更有说服力。你打算用哪个网络做验证？不同层的稀疏率差异很大，预扫描模块的FIFO深度得跟着调。

动态稀疏卷积加速器在FPGA上落地，最容易被面试官看穿的一个坑是：你只想到了省DSP，但没算控制逻辑和地址仲裁吃了多少LUT。工程上有个很实际的取舍——你可以把稀疏感知的计算单元设计成数据流驱动的，而不是指令驱动的。具体做法是：权重和输入特征图都按非零对打包，每对包含一个权重值、一个输入地址偏移量和一个输出累加地址。PE内部只配一个乘法器和一个累加器，当valid信号为高时才执行运算，否则保持空闲。这样一来，地址映射完全由数据流本身携带，不需要全局状态机去解析稀疏模式。你问代码框架，核心就是三个部分：一个打包器（从BRAM里按行读出权重和输入，筛掉零值后拼成数据包），一个分发网络（用简单交叉开关把数据包广播到各个PE，冲突时用FIFO缓冲），以及PE阵列本身。打包器是这里的关键，它可以用一个双端口BRAM配合一个计数器来实现：每个时钟周期读出一组权重和对应输入地址，如果权重非零就把这对数据写入FIFO，否则跳过。这样打包过程是流水线化的，不会成为瓶颈。面试官如果追问多PE冲突怎么处理，你可以说把输入SRAM切成4个bank，每个PE固定绑定一个bank，打包器在生成数据包时就把bank号算进去，这样分发网络不需要全局仲裁，每对数据只流向对应bank的PE，冲突概率降到极低。这种设计思路的好处是控制逻辑非常规整，时序好收敛，而且扩展性强——要增加并行度，只需要加PE和对应bank就行，打包器和分发网络几乎不用改。你准备用几个并行PE？这个数字直接决定bank切分粒度，也影响打包器FIFO的深度设计。