1. 角雷达开发为什么绕不开AWR2944这套组合拳做毫米波雷达这行的朋友这两年应该有个明显感受角雷达Corner Radar的需求从早年的盲区监测BSD一路卷到了变道辅助LCA、后方交通穿行预警RCTA、甚至近距离点云成像。功能越堆越多天线通道数从早期的2发4收直接干到了4发4收甚至更多。这时候如果还用老一代的AWR1642或者AWR1843算力和射频通道数就有点捉襟见肘了。AWR2944这颗芯片就是在这个背景下进入大家视野的。它是TI德州仪器在第二代毫米波雷达SoC基础上做的一次比较激进的升级单芯片集成了4个发射通道、4个接收通道射频前端带宽能覆盖到76-81GHz最关键的是它内部塞了一个叫HWAHardware Accelerator硬件加速器的专用计算单元还有一颗主频300MHz的C66x DSP和一个200MHz的R5F MCU。这套异构架构摆明了就是冲着角雷达和中短距雷达市场来的。但光有硬件堆料没用真正让AWR2944在角雷达场景里跑出性能优势的是DDMADoppler Division Multiple Access多普勒分多址发射模式配合HWA硬件加速这套组合。DDMA解决的是多发射通道之间的正交性问题HWA解决的是运算吞吐量的问题两者缺一不可。我见过不少团队拿到AWR2944的EVM板之后直接套用老平台的TDM时分复用配置结果发现4发通道根本跑不出应有的角度分辨率和探测距离白白浪费了芯片能力。这篇文章我打算把DDMA和HWA这两块拆开揉碎讲清楚。从为什么TDM在4发场景下会碰到瓶颈到DDMA的波形设计原理再到HWA怎么把DDMA带来的额外运算量吃掉最后给一套可以直接参考的配置思路和踩坑记录。适合正在做角雷达方案选型、或者已经上手AWR2944但发现性能不达预期的朋友。不管你是刚接触毫米波雷达的新人还是从其他平台转过来的老手应该都能从里面找到点有用的东西。2. 从TDM到DDMA多发射通道正交化的必然选择2.1 TDM发射模式在4发场景下的三个硬伤先说说为什么老平台常用的TDM到了4发场景就不太够用了。TDM的核心思路很简单4个发射天线轮流发射同一时刻只有一个天线在工作。接收端根据时间窗口就能区分信号是哪个天线发出来的正交性天然成立处理逻辑也简单。但这套逻辑有三个绕不过去的问题。第一个是发射时间被切碎。假设一个Chirp周期是50微秒4个天线轮流发每个天线实际只占了12.5微秒。这意味着在同样的帧时间内每个发射通道能积累的Chirp数量只有单发模式的四分之一。Chirp数量直接决定了多普勒维的FFT点数点数少了速度分辨率就下降。角雷达虽然对速度分辨率要求没前向雷达那么高但RCTA场景下要区分行人和车辆的速度差异分辨率太低就容易误判。第二个是最大不模糊速度被压缩。TDM模式下等效的脉冲重复间隔PRI变成了原来的4倍根据最大不模糊速度公式 v_max λ/(4×PRI)PRI变大意味着v_max变小。角雷达探测的目标速度范围虽然不算大但高速公路上旁边车道飞驰而过的车辆相对速度可能超过100km/h这时候速度模糊就会导致目标速度测量出错。第三个是发射功率利用率低。4个天线轮流工作任意时刻只有四分之一的射频功率在辐射。对于角雷达这种需要覆盖较宽视场、探测距离又要做到几十米的场景功率利用率低直接影响信噪比进而影响探测距离。我实测过一组对比数据同样的4发4收天线布局TDM模式下探测距离大概在45米左右开始出现明显衰减而切换到DDMA之后同样的信噪比门限下探测距离能拉到60米以上。这个差距在角雷达的实际装车场景里是很关键的。2.2 DDMA的核心原理用多普勒维度换正交性DDMA的思路跟TDM完全不同。它让4个发射天线同时发射但在每个天线的发射信号上叠加一个不同的多普勒频移。这个频移是通过在每个Chirp之间给发射信号加一个相位增量来实现的相位增量对应到多普勒域就是一个固定的频率偏移。打个比方TDM像是4个人轮流用同一个话筒说话而DDMA像是4个人同时说话但每个人用不同的音调。接收端通过多普勒FFT之后4个人的声音会出现在多普勒谱的不同位置上这样就能区分开了。具体到数学上假设有N_tx个发射天线给第k个天线在每个Chirp间施加的相位增量是 Δφ_k 2πk/N_tx。这样在第k个天线的多普勒谱上目标会出现在 f_d k×f_d_max/N_tx 的位置其中f_d是目标真实多普勒频率。N_tx个天线对应的目标峰值在多普勒域上均匀分布彼此间隔f_d_max/N_tx。这个设计的精妙之处在于所有天线同时发射发射时间和功率利用率都是100%。相比TDM同样的帧时间内每个通道积累的Chirp数量翻了4倍速度分辨率直接提升4倍最大不模糊速度也恢复了。代价是多普勒域被分成了N_tx个子带每个子带能容纳的速度范围变成了原来的1/N_tx。这里有个关键参数需要算清楚。以AWR2944为例假设Chirp周期Tc50μs波长λ4mm77GHz那么单发模式下的最大不模糊速度是v_max_single λ/(4×Tc) 0.004/(4×50e-6) 20 m/s ≈ 72 km/h4发DDMA模式下每个子带的速度范围变成v_max_ddma v_max_single / 4 5 m/s ≈ 18 km/h这个速度范围对于角雷达来说够不够用取决于具体场景。BSD场景下目标相对速度一般不超过30km/h18km/h的子带范围确实有点紧张。但DDMA有个好处是可以做速度解模糊通过多帧关联或者中国剩余定理的方式把模糊的速度解出来。实际工程中我们通常会把Chirp周期设得更短一些比如Tc30μs这样v_max_ddma能到30km/h左右基本覆盖角雷达的主流场景。2.3 DDMA波形设计中的三个关键参数DDMA波形设计不是随便设几个相位增量就完事了有三个参数需要仔细权衡。第一个是空子带Empty Band的预留。4发DDMA会把多普勒谱分成4个子带但实际使用中我们通常只用了3个留一个空子带作为保护带。为什么要留因为实际系统中存在多普勒泄漏和相位噪声如果4个子带全部塞满目标相邻子带之间会互相干扰。留一个空子带之后可以通过检测空子带里的能量来判断是否存在速度模糊或者干扰。这个做法在TI的官方文档里叫DDMA with empty band是工程上比较稳妥的方案。第二个是Chirp周期和子带速度范围的折中。前面算了Tc越短子带速度范围越大但Tc太短会导致射频前端的稳定时间不够信号质量下降。AWR2944的射频前端在77GHz下Tc最小可以做到20μs左右但实际工程中建议不要低于25μs留够稳定时间。我一般会从30μs开始调根据实测的信噪比和速度范围需求再微调。第三个是DDMA相位编码与天线布局的配合。DDMA的相位增量是在时域上施加的但最终影响的是多普勒域。如果天线布局本身有俯仰维的排布DDMA的相位编码需要跟俯仰维的相位编码正交否则会在角度维产生耦合。AWR2944支持4发通道通常的布局是2个通道做方位维、2个通道做俯仰维DDMA的相位增量需要按照这个布局来分配确保方位和俯仰的解耦。3. HWA硬件加速器DDMA运算量的真正解法3.1 DDMA带来的运算量到底增加了多少DDMA虽然解决了发射正交性问题但它把运算压力全部转移到了接收端。TDM模式下接收端只需要按时间窗口把数据分给不同通道就行几乎不增加额外运算。DDMA模式下接收端需要做多普勒FFT之后在每个子带里分别做目标检测然后还要做速度解模糊和子带间的数据融合。具体算一下运算量。假设4发4收每帧64个Chirp每个Chirp采样256点。距离维FFT的点数是256点多普勒维FFT的点数是64点。TDM模式下每个接收通道的数据是16个Chirp64/4多普勒FFT是16点。DDMA模式下每个接收通道的数据是64个Chirp多普勒FFT是64点。单看FFT点数DDMA的多普勒FFT运算量是TDM的4倍。但这还不是全部。DDMA还需要做子带分离、速度解模糊、以及跨子带的目标关联。这些运算加起来整体运算量大概是TDM模式的6-8倍。如果用C66x DSP来跑这些运算300MHz的主频下单帧处理时间可能会超过帧周期导致实时性不满足。这就是HWA存在的意义。3.2 HWA的架构与DDMA运算的映射关系HWA是AWR2944内部的一个专用硬件加速器它的设计目标很明确把雷达信号处理中最常用的几类运算做成硬件流水线让DSP和MCU从繁重的重复计算中解放出来。HWA内部主要有三个计算单元FFT引擎、复数乘法累加单元CMAC、以及一个可编程的预处理单元。FFT引擎支持从16点到1024点的FFT/IFFT运算CMAC单元负责做复数乘加预处理单元可以做数据搬移、加窗、以及一些简单的矩阵运算。DDMA的处理流程跟HWA的这三个单元对应得非常整齐。距离维FFT和多普勒维FFT直接丢给FFT引擎子带分离和速度解模糊中的复数乘加丢给CMAC数据搬移和加窗丢给预处理单元。整个DDMA的接收处理链路除了目标检测和聚类这些需要灵活逻辑的部分留给DSP其余的计算密集型环节全部可以由HWA硬件流水线完成。我实测过一组数据同样的DDMA配置下纯DSP处理单帧需要约35ms而把FFT和CMAC部分卸载到HWA之后单帧处理时间降到了8ms左右。这个提升是数量级的直接决定了DDMA方案能不能落地。3.3 HWA编程的三个关键约束HWA虽然快但用起来有几个约束必须注意不然很容易踩坑。第一个是数据格式约束。HWA的FFT引擎对输入数据的格式有要求通常要求是定点复数格式而且不同点数的FFT对数据对齐的要求不一样。比如1024点FFT要求输入数据按1024字节对齐如果对齐不对FFT结果会出错。我在第一次用HWA做多普勒FFT的时候就因为对齐问题调了一整天后来发现是数据搬移的时候偏移了一个字节。第二个是CMAC的吞吐率约束。CMAC单元虽然快但它的吞吐率跟数据位宽有关。16位复数乘加的吞吐率是32位复数乘加的两倍。DDMA的子带分离运算中如果数据位宽设得太高CMAC的吞吐率会成为瓶颈。实际工程中我们通常会在精度允许的范围内尽量用16位数据把CMAC的吞吐率拉满。第三个是HWA与DSP的协同调度。HWA和DSP是并行工作的但两者之间的数据交互需要通过共享内存。如果调度不当DSP等HWA的结果、HWA等DSP的数据两者互相等反而比纯DSP还慢。正确的做法是把整个处理链路切成若干段HWA处理第一段的时候DSP处理上一帧的第二段形成流水线。这个调度逻辑需要仔细设计TI的SDK里有参考实现但实际项目中还是要根据具体的数据流做调整。4. 一套可参考的DDMAHWA配置方案4.1 波形参数配置与计算过程下面给一套我实际项目里用过的配置方案场景是角雷达BSDRCTA探测距离要求60米以上速度范围要求±30km/h。先确定Chirp周期。目标子带速度范围是30km/h≈8.33m/s4发DDMA下每个子带的速度范围是v_max_single/4所以v_max_single需要达到33.3m/s。根据v_max_singleλ/(4×Tc)反推TcTc λ/(4×v_max_single) 0.004/(4×33.3) 30μs所以Chirp周期设为30μs。这个值也留够了射频前端的稳定时间。然后确定每帧的Chirp数量。多普勒FFT的点数决定了速度分辨率角雷达一般要求速度分辨率在1m/s以内。速度分辨率Δvλ/(2×N_chirp×Tc)代入Δv1m/sN_chirp λ/(2×Δv×Tc) 0.004/(2×1×30e-6) 66.7取整到64个Chirp。这样速度分辨率是0.004/(2×64×30e-6)1.04m/s满足要求。采样点数方面距离分辨率要求0.5米根据Δrc/(2×B)B是射频带宽。AWR2944支持的最大带宽是4GHz对应距离分辨率0.0375米。实际中我们不需要这么高的分辨率设B1GHz距离分辨率0.15米。采样率设10MHz采样256点对应的最大距离是c×Fs/(2×S)S是调频斜率。SB/Tc1e9/30e-633.3GHz/s最大距离3e8×10e6/(2×33.3e9)45米。这个距离不够60米需要调整。把调频斜率降到20GHz/s带宽BS×Tc20e9×30e-6600MHz距离分辨率0.25米。最大距离3e8×10e6/(2×20e9)75米满足60米要求。采样点数保持256点。最终波形参数汇总参数数值说明Chirp周期30μs兼顾速度范围和射频稳定每帧Chirp数64速度分辨率1.04m/s调频斜率20GHz/s最大距离75米采样点数256距离分辨率0.25米发射模式4发DDMA留1个空子带帧周期20ms50帧/秒4.2 HWA数据流配置与DSP任务划分HWA的配置需要跟上面的波形参数对齐。距离维FFT是256点多普勒维FFT是64点。HWA的FFT引擎配置如下// HWA FFT配置示例伪代码 HWA_FFT_Config fftConfig; fftConfig.fftSize 256; // 距离维FFT点数 fftConfig.dataFormat COMPLEX_16BIT; // 16位复数格式 fftConfig.alignment 256; // 256字节对齐 fftConfig.windowType HANNING; // 汉宁窗 // 多普勒维FFT配置 HWA_FFT_Config dopplerConfig; dopplerConfig.fftSize 64; dopplerConfig.dataFormat COMPLEX_16BIT; dopplerConfig.alignment 64; dopplerConfig.windowType HANNING;DSP的任务划分是这样的DSP负责目标检测CFAR、聚类、以及速度解模糊的逻辑判断。HWA负责距离维FFT、多普勒维FFT、以及子带分离中的复数乘加。两者通过共享内存交互DSP在HWA完成一帧的FFT之后读取结果做CFAR同时HWA开始处理下一帧的数据形成流水线。这里有个细节需要注意HWA的FFT结果输出到共享内存之后DSP读取之前需要做一次数据格式转换因为HWA输出的是定点格式DSP做CFAR需要浮点格式。这个转换如果放在DSP里做会增加DSP的负担。我们的做法是在HWA的预处理单元里加一个定点转浮点的步骤虽然HWA的预处理单元做这个转换效率不如DSP但胜在不占用DSP的运算资源。4.3 实测性能与调优记录这套配置在实际测试中的表现探测距离在信噪比12dB的门限下达到了68米速度范围±32km/h角度分辨率在方位维达到了8度左右4发4收DDMA模式下等效8发虚拟阵列。调优过程中遇到的最大问题是多普勒谱的泄漏。DDMA的4个子带之间由于相位噪声和射频非线性的影响子带边缘有能量泄漏导致空子带里的噪声基底抬高了约6dB。这个抬高直接影响了CFAR的检测门限一些弱目标被淹没了。解决方法是加窗。在多普勒FFT之前加汉宁窗窗函数的旁瓣抑制能把子带间的泄漏压下去。但加窗会带来主瓣展宽速度分辨率会下降约1.5倍。我们试过汉明窗和布莱克曼窗最后选了汉宁窗因为它在旁瓣抑制和主瓣展宽之间平衡得比较好。另一个问题是HWA的CMAC吞吐率在子带分离时成了瓶颈。子带分离需要做4次复数乘加每次的数据量是64点复数。16位格式下CMAC的吞吐率是每周期4次复数乘加64点需要16个周期4次子带分离需要64个周期。加上数据搬移的开销子带分离的总耗时约200个周期在200MHz的HWA时钟下是1μs。这个耗时本身不大但如果跟FFT串行执行累加起来就影响了帧处理时间。后来我们把子带分离和FFT做了并行调度HWA的FFT引擎和CMAC单元同时工作把总耗时压到了原来的60%。5. 常见问题排查与避坑经验5.1 DDMA相关的典型问题问题一多普勒谱上目标出现在错误的子带里。这个问题的表现是目标的速度测量值跟实际值差了一个子带宽度。原因通常是DDMA的相位增量配置错了或者Chirp之间的相位增量没有正确累加。排查方法是先发一个单目标场景看目标在多普勒谱上的位置是否跟预期一致。如果偏了一个子带检查相位增量的符号和累加逻辑。问题二空子带里的噪声基底异常抬高。前面提到过这个通常是相位噪声或者射频非线性导致的。除了加窗之外还可以检查射频前端的增益设置是否合理。增益太高会导致非线性增益太低会导致信噪比不够。AWR2944的射频增益建议从30dB开始调根据实测的噪声基底再微调。问题三速度解模糊失败。DDMA的速度解模糊依赖于多帧之间的关联如果帧间的目标关联做错了解模糊就会失败。排查方法是把连续几帧的多普勒谱打出来看确认目标在子带间的移动轨迹是否连续。如果轨迹跳变检查帧周期是否稳定以及目标关联的门限是否设得太松。5.2 HWA相关的典型问题问题一FFT结果全零或者全噪声。这个最常见的原因是数据对齐问题。HWA的FFT引擎对输入数据的对齐要求很严格如果对齐不对FFT引擎会读不到数据或者读到错误的数据。排查方法是检查数据搬移的地址是否满足对齐要求以及数据格式是否跟FFT配置一致。问题二CMAC吞吐率不达预期。如果发现CMAC的运算时间比理论值长很多检查数据位宽是否设成了32位。16位和32位的吞吐率差一倍如果精度允许尽量用16位。问题三HWA和DSP的流水线冲突。表现是DSP等HWA的结果HWA等DSP的数据两者互相等。排查方法是把HWA和DSP的任务执行时间打出来看两者的时间窗口是否重叠。如果不重叠调整任务划分让两者的执行时间尽量重叠。5.3 常见问题速查表问题现象可能原因排查方法解决方案目标速度测量偏差一个子带DDMA相位增量配置错误单目标场景验证多普勒谱位置检查相位增量符号和累加逻辑空子带噪声基底抬高相位噪声或射频非线性检查射频增益设置加汉宁窗调整射频增益速度解模糊失败帧间目标关联错误连续多帧多普勒谱轨迹检查调整帧周期和目标关联门限HWA FFT结果异常数据对齐或格式错误检查数据搬移地址和格式确保对齐满足要求格式一致CMAC吞吐率低数据位宽设成32位检查数据位宽配置精度允许下改用16位HWA与DSP流水线冲突任务划分不合理打印两者执行时间窗口调整任务划分重叠执行时间5.4 几条踩坑之后总结的经验第一条经验是DDMA的相位增量一定要在时域上验证。我见过有团队直接在频域上配相位增量结果发现多普勒谱上的子带位置是对的但子带内的目标相位是乱的。DDMA的相位增量本质上是在每个Chirp的发射信号上加一个相位偏移这个偏移是在时域上累加的必须在时域上验证。第二条经验是HWA的配置不要一次配太多功能。HWA的预处理单元、FFT引擎、CMAC单元可以并行工作但如果配置太复杂调度逻辑会变得很难调。建议先把FFT引擎跑通再加CMAC最后加预处理单元一步一步来。第三条经验是DDMA的速度解模糊不要只依赖单帧。单帧的多普勒谱上目标在子带里的位置是模糊的必须结合多帧的关联才能解出真实速度。实际工程中我们通常用3-5帧的关联来做解模糊帧数太少容易解错帧数太多会增加延迟。第四条经验是HWA和DSP的共享内存要留够余量。HWA的输出数据量比TDM模式下大了4倍共享内存的分配要按DDMA的数据量来算不要按TDM的来算。我们第一次做的时候就是按TDM的数据量分配的共享内存结果DDMA跑起来之后内存不够数据被覆盖了调了好久才发现。最后再分享一个小技巧AWR2944的SDK里有一个DDMA的参考例程但那个例程的配置比较保守性能没有拉满。建议在参考例程的基础上先把Chirp周期和调频斜率按实际场景需求重新算一遍再把HWA的FFT点数和数据格式对齐最后调DDMA的相位增量和空子带位置。这套流程走下来基本能跑出一个可用的DDMAHWA方案。后续如果要进一步提升性能可以考虑在HWA的预处理单元里加一些自定义的滤波或者数据压缩逻辑把DSP的负担再降一降。 
长河君 · 2026/10/6 5:48:43 · 阅读 1.2k AWR2944角雷达开发：DDMA与HWA硬件加速实战指南
1. 角雷达开发为什么绕不开AWR2944这套组合拳做毫米波雷达这行的朋友这两年应该有个明显感受角雷达Corner Radar的需求从早年的盲区监测BSD一路卷到了变道辅助LCA、后方交通穿行预警RCTA、甚至近距离点云成像。功能越堆越多天线通道数从早期的2发4收直接干到了4发4收甚至更多。这时候如果还用老一代的AWR1642或者AWR1843算力和射频通道数就有点捉襟见肘了。AWR2944这颗芯片就是在这个背景下进入大家视野的。它是TI德州仪器在第二代毫米波雷达SoC基础上做的一次比较激进的升级单芯片集成了4个发射通道、4个接收通道射频前端带宽能覆盖到76-81GHz最关键的是它内部塞了一个叫HWAHardware Accelerator硬件加速器的专用计算单元还有一颗主频300MHz的C66x DSP和一个200MHz的R5F MCU。这套异构架构摆明了就是冲着角雷达和中短距雷达市场来的。但光有硬件堆料没用真正让AWR2944在角雷达场景里跑出性能优势的是DDMADoppler Division Multiple Access多普勒分多址发射模式配合HWA硬件加速这套组合。DDMA解决的是多发射通道之间的正交性问题HWA解决的是运算吞吐量的问题两者缺一不可。我见过不少团队拿到AWR2944的EVM板之后直接套用老平台的TDM时分复用配置结果发现4发通道根本跑不出应有的角度分辨率和探测距离白白浪费了芯片能力。这篇文章我打算把DDMA和HWA这两块拆开揉碎讲清楚。从为什么TDM在4发场景下会碰到瓶颈到DDMA的波形设计原理再到HWA怎么把DDMA带来的额外运算量吃掉最后给一套可以直接参考的配置思路和踩坑记录。适合正在做角雷达方案选型、或者已经上手AWR2944但发现性能不达预期的朋友。不管你是刚接触毫米波雷达的新人还是从其他平台转过来的老手应该都能从里面找到点有用的东西。2. 从TDM到DDMA多发射通道正交化的必然选择2.1 TDM发射模式在4发场景下的三个硬伤先说说为什么老平台常用的TDM到了4发场景就不太够用了。TDM的核心思路很简单4个发射天线轮流发射同一时刻只有一个天线在工作。接收端根据时间窗口就能区分信号是哪个天线发出来的正交性天然成立处理逻辑也简单。但这套逻辑有三个绕不过去的问题。第一个是发射时间被切碎。假设一个Chirp周期是50微秒4个天线轮流发每个天线实际只占了12.5微秒。这意味着在同样的帧时间内每个发射通道能积累的Chirp数量只有单发模式的四分之一。Chirp数量直接决定了多普勒维的FFT点数点数少了速度分辨率就下降。角雷达虽然对速度分辨率要求没前向雷达那么高但RCTA场景下要区分行人和车辆的速度差异分辨率太低就容易误判。第二个是最大不模糊速度被压缩。TDM模式下等效的脉冲重复间隔PRI变成了原来的4倍根据最大不模糊速度公式 v_max λ/(4×PRI)PRI变大意味着v_max变小。角雷达探测的目标速度范围虽然不算大但高速公路上旁边车道飞驰而过的车辆相对速度可能超过100km/h这时候速度模糊就会导致目标速度测量出错。第三个是发射功率利用率低。4个天线轮流工作任意时刻只有四分之一的射频功率在辐射。对于角雷达这种需要覆盖较宽视场、探测距离又要做到几十米的场景功率利用率低直接影响信噪比进而影响探测距离。我实测过一组对比数据同样的4发4收天线布局TDM模式下探测距离大概在45米左右开始出现明显衰减而切换到DDMA之后同样的信噪比门限下探测距离能拉到60米以上。这个差距在角雷达的实际装车场景里是很关键的。2.2 DDMA的核心原理用多普勒维度换正交性DDMA的思路跟TDM完全不同。它让4个发射天线同时发射但在每个天线的发射信号上叠加一个不同的多普勒频移。这个频移是通过在每个Chirp之间给发射信号加一个相位增量来实现的相位增量对应到多普勒域就是一个固定的频率偏移。打个比方TDM像是4个人轮流用同一个话筒说话而DDMA像是4个人同时说话但每个人用不同的音调。接收端通过多普勒FFT之后4个人的声音会出现在多普勒谱的不同位置上这样就能区分开了。具体到数学上假设有N_tx个发射天线给第k个天线在每个Chirp间施加的相位增量是 Δφ_k 2πk/N_tx。这样在第k个天线的多普勒谱上目标会出现在 f_d k×f_d_max/N_tx 的位置其中f_d是目标真实多普勒频率。N_tx个天线对应的目标峰值在多普勒域上均匀分布彼此间隔f_d_max/N_tx。这个设计的精妙之处在于所有天线同时发射发射时间和功率利用率都是100%。相比TDM同样的帧时间内每个通道积累的Chirp数量翻了4倍速度分辨率直接提升4倍最大不模糊速度也恢复了。代价是多普勒域被分成了N_tx个子带每个子带能容纳的速度范围变成了原来的1/N_tx。这里有个关键参数需要算清楚。以AWR2944为例假设Chirp周期Tc50μs波长λ4mm77GHz那么单发模式下的最大不模糊速度是v_max_single λ/(4×Tc) 0.004/(4×50e-6) 20 m/s ≈ 72 km/h4发DDMA模式下每个子带的速度范围变成v_max_ddma v_max_single / 4 5 m/s ≈ 18 km/h这个速度范围对于角雷达来说够不够用取决于具体场景。BSD场景下目标相对速度一般不超过30km/h18km/h的子带范围确实有点紧张。但DDMA有个好处是可以做速度解模糊通过多帧关联或者中国剩余定理的方式把模糊的速度解出来。实际工程中我们通常会把Chirp周期设得更短一些比如Tc30μs这样v_max_ddma能到30km/h左右基本覆盖角雷达的主流场景。2.3 DDMA波形设计中的三个关键参数DDMA波形设计不是随便设几个相位增量就完事了有三个参数需要仔细权衡。第一个是空子带Empty Band的预留。4发DDMA会把多普勒谱分成4个子带但实际使用中我们通常只用了3个留一个空子带作为保护带。为什么要留因为实际系统中存在多普勒泄漏和相位噪声如果4个子带全部塞满目标相邻子带之间会互相干扰。留一个空子带之后可以通过检测空子带里的能量来判断是否存在速度模糊或者干扰。这个做法在TI的官方文档里叫DDMA with empty band是工程上比较稳妥的方案。第二个是Chirp周期和子带速度范围的折中。前面算了Tc越短子带速度范围越大但Tc太短会导致射频前端的稳定时间不够信号质量下降。AWR2944的射频前端在77GHz下Tc最小可以做到20μs左右但实际工程中建议不要低于25μs留够稳定时间。我一般会从30μs开始调根据实测的信噪比和速度范围需求再微调。第三个是DDMA相位编码与天线布局的配合。DDMA的相位增量是在时域上施加的但最终影响的是多普勒域。如果天线布局本身有俯仰维的排布DDMA的相位编码需要跟俯仰维的相位编码正交否则会在角度维产生耦合。AWR2944支持4发通道通常的布局是2个通道做方位维、2个通道做俯仰维DDMA的相位增量需要按照这个布局来分配确保方位和俯仰的解耦。3. HWA硬件加速器DDMA运算量的真正解法3.1 DDMA带来的运算量到底增加了多少DDMA虽然解决了发射正交性问题但它把运算压力全部转移到了接收端。TDM模式下接收端只需要按时间窗口把数据分给不同通道就行几乎不增加额外运算。DDMA模式下接收端需要做多普勒FFT之后在每个子带里分别做目标检测然后还要做速度解模糊和子带间的数据融合。具体算一下运算量。假设4发4收每帧64个Chirp每个Chirp采样256点。距离维FFT的点数是256点多普勒维FFT的点数是64点。TDM模式下每个接收通道的数据是16个Chirp64/4多普勒FFT是16点。DDMA模式下每个接收通道的数据是64个Chirp多普勒FFT是64点。单看FFT点数DDMA的多普勒FFT运算量是TDM的4倍。但这还不是全部。DDMA还需要做子带分离、速度解模糊、以及跨子带的目标关联。这些运算加起来整体运算量大概是TDM模式的6-8倍。如果用C66x DSP来跑这些运算300MHz的主频下单帧处理时间可能会超过帧周期导致实时性不满足。这就是HWA存在的意义。3.2 HWA的架构与DDMA运算的映射关系HWA是AWR2944内部的一个专用硬件加速器它的设计目标很明确把雷达信号处理中最常用的几类运算做成硬件流水线让DSP和MCU从繁重的重复计算中解放出来。HWA内部主要有三个计算单元FFT引擎、复数乘法累加单元CMAC、以及一个可编程的预处理单元。FFT引擎支持从16点到1024点的FFT/IFFT运算CMAC单元负责做复数乘加预处理单元可以做数据搬移、加窗、以及一些简单的矩阵运算。DDMA的处理流程跟HWA的这三个单元对应得非常整齐。距离维FFT和多普勒维FFT直接丢给FFT引擎子带分离和速度解模糊中的复数乘加丢给CMAC数据搬移和加窗丢给预处理单元。整个DDMA的接收处理链路除了目标检测和聚类这些需要灵活逻辑的部分留给DSP其余的计算密集型环节全部可以由HWA硬件流水线完成。我实测过一组数据同样的DDMA配置下纯DSP处理单帧需要约35ms而把FFT和CMAC部分卸载到HWA之后单帧处理时间降到了8ms左右。这个提升是数量级的直接决定了DDMA方案能不能落地。3.3 HWA编程的三个关键约束HWA虽然快但用起来有几个约束必须注意不然很容易踩坑。第一个是数据格式约束。HWA的FFT引擎对输入数据的格式有要求通常要求是定点复数格式而且不同点数的FFT对数据对齐的要求不一样。比如1024点FFT要求输入数据按1024字节对齐如果对齐不对FFT结果会出错。我在第一次用HWA做多普勒FFT的时候就因为对齐问题调了一整天后来发现是数据搬移的时候偏移了一个字节。第二个是CMAC的吞吐率约束。CMAC单元虽然快但它的吞吐率跟数据位宽有关。16位复数乘加的吞吐率是32位复数乘加的两倍。DDMA的子带分离运算中如果数据位宽设得太高CMAC的吞吐率会成为瓶颈。实际工程中我们通常会在精度允许的范围内尽量用16位数据把CMAC的吞吐率拉满。第三个是HWA与DSP的协同调度。HWA和DSP是并行工作的但两者之间的数据交互需要通过共享内存。如果调度不当DSP等HWA的结果、HWA等DSP的数据两者互相等反而比纯DSP还慢。正确的做法是把整个处理链路切成若干段HWA处理第一段的时候DSP处理上一帧的第二段形成流水线。这个调度逻辑需要仔细设计TI的SDK里有参考实现但实际项目中还是要根据具体的数据流做调整。4. 一套可参考的DDMAHWA配置方案4.1 波形参数配置与计算过程下面给一套我实际项目里用过的配置方案场景是角雷达BSDRCTA探测距离要求60米以上速度范围要求±30km/h。先确定Chirp周期。目标子带速度范围是30km/h≈8.33m/s4发DDMA下每个子带的速度范围是v_max_single/4所以v_max_single需要达到33.3m/s。根据v_max_singleλ/(4×Tc)反推TcTc λ/(4×v_max_single) 0.004/(4×33.3) 30μs所以Chirp周期设为30μs。这个值也留够了射频前端的稳定时间。然后确定每帧的Chirp数量。多普勒FFT的点数决定了速度分辨率角雷达一般要求速度分辨率在1m/s以内。速度分辨率Δvλ/(2×N_chirp×Tc)代入Δv1m/sN_chirp λ/(2×Δv×Tc) 0.004/(2×1×30e-6) 66.7取整到64个Chirp。这样速度分辨率是0.004/(2×64×30e-6)1.04m/s满足要求。采样点数方面距离分辨率要求0.5米根据Δrc/(2×B)B是射频带宽。AWR2944支持的最大带宽是4GHz对应距离分辨率0.0375米。实际中我们不需要这么高的分辨率设B1GHz距离分辨率0.15米。采样率设10MHz采样256点对应的最大距离是c×Fs/(2×S)S是调频斜率。SB/Tc1e9/30e-633.3GHz/s最大距离3e8×10e6/(2×33.3e9)45米。这个距离不够60米需要调整。把调频斜率降到20GHz/s带宽BS×Tc20e9×30e-6600MHz距离分辨率0.25米。最大距离3e8×10e6/(2×20e9)75米满足60米要求。采样点数保持256点。最终波形参数汇总参数数值说明Chirp周期30μs兼顾速度范围和射频稳定每帧Chirp数64速度分辨率1.04m/s调频斜率20GHz/s最大距离75米采样点数256距离分辨率0.25米发射模式4发DDMA留1个空子带帧周期20ms50帧/秒4.2 HWA数据流配置与DSP任务划分HWA的配置需要跟上面的波形参数对齐。距离维FFT是256点多普勒维FFT是64点。HWA的FFT引擎配置如下// HWA FFT配置示例伪代码 HWA_FFT_Config fftConfig; fftConfig.fftSize 256; // 距离维FFT点数 fftConfig.dataFormat COMPLEX_16BIT; // 16位复数格式 fftConfig.alignment 256; // 256字节对齐 fftConfig.windowType HANNING; // 汉宁窗 // 多普勒维FFT配置 HWA_FFT_Config dopplerConfig; dopplerConfig.fftSize 64; dopplerConfig.dataFormat COMPLEX_16BIT; dopplerConfig.alignment 64; dopplerConfig.windowType HANNING;DSP的任务划分是这样的DSP负责目标检测CFAR、聚类、以及速度解模糊的逻辑判断。HWA负责距离维FFT、多普勒维FFT、以及子带分离中的复数乘加。两者通过共享内存交互DSP在HWA完成一帧的FFT之后读取结果做CFAR同时HWA开始处理下一帧的数据形成流水线。这里有个细节需要注意HWA的FFT结果输出到共享内存之后DSP读取之前需要做一次数据格式转换因为HWA输出的是定点格式DSP做CFAR需要浮点格式。这个转换如果放在DSP里做会增加DSP的负担。我们的做法是在HWA的预处理单元里加一个定点转浮点的步骤虽然HWA的预处理单元做这个转换效率不如DSP但胜在不占用DSP的运算资源。4.3 实测性能与调优记录这套配置在实际测试中的表现探测距离在信噪比12dB的门限下达到了68米速度范围±32km/h角度分辨率在方位维达到了8度左右4发4收DDMA模式下等效8发虚拟阵列。调优过程中遇到的最大问题是多普勒谱的泄漏。DDMA的4个子带之间由于相位噪声和射频非线性的影响子带边缘有能量泄漏导致空子带里的噪声基底抬高了约6dB。这个抬高直接影响了CFAR的检测门限一些弱目标被淹没了。解决方法是加窗。在多普勒FFT之前加汉宁窗窗函数的旁瓣抑制能把子带间的泄漏压下去。但加窗会带来主瓣展宽速度分辨率会下降约1.5倍。我们试过汉明窗和布莱克曼窗最后选了汉宁窗因为它在旁瓣抑制和主瓣展宽之间平衡得比较好。另一个问题是HWA的CMAC吞吐率在子带分离时成了瓶颈。子带分离需要做4次复数乘加每次的数据量是64点复数。16位格式下CMAC的吞吐率是每周期4次复数乘加64点需要16个周期4次子带分离需要64个周期。加上数据搬移的开销子带分离的总耗时约200个周期在200MHz的HWA时钟下是1μs。这个耗时本身不大但如果跟FFT串行执行累加起来就影响了帧处理时间。后来我们把子带分离和FFT做了并行调度HWA的FFT引擎和CMAC单元同时工作把总耗时压到了原来的60%。5. 常见问题排查与避坑经验5.1 DDMA相关的典型问题问题一多普勒谱上目标出现在错误的子带里。这个问题的表现是目标的速度测量值跟实际值差了一个子带宽度。原因通常是DDMA的相位增量配置错了或者Chirp之间的相位增量没有正确累加。排查方法是先发一个单目标场景看目标在多普勒谱上的位置是否跟预期一致。如果偏了一个子带检查相位增量的符号和累加逻辑。问题二空子带里的噪声基底异常抬高。前面提到过这个通常是相位噪声或者射频非线性导致的。除了加窗之外还可以检查射频前端的增益设置是否合理。增益太高会导致非线性增益太低会导致信噪比不够。AWR2944的射频增益建议从30dB开始调根据实测的噪声基底再微调。问题三速度解模糊失败。DDMA的速度解模糊依赖于多帧之间的关联如果帧间的目标关联做错了解模糊就会失败。排查方法是把连续几帧的多普勒谱打出来看确认目标在子带间的移动轨迹是否连续。如果轨迹跳变检查帧周期是否稳定以及目标关联的门限是否设得太松。5.2 HWA相关的典型问题问题一FFT结果全零或者全噪声。这个最常见的原因是数据对齐问题。HWA的FFT引擎对输入数据的对齐要求很严格如果对齐不对FFT引擎会读不到数据或者读到错误的数据。排查方法是检查数据搬移的地址是否满足对齐要求以及数据格式是否跟FFT配置一致。问题二CMAC吞吐率不达预期。如果发现CMAC的运算时间比理论值长很多检查数据位宽是否设成了32位。16位和32位的吞吐率差一倍如果精度允许尽量用16位。问题三HWA和DSP的流水线冲突。表现是DSP等HWA的结果HWA等DSP的数据两者互相等。排查方法是把HWA和DSP的任务执行时间打出来看两者的时间窗口是否重叠。如果不重叠调整任务划分让两者的执行时间尽量重叠。5.3 常见问题速查表问题现象可能原因排查方法解决方案目标速度测量偏差一个子带DDMA相位增量配置错误单目标场景验证多普勒谱位置检查相位增量符号和累加逻辑空子带噪声基底抬高相位噪声或射频非线性检查射频增益设置加汉宁窗调整射频增益速度解模糊失败帧间目标关联错误连续多帧多普勒谱轨迹检查调整帧周期和目标关联门限HWA FFT结果异常数据对齐或格式错误检查数据搬移地址和格式确保对齐满足要求格式一致CMAC吞吐率低数据位宽设成32位检查数据位宽配置精度允许下改用16位HWA与DSP流水线冲突任务划分不合理打印两者执行时间窗口调整任务划分重叠执行时间5.4 几条踩坑之后总结的经验第一条经验是DDMA的相位增量一定要在时域上验证。我见过有团队直接在频域上配相位增量结果发现多普勒谱上的子带位置是对的但子带内的目标相位是乱的。DDMA的相位增量本质上是在每个Chirp的发射信号上加一个相位偏移这个偏移是在时域上累加的必须在时域上验证。第二条经验是HWA的配置不要一次配太多功能。HWA的预处理单元、FFT引擎、CMAC单元可以并行工作但如果配置太复杂调度逻辑会变得很难调。建议先把FFT引擎跑通再加CMAC最后加预处理单元一步一步来。第三条经验是DDMA的速度解模糊不要只依赖单帧。单帧的多普勒谱上目标在子带里的位置是模糊的必须结合多帧的关联才能解出真实速度。实际工程中我们通常用3-5帧的关联来做解模糊帧数太少容易解错帧数太多会增加延迟。第四条经验是HWA和DSP的共享内存要留够余量。HWA的输出数据量比TDM模式下大了4倍共享内存的分配要按DDMA的数据量来算不要按TDM的来算。我们第一次做的时候就是按TDM的数据量分配的共享内存结果DDMA跑起来之后内存不够数据被覆盖了调了好久才发现。最后再分享一个小技巧AWR2944的SDK里有一个DDMA的参考例程但那个例程的配置比较保守性能没有拉满。建议在参考例程的基础上先把Chirp周期和调频斜率按实际场景需求重新算一遍再把HWA的FFT点数和数据格式对齐最后调DDMA的相位增量和空子带位置。这套流程走下来基本能跑出一个可用的DDMAHWA方案。后续如果要进一步提升性能可以考虑在HWA的预处理单元里加一些自定义的滤波或者数据压缩逻辑把DSP的负担再降一降。