图像处理架构

APSchmidt

这个纯粹随笔，有一些仅仅是demo，所以将debug的一些方式也放入到了这一篇当中。有些架构笔者也仅仅是个人猜想，实际也没使用过，就权当看个热闹

一：设计方面
1：假设图像的信息流存在了A当中，B负责从A当中取到相应的值，要求要快，那么最简单的方式便是提高时钟频率。但是高频率的时钟带来了高功耗。
此时假设B（比如CPU）在处理第一帧图像的时候，我B还能同时发出一个指令，告诉A，说，嘿，你把第二帧的图形发送过来呗。指令和图形处理单元分开，外表看起来就是图像处理单元好像一直都在work，效率自然就高了（不过比如说视频处理，分成了I 帧、P 帧、B 帧，I帧可以独立解码，但是PB不行，需要前后的一些帧信息才能完成解码行为，题外话哈哈）

2：考虑一个算法是否适合硬件来实现（总体的思路）：
比如说某一个算法单元运转时间为a，整个算法单元的运转时间为b，当a远小于b的时候，这时候使用硬件实现的化，会让硬件单元大部分时间处于空闲态，所以这种算法更适合软件实现
再如一个算法，有大量的复杂运算单元，
再如一个算法，本质是串行的，怎么改都没法改成并行架构
具体的算法：

3：使用片外的存储器的时候，比如说现在需要缓存一帧的图像，用了一个ddr作为存放。图像写入ddr----处理器从ddr读出数据流（当然大部分时候是图像写入fifo----fifo转入ddr----ddr读出到fifo，fifo给予处理器），这一个过程需要比较长的时间，等呀等，黄花菜都凉了（注意这里仅仅是图像发送到cpu这段时间的模型，如在算法的内部做一些line buff，frame buff暂时没考虑）。
那咋办。简单粗暴就是用多个的存储器，比如偶数行放入a_ddr,奇数行放入b_ddr，然后并行出来图像数据，外头嵌个打包模块（a_ddr+b_ddr打成一个包），本质是拓展字节位宽，吃进去处理器当中。
通俗解释：一顿饭，一小口一小口吃，要从早上吃到晚上，但是一顿饭，一大口（两小口）一大口，那我只要从早上吃到中午就好了（emm），啥？你说上午时间长于下午时间（不是2倍的关系），那打包模块也需要一定的时间的。


如果要求不是很高，用一些单边沿的存储器即可，用不着ddr了。不过大部分实际项目应该不会用这种方式。
4也可以按照数据使用的频繁程度划分，比如有一些配置数据流，仅仅在开始的时候回进行一次加载，后面不再使用。那么可以将这些配置数据流放在了片外的存储器，常用的数据流放入内部的高速缓存当中。笔者之前有一个项目，面积不够，line buff的存储量为a，ram大小为2的次幂，设为b，b大于a，所以将b-a剩余的存储单元作为"rom"使用，即写出初始化文件而后期不再刷新该存储位置
5如果某一个资源很珍贵，进行共享行为。那么最后独立开来仲裁控制模块。如abcd都拥有对X的使用权（可能是不同的时间段的使用，也可能是X的其中某部分的使用），那么abcd----仲裁机制模块-----X，将所有的control放在了仲裁上，隔离开，只有它有权访问共享资源，这样一旦乱套，debug起来直接找仲裁那个模块即可

二：调试方面（本质上都是额外增加一些行为（电路结构））
1：比如做一个编解码的算法，在做原始的demo的时候，有时候可能视频流的图像有一些是正常能解码出来的，有一些图像偏偏就是会解码失败，比如说一副高中低频分布均匀的图像数据，嘿，完美解码，但是一副高频噪声构造的图像，解码GG。
此时debug起来很头疼。因为视频流处理过程中单凭现象，肉眼来看很难看出问题缘由，即使你使用了一些专业的仪器，比如7000视频解析器（甚至有时候你手头就没有这类仪器，毕竟实在贵），也很难从参数当中立马就知道嘿原来是高频信息导致的错误。
此时可以每一帧图像进行算法处理前进行存储，一旦bug来了，就将对应的bug的图像给抓出来，转换为图像数据，用软件算法或者硬件仿真debug。同理，可以处理后的图像流也可以存储，用于仿真对比。
2：比如增加一些IO口作为debug，当然ASIC上麻烦了些，但是请不要直接input = ouput。比如说ASIC的一些比较重要的sign，电源控制模块，最好还是留点余地，不然流片后出问题真的很想死
3：参考xilinx的DDR提供的example design，可以做一个内部的读写对比模块