3. 可配置DMA需求分析
在动手写RTL之前，需求分析决定了微架构的“天花板”。可配置DMA控制器的核心价值在于用一套RTL覆盖多种应用场景，而配置维度一旦定义不清，后续就会出现参数耦合、面积浪费或功能缺失。本节围绕六个关键维度展开：通道数、数据宽度、地址对齐、传输模式、优先级与仲裁策略，并给出可落地的参数化建议。
一、核心原理：配置维度如何映射到硬件资源
每个配置维度都对应一组硬件资源。通道数决定描述符存储、状态机和仲裁器的实例数量；数据宽度决定数据通路的位宽、FIFO深度和总线掩码逻辑；地址对齐决定是否需要在数据通路上插入移位/拼接逻辑；传输模式决定地址生成器的复杂度；优先级与仲裁策略决定仲裁器的面积和时序路径。
关键结论：配置不是“越多越好”，而是“正交且可裁剪”。通道数、数据宽度、传输模式应作为编译期参数；优先级策略可作为运行期可配置项；地址对齐能力则建议做成“按通道可选”，避免全局强制对齐带来的面积开销。
下图展示了六个配置维度与RTL模块之间的映射关系，便于在需求评审时快速定位影响面。
二、方法流程：从场景到参数表的推导步骤
- 场景枚举：列出所有目标应用，例如音频播放、摄像头采集、网络包搬运、存储器间大块拷贝。
- 带宽反推：用“数据量 / 时间窗口”计算峰值带宽，再除以总线频率得到所需数据宽度。
- 通道数估算：统计可并发发起传输的独立数据流数量，并预留1~2个通道用于调试或未来扩展。
- 对齐能力决策：判断源地址和目的地址是否可能非对齐，决定是否支持字节级移位。
- 模式裁剪：确认是否需要循环缓冲、链表描述符、二维块传输等高级模式。
- 仲裁策略选择：根据实时性要求选择固定优先级、轮询或加权轮询。
建议把上述推导结果固化为一张“配置参数表”，作为RTL参数和验证用例的共同输入，避免设计与验证对配置理解不一致。
三、案例/场景：三类典型配置对比
下表给出三种典型场景下的配置组合，便于理解参数之间的权衡关系。
| 配置项 | 音频播放 | 摄像头采集 | 网络包搬运 |
|---|---|---|---|
| 通道数 | 2 | 4 | 8 |
| 数据宽度 | 32 bit | 64 bit | 128 bit |
| 地址对齐 | 4字节对齐 | 支持非对齐 | 16字节对齐 |
| 传输模式 | 循环缓冲 | 二维块 | 链表描述符 |
| 优先级 | 固定高 | 中等 | 轮询 |
| 仲裁策略 | 固定优先级 | 加权轮询 | 轮询 |
从表中可以看出，音频场景对实时性要求高但数据量小，适合固定优先级；网络场景通道多、包长可变，轮询能保证公平性；摄像头场景介于两者之间，加权轮询可以兼顾实时通道和普通通道。
四、误区与复盘：常见需求分析陷阱
误区一：通道数越多越好。通道数增加会线性增加仲裁器和描述符存储面积，且时序收敛难度上升。建议按“最大并发流 + 1”确定。
误区二：全局强制地址对齐。若所有通道都要求对齐，非对齐场景需要CPU介入搬运，反而降低系统效率。建议按通道配置对齐能力。
误区三：优先级策略写死在RTL中。不同场景对公平性和实时性的需求不同，建议把优先级和仲裁策略做成运行期可配置寄存器。
复盘时可以用以下清单逐项检查需求是否闭合：
- 每个通道的峰值带宽是否已计算，并留有余量？
- 数据宽度是否与总线位宽匹配，是否需要位宽转换？
- 非对齐传输是否已明确支持范围（字节/半字/字）？
- 传输模式是否覆盖循环、链表、二维块等实际需求？
- 优先级是否支持动态调整，仲裁是否会导致饥饿？
- 配置寄存器地址映射是否已定义，复位默认值是否安全？
// 建议的参数化定义示例
parameter CH_NUM = 4; // 通道数
parameter DATA_W = 64; // 数据宽度
parameter ADDR_W = 32; // 地址宽度
parameter ALIGN_EN = 1; // 是否支持非对齐
parameter MODE_LINK = 1; // 是否支持链表模式
parameter ARB_MODE = 2'b01; // 0:固定优先级 1:轮询 2:加权轮询
需求分析的输出应当是一份可追溯的配置矩阵：每个配置项都能对应到具体场景、RTL参数和验证用例。只有这样，后续的微架构设计才不会在“到底支持不支持”的问题上反复摇摆。