2026年FPGA校招，海思面试手撕Verilog实现AXI4-Stream实时视频去雾，暗通道先验中透射率t(x)怎么用查找表加速？求具体推导和资源对比

面试官给这个提示，其实是想看你有没有工程上的资源意识——暗通道先验里透射率t(x)=1 – ω min(min(I_c / A_c))，这里除法是拿每个通道的像素值除以大气光值，结果在0.1到1.0之间（防止天空过曝一般下限设0.1）。直接用除法器，一个除法就要占几十个LUT和至少一个DSP，而且流水线延迟长，视频去雾这种实时流数据根本扛不住。查找表的思路就是把t(x)的可能输入范围映射成地址，提前算好结果存进BRAM。比如你的输入是像素值I_c和大气光值A_c的比值，I_c是8bit（0-255），A_c是定值，那实际比值范围就是0-255/A_c，但t(x)只关心0.1-1.0，所以你可以把A_c归一化后，把0-255分成256个步长，每个步长对应一个t(x)值，用8bit定点数表示（比如Q4.4格式，精度1/16）。这样BRAM深度256、宽度8bit就够了，一个块RAM能搞定。资源对比很直观：一个32位除法器在7系列上大概要150个LUT加1个DSP，延迟3-4个周期；查找表方案只要一个BRAM（约0.5个块RAM），LUT只用于地址译码（不到20个），延迟1-2个周期。省了DSP，LUT省80%以上，代价是精度损失——步长0.0039（1/256）对去雾效果几乎看不出区别。但要注意，你的大气光值A_c如果在帧间变化，查找表得重新加载，面试时可以说用双口BRAM在线更新，或者把A_c固定为整帧最大值来简化。你面试时最好画个地址映射图，说清楚输入像素值怎么左移右移变成地址，再附个仿真波形示意读使能和有效数据对齐。你目前是在准备手撕代码阶段还是已经拿到面试了？追问一下：你用的平台是Vivado还是Quartus，因为BRAM原语例化方式不同。

查找表加速的核心是把除法结果预存，用输入像素值做地址直接读。比如t(x) = (I / A) 归一化到0.1-1.0，I是8bit，A是常数，那地址就是I，深度256，宽度8bit存t(x)的定点值。对比除法：查找表用1个BRAM加几十个LUT，除法器要上百LUT加DSP，延迟少1-2个周期。步长按256级分，精度够用。面试时重点说清楚地址怎么算、BRAM例化参数，再提一嘴资源节省比例就行。

查表就是拿像素值当地址，BRAM里存算好的t(x)，256深度8bit宽，省DSP省LUT，延迟多一拍但能流水。面试官其实就想听你懂不懂用BRAM换逻辑。别纠结步长，直接说256级够用。

其实面试官问这个，重点不是让你现场推一个完美的查找表，而是看你有没有「用BRAM换DSP」的意识。透射率t(x)范围0.1到1.0，你把它量化成256级，深度256、位宽8bit的BRAM就够了。地址直接用像素值（0-255），但注意像素值要除以大气光A_c才能得到比值，而A_c是个常数，所以你可以提前把t(x)=1 – ω min(I_c/A_c)算好，把I_c从0到255每个值对应的t(x)存进去。这样查表时输入像素值，输出就是t(x)的定点数（比如Q4.4）。对比直接除法：一个除法器通常占40-60个LUT加1个DSP，查找表只要1个BRAM加几十个LUT做地址译码和流水线，资源能省一半以上，代价是多1-2拍延迟。但要注意，如果大气光A_c是动态更新的（比如每帧重新算），那这套查找表就得每帧重新生成，或者改成双BRAM乒乓操作。面试时最好主动提这个风险，说明你考虑过实际工程场景。另外，步长不一定要256级，如果精度要求不高，128级也能用，BRAM宽度可以降到7bit。你目前是卡在A_c每帧变化的情况吗？还是A_c固定？这个会影响方案选择。
追问：你们面试时允许用IP核例化BRAM，还是必须手写RTL？这个决定了写法差异。

