海思isp图像处理芯片_详解可编程ISP实现-S32V （1）

Image Signal Processor, 即ISP， 是所有相机成像系统中必不可少的一环。其主要作用是将Image sensor捕获的raw data转化为可供人眼或是后继感知模块识别的图像。这就需要一系列功能相对固定，但实现和效果又大相径庭的ISP算法，其中包括了Black Level Correction, Lens Shading Correction, Debayering, HDR, Tone Mapping, Denoising, AEC(Auto Exposure Control), AWB(Auto White Balancing)等等。除去传感器本身的因素，ISP算法的质量直接决定了相机系统的质量。

既然有了相对固定了算法和流水线，那么如何把这些工作在独特的硬件处理单元中加速从而减小CPU的负载，就是硅工们需要考虑的了。通常分为两种技术路线。针对相对固定的业务场景，本身又包含强大的算法团队支撑，也就是说可以明确自己想要什么算法落在芯片上（又能保证在产品周期内算法的竞争力），通常采用ASIC的设计。这种设计的优势对芯片来说是显而易见的，即最优的PPA，缺点是算法不能改动。采用此类设计方案的厂商包括比如Nvidia, TI和海思等。另一种方案是采用软核的方案，即采用可编程的DSP加速ISP算法。优势就在于其可编程性增加了算法的灵活性，便于OEM提供差异化的算法针对不同业务场景，主要厂商包括高通和NXP等。下面我们就来剖析下S32V中的ISP实现方式

架构上来看这个ISP子系统包含了三个主要部分：

4M的高速缓存用于缓存行处理后的中间数据
12个各自独立的IPUS/IPUV引擎用于算法的处理任务
1个基于ARM M0的Sequencer用于系统间的任务调度

从数据流的角度上看，当有数据流入时Sequencer首先会打开CSI控制器解析数据并传送到SRAM中。数据在SRAM中的存储都是以行存的形式。这么做主要是利用了ISP算法中大多只要邻域数据的特性，采用行存意味着空间有限的SRAM中只需存储即将被处理的行数据（而非整张图片)。

每个IPU引擎在运行前都加载好了需要运行的算法，其功能完全独立于其他与之并行工作的引擎，仅需通过SRAM进行数据上的交互。比如说图片中的IPUS0运行的算法是一个3*3的Gaussian Filter, 那么它对数据最大的依赖为3行。当从CSI中传到SRAM中的数据大于3行之后，sequencer就会通知IPUS0从SRAM中开始读取数据。每一个cycle, IPU会通过内部的Stream DMA读取新的pixel数据，按照用户编程好的Gaussian Filter进行乘累加的运算，最后将结果通过Stream DMA写回SRAM，当然这些操作都是以流水的形式体现的。IPU内部包含一个记录pixel数目的寄存器，当达到每行的pixel数目时，IPU会产生一个line done的信号返还给sequencer. Line done意味着当前行处理完毕并写回到SRAM中，而后继IPU会依赖于前面line done的数目调度pipeline中下一个算法任务，以此往复流水。值得一提的是通常采用double buffering的策略以保证IPU不会因为没有足够数据而处于饿死状态。上面图片中展示了一组纯串行的流水线，实际上流水线的组合完全是软件可配而服务于算法的。

当pipeline中的最后一个引擎完成一行的处理任务时，sequencer会调度高速的DMA将数据以整行为最小粒度搬运回DDR中。就这样直到一帧图像的最后一行被搬运完毕，sequencer会以中断形式上报host(A53)当前帧处理完毕。

从编程的角度来看完成ISP的功能需要两个维度的编程工作：

Kernel层面的函数实现pixel级图像处理功能，通常用来实现单一或者融合的ISP算法，计算过程运行在IPUS/IPUV中。Kernel层面的编程涉及到IPU运算单元具体的架构和指令，我们把它作为单独的一篇文章来介绍
Graph层面用于组合和排列各种算法实现完整的ISP pipeline. 这部分工作更像是对处理流程的描述，然后通Seqeuncer完成IPU的任务调度和buffer的状态管理。Sequence的代码由厂商作为firmware提供，并向用户开放特定API用于如IPU寄存器读写请求等工作。

比如上图就是对一个简单处理流程的描述。首先由kernel1完成G和RB图层的分离，中间结果以行存的形式缓存在Buffer1和Buffer3中。Buffer1的数据经过Kernel2的再处理后缓存到Buffer2中。最后再由Kernel3完成对Buffer2和Buffer3中数据的处理。这部分数据结构会被作为一部分编译到Sequencer的firmware当中，因此无法在runtime动态更改graph的设置。由这张图可以想象，如何保证数据间的同步与各级间的依赖关系，管理各级buffer之间的状态都会是Sequencer固件设计的难点。尤其当graph变得十分复杂时，大量的因此而生的中断响应可能称为系统性能的瓶颈。

聊过了这款ISP的整体架构和编程模型后，我们从用户角度看下应用端的编译方法。还是直接上图。

在Device侧， IPU中运行的算子会通过IPU专用的编译器生成相应的binary, 这部分binary会在runtime通过firmware提供的API加载到sequencer的kernel memory中。前面介绍的ISP graph会作为数据结构的一部分被编译到firmware中，而firmware又会以静态库的形式被主程序调用。当然，在OS环境下，sequencer和ISP pipeline中的众多其他设备如CSI, FastDMA等都会以device driver的形式注册在OS下。主程序会以各个device在userspace中的API完成sequencer加载firmware并执行graph等动作。

这篇文章真的十分粗粒度的介绍了S32V中ISP的整体框架和编程模型。虽然只是庞大SOC下的一个小小的子系统，但又涵盖了从硬件到软件，从编译器到图形编程，从嵌入式固件到操作系统等多个领域，有种麻雀虽小五脏俱全的感觉, 感叹定义这款加速器IP的架构师深厚功底。

之后有机会的话会具体分析下IPU模块的架构以及其专用的指令
————————————————
版权声明：本文为CSDN博主「SoulframEE」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_34397537/article/details/112365940