第一章：课程导论与噪声模型——为什么需要硬件去噪？

各位同学好，我是老李。做数字IC设计十几年了，今天咱们聊聊去噪算法硬件化这件事。

先问个问题：为什么非要用硬件去噪？软件跑跑不香吗？

嗯，我刚开始做图像处理项目时也这么想。直到有一次，一个实时视频处理项目，要求每帧处理时间不超过16ms。软件算法跑在ARM上，光去噪这一步就占了8ms，剩下的任务根本排不过来。那次之后，我彻底明白了——实时性是硬伤。

1.1 为什么需要硬件去噪？

说白了，三个字：快、省、稳。

• 快：硬件流水线处理，一帧数据进来，几个时钟周期就出结果。软件要读内存、算指令、写回，慢一个数量级。
• 省：专用硬件比通用处理器省电得多。我做过一个对比，同样的中值滤波算法，硬件功耗只有DSP实现的1/10。
• 稳：硬件延迟确定，不会像软件那样被中断、调度影响。这在自动驾驶、医疗影像里是刚需。

你想想看，一个摄像头每秒输出60帧1080p图像，每帧200万个像素。软件要实时处理，CPU得跑多高的频率？散热怎么办？

1.2 常见噪声模型——你得知道敌人长什么样

做去噪之前，先搞清楚噪声从哪来。我习惯把噪声分成三类：

噪声类型	来源	数学描述	硬件处理难点
高斯噪声	传感器热噪声、放大器噪声	概率密度服从正态分布	需要统计运算，资源消耗大
椒盐噪声	传输错误、存储单元损坏	随机出现黑白像素点	需要排序或比较，延迟敏感
泊松噪声	光子计数统计特性（低光照）	信号方差等于均值	非线性变换，硬件实现复杂

1.2.1 高斯噪声

这是最常见的噪声。每个像素叠加一个随机值，这个值服从高斯分布：

P(x) = (1 / (σ * √(2π))) * exp(-(x - μ)² / (2σ²))

其中μ是均值（通常为0），σ是标准差（控制噪声强度）。

我在项目中遇到过一个问题：传感器温度升高，σ从10涨到30，画面直接没法看。硬件去噪必须能自适应调整滤波强度。

1.2.2 椒盐噪声

椒盐噪声就是随机出现的白点（盐）和黑点（椒）。数学上很简单：

I'(x,y) = 
    - 0（黑点），概率 p/2
    - 255（白点），概率 p/2
    - I(x,y)（原值），概率 1-p

p是噪声密度。比如p=0.05，意味着5%的像素被污染。

处理椒盐噪声，中值滤波是经典方案。但硬件实现中值滤波有个坑——排序。3x3窗口要排9个数，5x5要排25个数。排序网络怎么设计，直接影响面积和时序。

1.2.3 泊松噪声

这个稍微复杂点。在低光照条件下，光子到达传感器是随机过程，服从泊松分布：

P(k) = (λ^k * e^(-λ)) / k!

λ是平均光子数。注意：泊松噪声的方差等于均值。也就是说，信号越强，噪声越大。这和高斯噪声完全不同。

处理泊松噪声，常用Anscombe变换把它变成高斯噪声，再用高斯去噪算法处理。但变换涉及开方运算，硬件实现要小心。

1.3 噪声模型与硬件架构的关系

搞清楚了噪声模型，才能设计硬件架构。我画了一张图，帮你理清思路：

从这张图你能看到：不同的噪声类型，对应不同的硬件方案。选错了，要么效果差，要么资源浪费。

1.4 硬件去噪的挑战

说了这么多好处，也得泼点冷水。硬件去噪不是万能的：

1. 面积与性能的权衡：滤波窗口越大，效果越好，但面积和功耗也越大。3x3和5x5的排序网络，面积差4倍。
2. 数据精度：浮点运算在硬件里太贵，通常用定点。但定点精度不够，去噪效果会打折扣。
3. 实时性要求：1080p@60fps，每个像素只有约15ns的处理时间。流水线深度要精心设计。
4. 多噪声混合：实际场景往往是高斯+椒盐混合。单一算法搞不定，需要多级流水线。

1.5 本章小结

这一章我们聊了：

• 硬件去噪为什么必要——实时性、低功耗、确定性延迟
• 三种常见噪声模型——高斯、椒盐、泊松，以及它们的数学描述
• 噪声模型如何影响硬件架构选择
• 硬件去噪面临的挑战

记住一句话：不懂噪声模型，就别谈硬件架构。后面的章节，我们会一步步深入，从算法到RTL，把每个细节讲透。