我在用Zynq做实时视频去雾的毕设项目，暗通道先验算法已经用Verilog实现了，但透射率计算这一步特别慢，现在只能跑到30帧左右，离1080p60帧的目标差很远。导师说要从流水线设计上优化，但我不知道该从哪下手。是不是要改成多级流水线并行处理窗口？还是用查找表代替除法？求有经验的大佬指点具体优化思路和代码结构，最好能分享一下时序约束上的坑。
回答 3
你先想清楚一件事：1080p60 意味着每帧大约16.7ms，而暗通道先验里透射率计算通常涉及最小值滤波和除法（或减法后取倒数）。如果你现在30帧时透射率模块占了主要瓶颈，那首先得定位是除法器延迟大，还是窗口遍历导致数据吞吐不够。我建议你先把透射率计算拆成三级流水：第一级做窗口内像素最小值比较（用移位寄存器加比较树，不要用for循环综合），第二级用查找表把除法换成乘法——因为大气光值A在整帧内基本不变，你可以预计算1/A的定点数，然后透射率t(x)=1-暗通道/A就变成了一个乘法和减法，延迟能压到1个时钟周期。第三级做阈值钳位和输出。这样三级之间插寄存器，能跑到150MHz以上，再配合双端口BRAM做行缓冲，1080p60在148.5MHz像素时钟下刚好够用。时序约束上要注意：最小值比较树如果级数太多，跨时钟域时容易产生亚稳态，建议用同步复位和multi-cycle path约束来放宽比较路径。另外，Zynq的PS端可以分担大气光值估计，别把A的计算也放PL里，否则会拖慢流水线。你现在的透射率模块是用的组合逻辑还是纯时序？如果是组合逻辑直接输出，那改成流水线后记得加valid信号做握手，不然下游模块会读到中间值。
透射率计算慢最常见的原因是用了浮点除法或串行求最小值。你把除法换成查找表，大气光值A固定后1/A查表，透射率就变成一个乘法和减法，一个时钟周期出结果。最小值滤波那块用行缓冲+比较树，每来一个像素就更新窗口内的最小值，别再每帧从头扫一遍。这样改完，主频能提到150MHz以上，1080p60的像素时钟148.5MHz就能稳过。还有，别忘了用双端口BRAM做行缓冲，别用分布式RAM，否则布线会炸。你目前透射率计算花了几个时钟周期？
你导师说的没错，核心瓶颈确实在流水线上，但光加流水线级数不够，得先搞清楚除法器占了多少资源。1080p60的像素时钟是148.5MHz，如果透射率计算里用了一个非流水线除法器（比如Xilinx的Divider Generator IP核，Latency设成8-12个周期），那它每收到一个像素就要卡住好几个时钟周期才能出结果，吞吐量直接掉到原来的1/8。所以第一步不是加流水线，而是把除法彻底去掉。常见做法是：大气光值A在整帧内取最大值或固定百分比，你可以在帧头算一次，然后预计算1/A的定点数（比如Q8.8格式，精度够用），之后每个像素的透射率t(x)=1-暗通道/A就变成了一个乘法和减法，一个时钟周期就能出结果。这一步改完，吞吐量瓶颈基本就解了。第二步才是优化最小值滤波的流水线。如果你现在用二维滑动窗口（比如15×15）每来一个新像素就重新算窗口内所有像素的最小值，那每个像素需要225次比较，就算综合出比较树也要好几级逻辑深度，时序容易跑不高。更好的方案是用行缓冲加一维比较树：先把每一行窗口内的最小值用移位寄存器+比较器算出来（比如15个像素的流水线比较，每时钟出一个该行最小值），然后对这15行的结果再做一列比较树，这样每来一个像素只需要做15次比较加一次15选1的比较树，延迟只有几个时钟周期，而且资源可控。时序约束上有个坑：比较树级数多了容易跨时钟域，建议每两级之间插寄存器，并在综合时给这条路径加set_max_delay约束，把逻辑级数压到8级以内。Zynq-7020的资源跑1080p60完全够，关键是把除法换成查找表，以及用行缓冲+比较树代替全窗口遍历。你目前透射率计算那一块用了几个时钟周期？除法器Latency设了多少？
发表回答
登录后可在本页底部提交回答
游