我的毕业设计是做基于FPGA的实时H.264视频编码器，用Zynq平台实现。现在卡在运动估计部分，SAD（绝对差值和）计算需要处理大量像素数据，纯Verilog实现占用了超过LUT 20k，远超出目标15k。我试过用HLS做pipeline优化，但资源下降不明显。有没有什么方法能减少SAD计算单元的数量？比如用分时复用或者搜索窗口缩小？另外，如何用Block RAM缓存参考帧数据来减少AXI总线访问？希望有做类似毕设的学长学姐给点建议。
回答 3
兄弟，你这个20k LUT超标的痛点我太懂了，纯Verilog做全并行SAD确实猛但资源爆炸。首先，分时复用绝对是首选：把SAD计算单元从全并行改成4×4或8×8的块级流水，比如一次只算4个像素的绝对值累加，分多次凑齐16×16宏块的总SAD，这样LUT能砍到原来的三分之一以下。搜索窗口缩小也有效，从±16降到±8，运动矢量精度可能降一点，但大部分视频场景够用。其次，Block RAM缓存一定要用双端口模式，把参考帧的搜索窗口区域提前从DDR搬到BRAM，计算时只读BRAM，避免AXI频繁访问。你用HLS时注意加DATAFLOW和ARRAY_PARTITION，别让编译器把BRAM都综合成LUT。最后建议先搭一个小规模的8×8块验证，资源压到10k以内再扩到16×16。
学长来给你支个招。SAD计算占LUT多的根源是每个像素的绝对差并行比较和累加器太多。你要做的是：第一，把16×16宏块拆成4个8×8子块，用四个SAD计算单元分时复用，每个周期算一个子块的四分之一，这样LUT从20k降到8k左右，但时钟要跑高一点来弥补吞吐量。第二，参考帧缓存用Zynq的BRAM，设置成两个bank ping-pong操作，一个bank存当前搜索窗口，另一个从DDR预取下一帧数据，用DMA或者AXI_HP口，带宽够用。注意BRAM深度要算好，比如搜索窗口±16需要32×32像素，一个像素8bit，那BRAM至少1KB，Zynq的BRAM很多，别怕不够。第三，HLS优化时加PIPELINE II=1和UNROLL factor=4，同时禁用不必要的fifo，资源能再降。实测这样能把LUT控在12k左右，留余量给其他模块。
你好，我去年刚做完类似毕设，踩过同样的坑。核心思路是放弃全并行SAD，改用基于行的流水线结构。具体：用8个并行的绝对差计算单元，每个单元处理一行16个像素，然后用树形加法器逐级累加，这样LUT从20k降到10k出头。但要注意加法器级数别太多，4级树就够了，否则时序崩。参考帧缓存方面，用Zynq的BRAM做双重缓存：一个BRAM存当前搜索窗口的32×32区域，另一个预存下一帧数据，通过AXI_HP口的突发读取实现，每次读64字节，效率很高。另外，搜索窗口别用全搜索，改用三步法或菱形搜索，运动估计次数从256次降到20次左右，SAD计算总量陡降，逻辑资源自然省。最后提醒：HLS的pipeline优化要配合数组分块，否则综合工具会自动生成大堆LUT，用#pragma HLS ARRAY_PARTITION variable=ref complete dim=0试试。祝你顺利过毕设。
发表回答
登录后可在本页底部提交回答
游