2、项目需求分析：需求文档撰写、性能指标定义、接口协议选择、可行性评估
说实话，很多工程师一上来就急着写代码、搭平台。我见过不少团队，RTL写了三个月，结果发现接口选错了，整个方案要推倒重来。嗯，需求分析这一步，看着像「纸上谈兵」，其实是最省时间的环节。
我个人习惯，拿到一个硬件加速项目，先花一周时间把需求文档写清楚。别小看这个文档，它就是你后面所有工作的「宪法」。今天我们就聊聊，这个阶段到底要做什么。
核心观点：需求分析不是走流程，而是为了回答三个问题——做什么？做到什么程度？能不能做？
2.1 需求文档怎么写？
需求文档不是写作文，是写合同。我一般把它分成三块：
- 项目背景：为什么要做这个加速？现有方案的瓶颈在哪？
- 功能需求：输入是什么？输出是什么？处理流程是怎样的？
- 非功能需求：性能、功耗、面积、成本、开发周期。
举个例子。我之前做过一个视频编解码的加速项目。需求文档里功能需求就写得很细：输入是YUV420格式，分辨率1920x1080，帧率60fps。输出是H.265编码流。处理流程里，运动估计、变换量化、熵编码这些模块谁先谁后，都得写清楚。
我的小技巧：需求文档里最好加一个「不做什么」的列表。比如「本方案不支持4K分辨率」。这能避免后期需求蔓延，你想想看，客户今天加个功能，明天改个参数，项目就失控了。
2.2 性能指标怎么定义？
性能指标说白了就三个：吞吐量、延迟、功耗。但怎么定义，这里面有门道。
吞吐量
吞吐量是单位时间能处理多少数据。我习惯用两种方式描述：
- 峰值吞吐量：理论最大值，比如DDR带宽是25.6GB/s，那峰值就是25.6GB/s。
- 有效吞吐量：实际能跑到的值，要考虑协议开销、仲裁冲突、数据对齐等因素。
我在项目中遇到过，客户说「我要10Gbps的吞吐量」。结果一算，他的数据包最小只有64字节，加上MAC帧头、IP头、TCP头，有效载荷占比不到70%。实际需要的线速是14Gbps以上。你看，不把细节掰开，后面全是坑。
延迟
延迟分两种：
- 处理延迟：数据从进模块到出模块的时间。
- 端到端延迟：从数据源到数据目的地的总时间。
做实时系统时，端到端延迟是关键。我记得有个雷达信号处理的案子，要求端到端延迟小于1微秒。结果我们在DDR读写上就花了800纳秒，留给算法处理的时间只剩200纳秒。嗯，最后只能把中间结果存在BRAM里，硬着头皮优化流水线。
功耗
功耗估算我一般分动态功耗和静态功耗。动态功耗跟翻转率、频率、电压有关。静态功耗跟工艺节点有关。
注意：功耗估算别太乐观。我曾经按50%翻转率算，结果实际跑起来翻转率到了80%，功耗直接超了40%。后来我学乖了，留20%的余量。
2.3 接口协议怎么选？
接口选型，说白了就是看数据量和实时性要求。我整理了一个表格，方便你对比：
| 接口 | 典型带宽 | 延迟 | 适用场景 |
|---|---|---|---|
| AXI4-Stream | 取决于时钟频率和数据位宽 | 几个时钟周期 | 片内高速数据流，比如视频、网络包处理 |
| AXI4-Full | 取决于总线配置 | 几十到几百个时钟周期 | 片内存储器访问，比如DDR控制、寄存器配置 |
| PCIe Gen3 x8 | 约7.88 GB/s | 微秒级 | 板卡与主机通信，比如GPU、FPGA加速卡 |
| DDR4-3200 | 25.6 GB/s | 几十纳秒 | 大容量数据缓存，比如图像帧缓存、神经网络权重 |
我个人习惯，先看数据量。如果数据量小于1MB，用BRAM或者URAM就够了，不需要DDR。如果数据量在1MB到几百MB，DDR是首选。如果超过几百MB，可能要考虑DDR4或者HBM。
再看实时性。AXI-Stream延迟最低，适合流水线处理。PCIe延迟高一些，但适合主机和加速卡之间的批量数据传输。
避坑指南：我曾经选PCIe做视频采集卡，结果发现PCIe的延迟抖动很大，导致视频帧率不稳定。后来改成AXI-Stream + DMA的方式，把数据先缓存到板载DDR，再通过PCIe批量上传，问题就解决了。
2.4 可行性评估怎么做？
可行性评估不是拍脑袋，是算账。我一般从三个维度来评估：
- 资源可行性：FPGA的LUT、FF、BRAM、DSP够不够？我习惯先写一个粗略的RTL估算，比如一个卷积核大概用多少DSP，一个FIFO用多少BRAM。
- 时序可行性：目标频率能不能跑到？关键路径在哪？我一般先用一个简单的模块跑一下综合，看看时序余量。
- 开发周期可行性：团队能力够不够？有没有现成的IP可以用？
举个例子。有个项目要做4K@60fps的视频缩放，用双线性插值。我算了一下：每帧需要处理1920x1080个像素，60fps就是124M像素/秒。如果用Xilinx的HLS，一个像素需要3个时钟周期，那就要372MHz的时钟。嗯，这个频率在Artix-7上跑不到。最后只能改成流水线设计，一个时钟周期处理一个像素，才把频率降下来。
我的经验：可行性评估里最容易忽略的是「数据搬运」的开销。很多方案算处理时间很漂亮，但没算数据从DDR搬到FPGA的时间。你想想看，DDR的带宽是共享的，多个模块同时访问时，实际带宽可能只有理论值的60%。
2.5 本章知识体系
下面这张图，是我自己总结的需求分析流程。你看一眼，心里就有谱了。
这张图把需求分析拆成了四个步骤。你从需求文档开始，一步步往下走，最后输出一份SRS。有了这份文档，后面的RTL设计、验证、调试，都有了依据。
最后说一句：需求分析阶段，多花一天，后面可能省下一周。我见过太多项目，需求没搞清楚就开干，结果做到一半发现方向错了。嗯，磨刀不误砍柴工，这句话在硬件加速项目里尤其适用。
可可精品资料库