注意：本文没有提下位机的概念，下位机里面最核心的是雷达主控。
做雷达系统架构梳理时，最容易出问题的地方往往不是某个模块本身，而是模块之间的边界。主控和DSP谁指挥谁、FPGA和DSP谁算什么、点迹和航迹在哪一步分界、上位机到底管什么------这些问题单看每个模块都清楚，一旦落到文档里画成框图，就容易出现"主控产生航迹点"这类经不起推敲的表述。
这篇文章把雷达主控、FPGA、DSP、算法、上位机、点迹录取与数据处理之间的关系重新理一遍，重点讲清楚四件事：分层怎么分、控制流和数据流怎么走、点迹和航迹的边界卡在哪、算法到底算哪一层的东西。
一、先给结论：四层结构，控制与数据分离
雷达系统的完整链路可以收敛为四层：
交互层（上位机）→ 调度层（雷达主控）→ 硬实时预处理层（FPGA）→ 核心算法层（DSP）→ 数据处理与跟踪层（点迹录取与航迹处理） 。
这个分层的关键不在于名字，而在于每条边界上的职责是死的：
- 上位机不参与硬实时链路，只做任务配置、参数下发、可视化、状态监控和数据存储；
- 主控只做时序生成、波束调度、任务优先级管理和状态汇总，它是指挥者，不是计算者；
- FPGA承担高速前端预处理和硬实时流水线，典型如数字下变频（DDC）、抽取滤波、脉冲压缩、数据重排缓存和接口桥接；
- DSP承担计算密集、流程复杂的核心算法，典型如MTD、CFAR、DBF系数计算和部分数据处理；
- 点迹录取 输出单帧量测（点迹），数据处理输出跨帧关联后的状态序列（航迹）。
很多架构文档出问题，就是因为把这条链上的某一环说成了另一环的职责。最常见的两种误述是"主控调用天线产生航迹点"和"航迹点通过主控调度产生"------两者都跳过了点迹录取和数据关联两个关键阶段，也把主控的调度角色误当成了计算角色。
二、主控：调度者，不是计算者
主控模块（常由FPGA或专用控制芯片承担）的核心职责是让正确的模块在正确的时间拿到正确的数据。它根据上位机下发的参数，产生精确的发射/接收时序、波束指向指令，监控各分系统状态，并把DSP的处理状态汇总回传上位机。
它不执行脉压、CFAR、卡尔曼滤波这类运算。把"主控完成航迹滤波"或"主控进行目标检测"写进文档，是把调度层和计算层混为一谈。主控的价值在于时序精度和任务编排，而不是算力。
三、FPGA与DSP：硬实时前端与核心算法层
补上FPGA之后，实时算法执行的表述就不能再笼统地说"由DSP完成"了。典型分工是：
FPGA做固定系数、高吞吐、流水线化的运算------DDC、抽取滤波、脉压、数据重排缓存、接口桥接（ADC接口、SRIO/Aurora、与DSP的EMIF等），部分架构下还承担波控码生成或DBF前端加权。
DSP做流程复杂、系数可变的运算------MTD滤波器组、CFAR检测、DBF系数计算、部分数据处理。
写架构文档时，建议按"FPGA硬实时前端 → DSP核心算法 → 数据处理跟踪"三段描述，而不是笼统说"信号处理由DSP完成"。否则会掩盖FPGA在数据通路上的实际贡献，也解释不了为什么某些算法必须放在FPGA而不能挪到DSP。
四、点迹与航迹：边界必须卡死
这是整条链路里最容易出错的地方。
点迹（Plot） 是单帧、单次量测，来自天线截获回波、经接收机、ADC、FPGA预处理、DSP检测后的点迹录取输出，包含目标在某一时刻的距离、方位、俯仰等量测值。
航迹（Track） 是跨帧关联后的状态序列，来自点迹经数据关联、滤波、航迹起始与维持后的输出。
两者分属不同模块，中间隔着点迹录取和数据关联两个阶段。把"检测到目标"直接说成"形成航迹"，或者把天线说成"航迹点的产生者"，都是把三个阶段压成了一句话。更准确的表述是：主控通过波束调度和时序控制，为点迹的持续获取和航迹的稳定维持提供资源保障，而不是直接"产生"它们。
五、算法：不是独立一层，是贯穿多层的规则
算法嵌在FPGA里（脉压系数、DDC滤波系数、DBF加权），嵌在DSP里（CFAR门限、MTD滤波器组、跟踪滤波），也嵌在上位机里（显示端航迹平滑）。它不是一个独立的硬件层，而是各处理节点的处理逻辑。
参数的下行路径值得单独说明：上位机配置 → 主控转发 → FPGA/DSP加载。这条路径是联调时最容易出问题的环节，建议在架构文档里单独画一条，而不是混在数据流里一笔带过。
六、控制流与数据流：分开画，别画成一条双向箭头
很多架构图把控制和数据画成一条双向箭头，导致读者分不清谁指挥谁、谁给谁数据。正确做法是分开两条链路：
控制流下行：上位机（任务参数）→ 主控（时序、波束调度、模式切换）→ FPGA（预处理参数、脉压系数加载）/ DSP（算法参数加载）。
数据流上行：天线 → 接收机 → ADC → FPGA（DDC、抽取、脉压、数据组织）→ DSP（MTD、CFAR、DBF系数、部分数据处理）→ 点迹录取（点迹）→ 数据处理（航迹）→ 主控（汇总/转发）→ 上位机（显示/存储）。
调试旁路另算：上位机可直接读FPGA寄存器或DSP内存，抓脉压前后波形、CFAR门限等中间量。这是诊断功能，不是主链路职责。
七、两张图：架构分层与点迹→航迹时序
下面两张 Mermaid 图可以直接放进文档。第一张是分层架构与数据/控制流，第二张是点迹→航迹生成的时序，重点把"主控只调度、不产生量测"这个边界画清楚。
图1：雷达系统分层架构与数据/控制流
读图要点：实线是主链路，虚线是调度/旁路；控制流只下行，数据流只上行。主控不在数据链上产生任何量测值，只下发指令、汇总状态。
图2：点迹→航迹生成时序
读图要点：点迹出现在"检测结果→点迹录取"之后，航迹出现在"数据关联/滤波"之后；主控全程只下发指令、汇总状态，不参与量测生成。
八、还有几个容易被忽略的细节
术语一致性。同一份文档里，"主控"不要一会儿指FPGA、一会儿指整个控制板；"DSP"不要一会儿指芯片、一会儿指算法模块；"上位机"不要和"显控台""终端"混用。建议开篇给一张术语表，固定每个词的指代。
实时性等级要标注。FPGA层是硬实时（微秒级流水），DSP层是硬实时/准实时（毫秒级帧处理），上位机层是软实时/非实时（显示与存储）。标出实时性等级，能避免把上位机功能误塞进实时链路，也能解释为什么某些算法必须放FPGA而不能放DSP或上位机。
上位机的角色别拔高也别贬低。它不控制雷达发射（发射时序由主控产生，上位机只下发宏观参数），也不做信号处理（只做显示和后处理分析）。调试模式下旁路抓DSP中间数据，那是诊断功能，不是主链路职责。
小结
雷达系统架构梳理的核心，可以收敛成三句话：
分层要清------交互层、调度层、硬实时预处理层、核心算法层、数据处理与跟踪层，各司其职；
边界要死------点迹不等于航迹，调度不等于处理，配置不等于控制；
流向要分------控制流与数据流分开画，调试旁路单独标注。
做到这三点，架构描述基本不会出硬伤。补上FPGA之后，整条链路才算完整；而把点迹与航迹的边界卡死，才不会再出现"主控产生航迹点"这类看似顺口、实则失准的表述。