嵌入式入门生我分享一个具体的数据流架构，你们可以画个图跟着想。整个系统分三级流水：第一级是双路视频输入，经校正后，左右图各进入一个Census变换模块。这里用滑动窗口，一行像素需要缓存K-1行（K是窗口高度）。用Block RAM实现循环行缓冲，每行存1080个像素（按位宽算好深度）。第二级是代价计算与聚合。代价计算就是左右图census码的汉明距离，直接异或就行。聚合模块是重点，我们采用SGM的多路径聚合，但硬件上实现为：每个路径独立一个处理单元，共享同一个代价输入流。每个单元内部需要一个小缓存来存上一像素的聚合值（就是沿着路径方向的递归），这个用寄存器实现。第三级是视差计算，用WGC在聚合后的代价里找最小值。关键是为了流水，每个阶段处理延迟要匹配，比如Census出来第一个有效像素后，代价聚合就要立刻能算。建议用Vivado HLS先搭个行为模型，再优化流水线。资源评估要早做，别等到后期发现BRAM不够。
从算法近似角度给点思路。Census变换的窗口可以缩小，比如从9x7降到5x5，甚至用非对称的3x7（水平方向长一点，符合双目匹配的特性）。代价聚合那步，SGM（半全局匹配）的路径数不用8条全做，选4条（水平、垂直、两个对角线）效果也还行。精度损失大概2-3%，但硬件资源省一半。还有，视差搜索范围别设太大，根据你的摄像头基线距离和最小测距范围来定，比如只搜64个视差级别，而不是256。存储方面，代价立方体（cost volume）是三维的，别傻傻全存，太占BRAM。可以按视差层流式处理，算完一层聚合代价就传给下一级，中间只缓存聚合后的结果，不存原始代价。FPGA最怕大容量片上存储，一定要让数据流动起来。
我们去年做过类似题目，拿了国一。核心就一句话：把算法彻底流水线化，每个时钟周期都吃进新像素、吐出结果。Census变换那块，别傻傻地等整个窗口，用移位寄存器搭个滑动窗口，进来一个像素就更新一次census码。代价聚合是内存瓶颈，我们用了多级流水：先把几个方向的聚合拆开并行算，每个方向用行缓冲存几行数据，计算单元只读当前行和上一行的聚合结果，这样BRAM访问量能降一个数量级。视差优化简单，赢家通吃（WGC）就行，别上太复杂的，实时性第一。存储架构上，原始图像用Line Buffer存，中间代价用分布式RAM，因为要同时读很多个代价值去比大小。重点优化内存带宽，1080p@60fps数据量很大，计算其实不愁，愁的是数据喂不饱。