顺着查找表往下说，其实推导过程很简单，但面试官更想听你讲「为什么这样设参数」。透射率t(x) = 1 – ω min_c ( I_c(x) / A_c )，其中c是RGB三个通道。假设A_c是常数（比如大气光值取整帧最亮像素的0.1%分位点，通常固定），那么对于每个像素值I_c（0-255），I_c/A_c的范围是0到255/A_c。但t(x)被限制在0.1到1.0之间，所以实际输入范围可能只用到0-200左右。你不需要把0-255全映射，可以按实际输入范围缩小深度，比如只存0-200，深度201，宽度8bit，这样BRAM只用201个地址，省一点资源。但工程上一般直接取256，因为BRAM深度本来就是2的幂次，浪费几个地址无所谓。步长就是1，因为像素值本身是整数，你按1步长把每个整数对应的t(x)算出来存好，精度就是1/256 ≈ 0.39%，对去雾效果来说足够。资源对比：一个32位浮点除法器在7系列上大概占80个LUT加2个DSP，延迟5-6拍；查找表方案用1个18K BRAM（深度512可配置成256×8）加20-30个LUT做地址对齐和流水线，延迟3-4拍。LUT节省约60%，DSP省100%，代价是BRAM消耗增加。面试时你还可以补充：如果A_c是动态的，可以用双BRAM乒乓操作，或者改用CORDIC迭代除法（但延迟更大）。另外，Verilog实现时注意BRAM读使能信号，输出要打一拍寄存器避免时序问题。你手撕代码时，是把大气光A_c作为参数传入模块，还是直接写死在代码里？如果是参数化设计，查找表就得用generate块动态例化，这个你练过吗？

查表加速就是拿像素值当地址，提前算好t(x)存BRAM里。深度256宽度8bit，省DSP省LUT，延迟多一拍。步长按1分，精度够用。面试官就想听你懂不懂用BRAM换逻辑，别想复杂了。

查表法的核心就一句话：拿像素值当地址，把除法结果提前算好存进BRAM。t(x)范围0.1到1.0，量化成256级，深度256位宽8bit够用。地址就是像素值0-255，输出是定点数比如Q4.4格式，延迟多两拍但省一个除法器。面试官其实就想听你讲清楚地址映射和资源权衡，别往推公式上绕，直接说BRAM换DSP，LUT能省一半以上就行。你大气光值A_c是每帧更新还是固定值？

直接除法确实费资源，一个除法器通常占40-60个LUT加一个DSP，流水线还长。换成查找表只要一个BRAM加几十个LUT做地址译码，面积能压到原来的三分之一左右。但有个坑：大气光值A_c如果是动态更新的，那查找表内容就得每帧重新计算写入，这时候要考虑双端口BRAM或者用分布式RAM做重配置逻辑。步长按1分没问题，因为像素值是整数，256级对应0-255，t(x)精度够。你如果担心精度不够，可以把位宽扩到10bit，深度不变，资源增加不多。面试时主动提一句A_c更新策略怎么处理查找表，能证明你考虑过工程落地细节。

说实话海思面试问这个，重点不是让你背推导，而是看你对FPGA资源交换的直觉。透射率t(x)=1-ωmin(I_c/A_c)，这里I_c是8bit像素值，A_c是大气光常数，你实际要算的是每个像素值对应的除法结果。直接写除法器，一个除法IP核在7系列上至少占1个DSP48E1加60个LUT，延迟大概8个周期；你换成查找表，BRAM用单端口，深度256宽度8bit，地址用像素值，输出是预先算好的t(x)定点数（比如Q4.4，范围0.1-1.0映射到16-255），综合出来只占0.5个BRAM和20个LUT左右，延迟多2个周期但可以流水线插入抵消。关键点是A_c必须固定——如果A_c每帧变化，你就要在帧消隐期重写BRAM内容，这需要额外控制逻辑或者换成分布式RAM。面试官如果追问步长怎么选，你可以说按256级步长1是常规做法，但实际输入范围可能只用到0-200（因为t(x)下限0.1），可以缩小深度到200省一点资源，不过工程上为了对齐地址一般不这么干。仿真波形你查表出来的t(x)和除法器算出来的值对比，误差在±1LSB以内，时序没问题。你目前是在练单帧的还是准备做实时流处理？

面试官其实就想看你有没有资源交换的意识：把除法结果提前算好塞进BRAM，地址拿像素值，256深度8位宽，比除法器省一半多LUT和DSP，代价就多一两拍延迟。步长按1分就行，别纠结精度，他更关心你愿不愿用BRAM换逻辑。你的大气光A_c是每帧重算还是固定值？