1. 星载异构计算平台集成验证概述

星载异构计算平台，是指在同一星上电子系统中同时集成CPU通用处理单元、FPGA可编程逻辑、GPU/AI加速器、DSP信号处理器等两类以上异构计算资源的硬件与软件综合体。它通常以SoC、SiP或板卡级多芯片协同的形式出现，承担星上数据处理、目标识别、自主决策、载荷数据压缩与转发等任务。与地面异构计算系统相比，星载平台面对的是不可维修、辐射恶劣、功耗与散热受限、通信窗口间歇的约束环境，因此"设计正确"并不等于"系统可用"，必须通过系统化的集成验证来证明平台在真实约束下能够稳定完成既定功能。

课程目标

本课程围绕"如何证明一个星载异构计算平台真的可用"这一核心问题展开，目标是让学习者建立从验证对象界定、验证环境搭建、测试用例设计，到结果判读与问题定位的完整能力链。具体而言，完成课程后应能够：

• 准确界定一个异构平台的验证边界，区分单器件验证、板级集成验证与系统级验证的职责差异；
• 针对CPU+FPGA+AI加速器等典型组合，设计覆盖接口、数据通路、时序、功耗与容错的验证方案；
• 搭建半实物仿真与在轨等效测试环境，合理使用星务模拟器、载荷数据源与故障注入工具；
• 依据覆盖率、时序余量、误码率、功耗曲线等客观指标判断验证是否充分；
• 对验证中暴露的跨时钟域、资源竞争、辐射单粒子效应等问题进行定位与回归。

需要强调的是，集成验证不是"把各模块测一遍再拼起来"，而是要在模块之间真实的交互条件下，暴露那些单独测试永远看不到的问题。例如FPGA逻辑单独仿真时序收敛，但与CPU通过AXI总线交互时，因握手协议理解偏差导致死锁；AI加速器单独跑推理正常，但在载荷数据突发输入时因DDR带宽争用而超时。这类问题正是集成验证的价值所在。

验证对象界定

在启动任何验证活动之前，必须先明确"验什么"。星载异构计算平台的验证对象通常可划分为四个层次，界定不清会导致验证重复或遗漏。

界定验证对象时，一个实用做法是画出平台的"接口清单"：列出每一对需要交互的模块、它们之间的物理介质（如AXI、SpaceWire、LVDS、PCIe）、数据方向、时钟域以及协议版本。接口清单就是集成验证的最小工作单元集合，任何未列入清单的交互都应在评审中说明理由。

集成验证在星载计算系统研制中的位置

星载计算系统的研制通常遵循"需求分析—架构设计—详细设计—实现—集成验证—环境试验—在轨测试"的流程。集成验证处于实现与环境试验之间，是设计正确性从"纸面"走向"实物"的关键闸门。它向上承接详细设计输出的接口定义与时序约束，向下为环境试验（热真空、振动、EMC）和在轨测试提供功能基线。若集成验证不充分，问题会被推迟到环境试验甚至发射后暴露，代价呈数量级上升。

从工程节奏看，集成验证往往与详细设计并行启动：在硬件投板前，先用FPGA原型和仿真模型验证关键数据通路；硬件回板后，再逐步把真实器件替换进验证环境。这种"逐步替换、逐步逼近真实"的策略，可以在早期用较低成本发现接口级问题。

典型平台形态与验证挑战

当前星载异构平台主要有三种形态。第一种是"CPU+FPGA"型，CPU负责星务管理与任务调度，FPGA承担高速接口与数据预处理，常见于遥感卫星的数传分系统。第二种是"CPU+AI加速器"型，面向在轨智能处理，AI芯片完成目标检测与分类，CPU负责结果融合与上报。第三种是"CPU+FPGA+DSP"型，多用于雷达与电子侦察载荷，DSP完成脉冲压缩与参数估计。三种形态的验证重点不同：第一种重接口时序与数据完整性，第二种重推理精度与实时性，第三种重信号链路的信噪比与动态范围。

无论哪种形态，集成验证都面临四类共性挑战。其一是跨时钟域问题：异构芯片往往工作在不同时钟频率下，异步FIFO深度不足或握手信号采样错误会导致偶发数据丢失，这类问题在实验室短时测试中极难复现，需要长时间压力测试与断言监控。其二是资源竞争：多个计算单元共享DDR、总线或电源轨，突发负载下可能出现带宽饥饿或电压跌落，验证时必须构造最坏情况负载。其三是辐射效应：单粒子翻转可能改变FPGA配置位或CPU寄存器内容，验证中需通过故障注入模拟SEU，观察平台的检错与恢复能力。其四是功耗与热耦合：异构芯片同时满载时局部热点可能触发降频，验证需同步记录功耗曲线与结温，判断是否满足热设计余量。