2026年FPGA校招笔试题：手撕Verilog实现AXI4-Stream实时JPEG压缩，DCT变换的流水线设计怎么避免数据冲突？

说一个很多人踩过的坑：一上来就试图把整个8×8 DCT的64个乘法器全排成单周期，结果组合逻辑爆炸，时序一塌糊涂。面试官问的流水线深度，其实不是让你背一个固定数字，而是让你讲清楚行列分离结构里每一拍在干什么。常见做法是行一维DCT用8个时钟处理一行，每拍算一个像素的蝶形运算，这样行处理本身就需要8级流水线（加上输入寄存器可能到10级左右）。转置缓存那边，双端口BRAM的地址映射要注意：写入时按行优先，读时按列优先，但千万别在同一个时钟周期对同一个地址同时读写，否则BRAM的读后写行为跟你的预期可能不一样。解决办法是把读地址延迟一拍，或者让写使能提前一拍关闭，这样转置存储那一级就能无冲突地乒乓起来。我个人建议你在仿真里先测一个最坏情况：连续输入两个8×8块，看第二块的行处理是否因为转置RAM没读完而卡住。这个卡住的地方往往就是流水线深度不够或者地址冲突的点。另外，校招手撕代码通常不会让你把完整的JPEG压缩全写完，更多是考你单模块的时序控制，比如只写DCT的行列分离和转置存储，面试官会追问你怎么把AXI4-Stream的握手信号跟流水线衔接。准备时把这一小段调通，比背一个完整工程更有效。你目前用的仿真工具是Vivado还是Modelsim？不同工具的BRAM原语例化写法有点差别，容易踩坑。

转置存储的地址冲突本质是读写指针追赶问题，把BRAM的读地址比写地址滞后两拍就行，别想复杂了。

其实面试官最想听的不是代码细节，而是你对数据流阻塞点的判断。8×8 DCT流水线的瓶颈通常不在运算单元，而在转置RAM的带宽。你想想，行DCT每8个时钟输出一行，但列DCT需要每8个时钟读一列，而BRAM一个时钟只能读一个地址，所以必须用双端口同时读列数据和写行数据。关键技巧是把行DCT的输出先缓存到一个移位寄存器里，等够8个像素后再一次性写入BRAM，这样写操作只占一个时钟，读操作可以错开。至于流水线深度，我见过16级到22级都有人用，取决于你乘法器是否拆成多周期。建议你先固定一个深度跑时序，如果setup slack不够就加一级寄存器，别一开始就追求最小深度。另外提醒一句，AXI4-Stream的tvalid和tready握手会打断流水，记得在每级加valid-ready寄存器链，否则数据冲突会从DCT传播到后续的量化模块。

个人感觉你卡住的点其实很典型，很多同学在课设里只写过单块DCT，没处理过AXI-Stream的连续流。面试官问流水线深度，不是要你背数字，而是想看你怎么拆周期。我建议你按三步走：第一步，先确定行DCT每拍只算一个蝶形运算，8个像素需要8拍，加上输入寄存和输出寄存，行处理部分大约10级。第二步，转置缓存用双端口BRAM，写地址按行递增，读地址按列递增，但有个坑——BRAM在同一个时钟对同一地址同时读写时，读出的可能是旧值，所以要让读地址比写地址滞后两拍，或者用写使能提前一拍关闭。第三步，列DCT的结构和行一样，但要注意列DCT的输入来自转置RAM，必须等够8个列数据才能开始，所以总流水线深度在16到22级之间。你可以在仿真里故意构造一个最坏情况：连续输入两个8×8块，看转置RAM的读指针是否因为写指针太快而覆盖了未读数据。如果发生冲突，一个简单的补救办法是给转置RAM加一个空满标志，当读完一整列之前禁止写入新行。另外提醒一下，AXI-Stream的tvalid和tready握手会打乱节奏，建议在行DCT和列DCT之间插入一个FIFO来解耦，深度设成64即可。你现在的仿真环境是Vivado还是Modelsim？不同工具对BRAM的读后写行为有细微差异，最好先用IP核的仿真模型确认一下。

转置存储的读写冲突本质是地址追赶，你把BRAM的读地址比写地址固定滞后3个时钟周期，用计数器控制，不用搞复杂的状态机。

其实从工程角度看，你纠结的流水线深度和转置冲突，根源都在于你试图用纯时序逻辑去管理数据流，而忽略了握手机制带来的反压。面试官真正想考察的，是你能否从系统层面理解AXI-Stream的backpressure对DCT流水线的影响。我见过一个常见的错误解法：在行DCT的每级流水线里都加了valid-ready寄存器链，但没考虑列DCT处理完一块需要8个时钟，而行DCT每8个时钟就能输出一行，如果列DCT还没处理完上一块，转置RAM就会被写指针覆盖。正确的做法是给转置RAM配一个写指针和读指针，外加一个计数器记录已写入但未读出的行数，当这个计数器等于8时，说明整个8×8块已经写完但列DCT还在处理，此时必须拉低行DCT输出端的tready，暂停行DCT的输出。这相当于在行列之间做了一个握手的信用管理。至于流水线深度，我建议你先用最直接的方式写一个16级流水——行8级、转置1级、列8级——跑一次综合看时序。如果setup slack不够，优先在乘法器输出后加寄存器，而不是在数据路径中间乱插。另外，很多同学做转置缓存时喜欢用移位寄存器阵列，但8×8块用BRAM更省资源，而且双端口BRAM天然支持同时读写不同地址，只要控制好地址偏移就不会冲突。你现在的开发板型号是什么？如果是Xilinx的7系列，BRAM的读延迟是1拍，写延迟是0拍，这个特性会影响你地址偏移的设计——读地址必须比写地址提前至少1拍，否则读到的就是上一次写入的数据。最后给你一个学习路径建议：先别急着写JPEG完整链路，单独写一个带AXI-Stream接口的8×8 DCT模块，用testbench模拟连续块输入，重点观察转置RAM的读写指针是否会在块边界处追尾。把这个模块调通后，再集成到JPEG里会省很多debug时间。

其实你卡住的地方，很多应届生第一次做都遇到过。别急着写代码，先画时序图：从AXI-Stream的tvalid/tready握手开始，画出行DCT每拍输出一个像素，转置BRAM写地址按行递增，读地址按列递增。关键约束是读地址必须比写地址滞后至少两拍，否则BRAM的读写冲突会让你读到旧数据。流水线深度不用一开始就定死，我习惯先搭一个16级的基础框架——行处理8级、转置缓存2级、列处理6级，然后用时序分析工具看最差路径，哪里slack不够就在哪里加一级寄存器。面试官看的是你调试思路，不是背数字。你用的是Xilinx还是Intel的器件？不同厂家的BRAM读写延迟不一样，会影响你滞后的拍数。

我个人感觉，你现在的困境不是不会写DCT，而是没想清楚面试官到底在考察什么。校招笔试里手撕JPEG压缩，对方真正想看的不是你把64个乘法器排得多漂亮，而是你面对一个实时流处理系统，能不能识别出数据依赖的瓶颈在哪里。DCT行列分离结构是经典的二维变换加速方法，但很多同学一上来就掉进转置存储的坑里——他们以为只要把行结果写进BRAM、再按列读出来就行了，忽略了行DCT每8个时钟输出一行，而列DCT必须等够整列8个数据才能开始算，这中间天然就有8个时钟的等待窗口。如果你不用乒乓操作，这个等待窗口就会让流水线断流。正确的做法是配两块转置RAM，一块被行DCT写入时，另一块被列DCT读取，两块交替角色。这样流水线深度可以稳定在16到18级之间，吞吐率不会因为等待而下降。至于具体的BRAM地址映射，我建议你用行坐标乘8加列坐标作为写地址，读时反过来用列坐标乘8加行坐标，这样地址生成逻辑就是简单的累加器加计数器，组合逻辑面积很小。另外提醒一点：面试官如果追问流水线深度怎么定，千万别只答一个数字。你要讲清楚你分了几级流水线，每一级在做什么逻辑操作，比如第一级是输入寄存，第二级是蝶形运算的左半部分，第三级是右半部分加进位链，等等。这样才显得你真的理解时序。你手头有现成的仿真环境吗？可以先搭一个单块DCT的testbench，故意把两个8×8块连续输入，看转置RAM的读写指针会不会碰撞，这个测试比写代码更能暴露问题。

换一个角度说吧，你纠结的流水线深度其实没那么玄乎。工程上最稳妥的做法是先按最保守的深度搭出来，比如行处理每拍只算一个蝶形运算，加上输入寄存和输出寄存，行部分就12级了；转置缓存用双端口BRAM，读地址比写地址滞后3拍，再多加一级输出寄存，这里3级；列部分和行一样12级。加起来27级，看起来很大，但时序非常干净，setup slack很充裕。面试官如果嫌深，你再告诉他可以优化：把行DCT的蝶形运算拆成更细的流水线，比如把乘法器和加法器分开成两级，这样总深度能降到22级左右。记住一点，面试里提出一个保守方案再主动给出优化方向，比一开始就给一个激进的方案要好得多，因为后者万一被追问为什么没考虑某个边界情况，你容易答不上来。另外有个小技巧：转置RAM的读写地址冲突，你可以用写使能提前一拍关闭来规避，而不是搞复杂的仲裁逻辑。你现在的Verilog水平能直接手写BRAM例化吗？如果只能用推断写法，记得在always块里把读地址和写地址分开赋值，否则综合工具可能推断出单端口RAM。

转置RAM冲突说白了就是读指针追写指针，你让读地址比写地址固定滞后3拍，再用一个计数器记录已写完多少行，列DCT开始读之前先等够8行数据写进去，基本就不会出问题。代码不用写太复杂，双端口BRAM一边写一边读，地址错开就行。