Titan Bound：航向协处理器控制器 FPGA SoC 设计
摘要
本文描述了航向协处理器控制器（NCC）FPGA及其软处理器的架构和验证，该软处理器为 NASA 新前沿龙飞（Dragonfly）探测器执行泰坦任务而实现。NCC 是飞行软件（FSW）的外围组件互连（PCI）目标，并驻留在航向协处理器板（NCP）上。NCC 的关键功能包括以精确间隔向旋翼驱动电子（RDE）发送命令并接收遥测，向 FPGA 上的机载视觉处理（OVP）提供接口，将原始图像和激光雷达（LiDAR）地形图记录到 NAND 闪存，启动 NCP 上的组件，清洗 OVP，以及通过通用异步收发器（UART）向 NavCam 和 LiDAR 发送命令。NCC 包含一个高级微控制器总线架构（AMBA），该架构被分为两个部分，并通过高级高性能总线（AHB）到 AHB 桥连接，以将频繁的流量与 FSW 和 OVP 分离。团队使用传统和现代验证实践的组合来验证 NCC。许多设计师使用传统的超高速集成电路（VHSIC）硬件描述语言（VHDL）测试平台分别验证 NCC 中的各个模块。顶层仿真使用 Siemens 的现代通用验证方法学框架（UVMF）来建立一个通用框架，以测试 NCC 的复杂设计，并在 NCC 设计演进时实现灵活性和可扩展性。
作者
Steven Zhan 约翰·霍普金斯大学兰洛尔应用物理实验室
Matthew Gile 约翰·霍普金斯大学兰洛尔应用物理实验室
Christopher Monaghan 约翰·霍普金斯大学兰洛尔应用物理实验室
Ethan Mellert 约翰·霍普金斯大学兰洛尔应用物理实验室
Owen Pochettino 约翰·霍普金斯大学兰洛尔应用物理实验室
Justin Kelman 约翰·霍普金斯大学兰洛尔应用物理实验室
Ankita George 应用物理实验室，约翰·霍普金斯大学，劳雷尔
Minh Quan Tran 应用物理实验室，约翰·霍普金斯大学，劳雷尔
Jeffrey Boye 应用物理实验室，约翰·霍普金斯大学，劳雷尔
出版信息
期刊： 2025 IEEE Aerospace Conference 年份： 2025 页码： 1-10 DOI： 10.1109/AERO63441.2025.11068457 文章编号： 11068457 ISSN： Electronic ISSN: 2996-2358, Print on Demand(PoD) ISSN: 1095-323X
指标
总下载量： 18
关键词
IEEE 关键字： VHDL, Laser radar, Navigation, Transmitters, Computer architecture, Very high speed integrated circuits, Timing, Integrated circuit modeling, Field programmable gate arrays, Coprocessors
索引词： System-on-chip, System-on-Chip Designs, Raw Images, Light Detection And Ranging, Test Bench, Dragonfly, Data Storage, Data Transfer, Temperature Sensor, Source Control, Top Level, Heat Sink, Random Access Memory, Phase-locked Loop, Chip Design, Scrubber, Single-board Computer, Static Random Access Memory
未定义
第一节：引言
NASA 的新前沿计划——龙飞号（Dragonfly）前往泰坦（Titan）的任务，旨在在土星的卫星泰坦上降落一架旋翼飞行器。在其 3.3 年的基准任务期间，旋翼飞行器将探索地表的不同地点，研究前生化过程以及它们是否产生了生命的化学构建块。
它将成为首架将整个科学有效载荷飞往地表不同地点的航天器，为针对性获取地表材料提供支持。龙飞号由约翰·霍普金斯大学 APL 为 NASA 行星任务项目办公室管理。
NCP 是 Dragonfly 着陆器上的导航协处理器板，位于主 PCI 航天器总线上，只有一个发起器——RAD750 单板计算机 (SBC)。每个集成电子模块 (IEM) 盒子配有两块 NCP 卡，分别称为 NCP A 和 NCP B，每块卡连接到 IEM 中各自独立、冗余的 PCI 总线。每块 NCP 板都包含一个 Microchip RTG4 FPGA（现场可编程门阵列），被称为导航协处理器控制器 (NCC)，以及一个 Xilinx KU060 FPGA，被称为机载视觉处理 FPGA (OVP)。这两块 NCP 板在 FPGA 设计上完全相同。SBC 上的飞行软件 (FSW) 与 NCP 上的 NCC——仅为 PCI 目标设备——在航天器总线上通信，以访问 NCP 的功能。
NCC 支持 FSW 访问 RDE、NavCam 和 LiDAR 的 UART 接口。NCC 被设计为以精确的 10 毫秒间隔向 RDE UART 发送命令并接收遥测，以控制旋翼。FSW 以 1Hz 的频率向 NCC 发送 NavCam 命令，NCC 将其转发并将 NavCam 的响应存储在 NCC 缓冲区，供 FSW 读取。FSW 通过 NCC 控制 LiDAR 以 1Hz 接收遥测，NCC 将其存储在自身缓冲区中。
NCC 是访问 OVP 的唯一手段。FSW 通过 NCC 命令 OVP 执行其所需的硬件加速处理，以处理 NavCam 图像和 LiDAR 高程图，用于导航。NCC 通过 SelectMap 接口对 OVP 进行编程，并清除 OVP 的配置内存，以修复在旋翼机飞行期间可能发生的任何错误。NCC 还从 OVP 接收原始 NavCam 图像和 LiDAR 高程图，并将其存储到 NCP 上的 NAND Flash 中，供 FSW 在后续检索。
NCC 是一种片上系统 (SoC) 设计，包含一个软核 LEON 处理器。NCC 的 LEON 负责 NAND Flash 的所有数据传输。
NCC 与磁阻随机存取存储器 (MRAM) 和静态随机存取存储器 (SRAM) 接口。MRAM 包含单个 OVP 位流以及每个 NCC 和 OVP 软核处理器的两个启动映像。NCC 包含逻辑，以为每个处理器选择一个未损坏的启动映像。
图 1. NCP 硬件框图
NCC 允许 FSW 选择从存储在 MRAM 或 NAND Flash 中的 OVP 位流编程 OVP。
NCC 使用 SRAM 作为临时缓冲区，供 FSW 加载数据到 OVP 或 NAND Flash 并从中接收数据。
SECTION 2. 硬件概述
Figure 1 显示了导航协处理器（NCP）板硬件的框图。Figure 2 显示了完整硬件装配的渲染图。NCP 是机载集成电子模块（IEM）内的辅助计算机卡，主要为移动子系统提供计算资源，以执行导航和控制功能之外以及支持主要 RAD750 处理器（运行 flight \text{software} + \text{mobility} GNC 应用）的地形感知。NCP 还提供与转子驱动电子（RDE）、导航摄像头（通过 IEM 的冗余控制卡 / RCC）和 LiDAR 的接口。
NCP 拥有两个 FPGA。主 FPGA 是 Microchip RTG4，称为导航协处理器控制器（NCC），本文的重点。NCC FPGA 是可重新编程的基于闪存的设备，允许通过飞行交付实现敏捷开发，并具备自启动逻辑结构，简化并提高硬件设计的可靠性。辅助 FPGA 是 Xilinx Kintex Ultrascale，称为机载视觉处理器（OVP）。OVP 为电光地形感知（ETS / 导航摄像头基准）和 LiDAR 地形感知（LTS / LiDAR 基准）提供额外逻辑资源。OVP 是基于 SRAM 的 FPGA，必须在启动时编程。NCC 管理功率状态、编程、擦除和与 IEM Box 的 OVP 通信。
Figure 2. NCP 硬件装配
Figure 3. Dragonfly NCC FPGA 架构
The NCC FPGA 具备 PCI 控制器和 GPIO，用于机箱内部通信；LVDS 缓冲器，用于机箱外部通信；SelectMAP 接口，用于编程和擦除 OVP FPGA；以及自定义的 NCC‑to‑OVP FPGA 间互连接口。NCC 可直接访问 8 GB 的 ONFI 2.0 NAND Flash 用于大容量存储，16 MB 的 SRAM（带 BCH EDAC）用于工作内存，24 MB 的 MRAM 用于 OVP FPGA 与 NCC 软件的启动存储。
OVP FPGA 配备 LVDS 缓冲器，用于机箱外部接口（导航摄像机和 LiDAR）。OVP 可直接访问 24 Gbit 的 DDR3 SDRAM，用于 ETS 处理期间的图像存储。OVP 还配备了两个独立的 Quad Data Rate (QDR) 同步 SRAM（SSRAM）银行，以满足 ETS（2D‑FFT / 相位相关）和 LTS 处理的高吞吐量需求。ETS 与 LTS 管道的吞吐量和随机访问需求迫使采用高速 SRAM（具有平坦/确定性随机访问时间），而非 SDRAM（后者的访问延迟随访问模式而变化，有时相当大）。
NCP 支持多种电源状态，以适应不同的任务场景，范围从“睡眠模式”（所有核心轨道关闭，< 0.5 W）、“表面模式”（NCC 电源域开启，OVP 电源域关闭，约 2.5 W）到“表面飞行模式”（NCC 与 OVP 电源域开启，ETS 与 LTS 管道运行，约 25 W）。为满足高功耗模式下的热量散发，NCP 集成了坚固的铜制散热器和固定装置，用于直接热接触 IEM 机箱底盘和航天器甲板。整个组件（板、框架、散热器）重量为 1 kg。该板符合 6U cPCI 尺寸规范 -6.299^{\prime\prime} \times 9.187^{\prime\prime}。板采用 24 层聚酰亚胺结构，使用盲孔和通孔，成品厚度为 0.116^{\prime\prime} +/-0.012^{\prime\prime}。
SECTION 3. FPGA 架构
Dragonfly NCC FPGA 的架构如图 3 所示。 虚线代表 NCC FPGA，虚线之外的所有块均为 NCC FPGA 外部。 NCC FPGA 的每个块表示一个 IP 核心。 标记为 “APL” 的块包含约翰霍普金斯 APL 工程师设计的模块。 标记为 “Gaisler” 的块表示这些核心是从第三方 IP 供应商购买的。 加号的数量表示对 Gaisler IP 核心所做修改的程度。 这些修改是为了解决与外部外围设备的特定接口问题，或在寄存器中添加额外的调试信息以供 FSW 使用。
时钟与复位
NCC FPGA 从本地板载振荡器接收主 30 MHz 时钟，并在整个 FPGA 内部用作 AMBA 总线的时钟。 该设计未使用相位锁定环（PLL），以避免锁定丢失导致 FSW 出现软件异常并使 NCC 从 PCI 总线上消失。
该模块还提供飞行软件发出 NCC 重置的能力，并在重置原因寄存器中跟踪此操作。 同时还有专门用于重置 LEON3FT 和 OVP 的寄存器。
总线架构
NCC FPGA 的内部总线架构是一个 AMBA 网络，分为两个 AHB 总线，并通过 AHB-AHB 桥相连。 由于 NCC 作为 PCI 目标只能响应 FSW 发起的事务，并且可以避免双向总线可能出现的死锁问题，AHB-AHB 桥是单向的。 每个 AHB 总线都包含一个 APB，如图 3 所示。 APB 总线用于访问这些模块的寄存器。 两个 AHB 总线（称为 AHB0 和 AHB1）被配置为采用轮询方式运行。
The AHB1总线主要由运行在RAD750上的Flight Software（飞行软件）掌控，通过PCI-AHB桥（图3中的GRPCI2）。AHB1上另外两个重要的总线主控是Spacewire AHB桥（GRSPW2）和AHB JTAG。这两种AHB主控用于调试，允许用户通过在SPW上使用远程内存访问协议（RMAP）命令或通过JTAG上的GRMON来获取对NCC的访问，而不必使用PCI。两种AHB主控还可以访问PCI不可访问的调试模块。频繁被FSW访问的RDE UART同样被放置在同一AHB1总线上，以优化总线流量。FSW以较低频率1Hz通过AHB-AHB桥访问AHB0上的模块。
The AHB0总线在旋翼机飞行期间最常被LEON3FT软核处理器和擦除器（scrubber）掌控。软核处理器使用该总线进行指令和数据的提取，并将NavCam图像和LiDAR地形图存储到NAND Flash。擦除器按FSW指定的速率执行OVP的盲擦除。擦除器会周期性地读取存储在MRAM或NAND Flash中的OVP比特流配置帧，并将其覆写到OVP上。将LEON3FT和擦除器放在与RDE UARTs不同的AHB总线上可以优化总线流量。
PCI 接口
The PCI接口是NCP与航天器总线之间的连接。该连接是Flight Software（飞行软件）访问NCC的唯一通道。 The PCI接口采用Gaisler的GRPCI2核实现。PCI接口实现了一个兼容2.3版PCI本地总线规范的32位PCI目标。
The 与AMBA总线的连接包括用于PCI目标功能的AHB主控接口，以及用于访问核心中配置寄存器的AMBA APB从机接口。PCI和AMBA接口分别属于不同的时钟域，33.3 MHz和30 MHz。通过核心内部的双时钟FIFO完成这两个域之间的同步。
通过桥接访问 NCC FPGA 的 AMBA 总线是通过访问五个基址寄存器（BAR）之一来完成的。除 AHB0 总线上的调试模块（如调试支持单元 DSU）外，NCC 的所有内存和寄存器均可通过 PCI 访问。所有 BAR 的预取已启用。
第五个 BAR 包含 NCC 上所有可读寄存器。这些可读寄存器在其他 BAR 中也存在，但被镜像并连续排列，以通过允许大批量 PCI 读取来提升 FSW 对 PCI 读操作的执行效率。
NCC LEON
LEON3FT 在 AHBROM（包含启动代码的 PROM）的起始位置启动，并跳转至存放镜像的应用程序内存。FTAHBRAM，也称为 LEON 应用程序内存，是执行应用程序代码的位置，并通过清洗（scrubbing）和 EDAC 进行错误容错保护。IRQ 控制器处理来自 AMBA 总线的 LEON 分配的中断，通用定时器可供处理器使用。该设计还包括 APBUART 和 JTAG 控制器，提供控制台和 GRMON 访问，用于处理器调试和用户交互。
RDE UARTs
NCC FPGA 的 RDE 指令与遥测 UART（简称 RDE UART）与转子驱动电子 FPGA 接口。共有四个 UART，每个 UART 的架构相同且具有独立的内存映射。
UART 的 Tx（指令）端通过 AHB 接口接收 24 字节的 RDE 指令，将指令复制到缓冲区以待发送，并每 10 毫秒按顺序通过 UART 接口传输这些字节。
UART 的 Rx（遥测）端接收 RDE 遥测数据。接收到的遥测数据被放置在双端口 RAM 中，并可通过 AHB 接口供飞行软件（FSW）访问。Rx 采用 ping-pong 方式，因此当 FSW 正在从一个缓冲区读取遥测数据时，NCC 正在将新的遥测数据写入另一个缓冲区。NCC 根据数据字段对高优先级遥测进行字对齐，以减轻 FSW 解析字节为数据字段的负担。
NavCam 和 LiDAR UARTs
NavCam 和 LiDAR UART 用于连接 NavCam 和 LiDAR。该设计使用 AMBA 接口将设计与 NCC FPGA 连接。APB 寄存器可用于更改 UART 的操作配置，或查看状态计数器，例如已接收字节数。AHB 总线用于将数据发送和接收到映射到内存的命令或遥测 RAM 缓冲区。控制逻辑将在这些缓冲区与用于与 NavCam 和 LiDAR 通信的 Tx 和 Rx UART 之间传输数据。NCC 处理 LiDAR 所需的 HDLC（高级数据链路控制）编码和解码，使 FSW 不必担心数据包的编码或解码。
内存接口
NCP 本地存在三种不同类型的内存，由 NCC 控制。MRAM 和 Flash 设备作为引导映像和科学数据的主要非易失性内存，而 SRAM 则作为瞬时命令和遥测的易失性内存。
MRAM 控制器负责在 NCP 上与 MRAM 设备进行接口。MRAM 控制器的功能包括对读取、写入、睡眠的控制以及检测多比特错误（MBE）。MRAM 的持续 MBE 错误会成为 AHB 错误，如果 FSW 通过 PCI 访问，将表现为 PCI 目标中止。核心包含一个测试模式，用于注入 MBE，并提供 APB 寄存器以提供状态和错误信息。
Flash 控制器使用 Gaisler 的 NANDFCTRL 核实现，并启用了 EDAC。EDAC 使用 BCH 算法，可在每 60 位数据中纠正 4 位错误。它作为接口，用于存储两次飞行期间收集的原始 NavCam 图像和 LiDAR 起伏图的科学数据。两次飞行后，FSW 将在执行下一次飞行前从 NCP Flash 拉取所需的科学数据。NANDFCTRL 还作为接口，用于访问 Flash 中的三份条纹化 OVP bitstream 副本。这三份条纹化 OVP bitstream 副本相同，并且每 7 帧配置帧包含 CRC。如果任何 CRC 失败，可从另一份条纹副本拉取这 7 帧配置帧。此举是为防止随时间可能发生的任何闪存错误。
SRAM 控制器为 SRAM 提供访问，SRAM 用于 FSW 对 OVP 和 NAND Flash 的访问。FSW 将命令加载到 SRAM 并发送给 OVP，同时也在 SRAM 上接收响应。同样，FSW 通过请求 NCC 将 Flash 中存储的科学数据转存到 SRAM，以检索 NCP Flash 上的存储科学数据。SRAM 已启用 EDAC，以便纠正单个位错误并检测双个位错误（SECDED）。多位 EDAC 错误会呈现给 FSW 为 PCI 目标中止，但由于 SRAM 数据是瞬态的，发生的可能性很低。
AHBFSM
AHBFSM IP 核用于实现若干简单任务，否则需要软件控制。AHBFSM 负责 CRC 检查以及 NCC LEON、OVP bitstream 和 OVP LEON 的图像选择/交接。AHBFSM 通过配置 GRSCRUB 以编程引导控制器所选的 bitstream 图像，从而启动 OVP_FPGA（KU060 设备）的配置。在引导过程中检查该图像时，每当遇到第一个 MRAM MBE，AHBFSM 会指挥 NCC_FPGA 中的 MRAM 控制器进入睡眠状态，然后唤醒相应的 MRAM 设备。它还通过适当配置 GRSCRUB 控制寄存器来启动或禁用 OVP_FPGA 的连续擦除。
FCC
FCC（“Flash Cache Controller”）IP 核通过存储在 NAND Flash 中的 bitstream 图像实现 KU060 的配置和擦除。FCC 包含 8kiB 的内部块 RAM，作为 OVP bitstream 数据的“缓存”。它实现了 2 个 AHB 从属接口：一个供 AHB 主控（如 GRSCRUB）读取配置数据，另一个供写入配置数据。FCC 将 Flash 中的数据存入其内部缓存，并将请求的 AHB 读取映射到这些内部缓冲区中的数据。当 FCC 在任一缓存中都没有所请求的 AHB 读取数据时，它会向 NCC_LEON 触发中断，请求其对包含所请求地址的下一块 bitstream 数据进行缓存填充。
时间记录
NCC 上的时间保持模块用于维护 SCLK（航天器时钟）。
NCC 从 SCIF FPGA 接收两个离散输入引脚，分别为 SCLK 锁存脉冲和
1PPS（每秒一次脉冲）1 2。
SCIF 产生 SCLK
锁存脉冲，使登月器系统能够通过比较各相关终端的系统秒和子秒来评估整个系统的延迟。
时间保持模块在 SCLK 锁存脉冲产生后 20 µs 内锁存完整的 48 位
SCLK，并将锁存的 SCLK 值分别放入 32 位只读寄存器（表示秒）和 16
位只读寄存器（表示子秒），子秒分辨率为 20 µs。
提供一个 32 位寄存器供 FSW 写入 SCLK。该寄存器保存值，以便在下一次
1PPS 时更新 SCLK 值的秒数，并将其写入当前 SCLK 寄存器。
时间保持模块还提供两个只读寄存器（秒寄存器为 32 位，子秒寄存器为 16
位；两者组合存储当前 SCLK 的值），供 FSW 读取当前 SCLK。
NCP 健康
温度传感器接口用于将导航协处理器控制器（NCC）FPGA 与两颗德州仪器 TMP461 温度传感器相连。 每个温度传感器都有远程和本地温度读取。 远程温度使用 FPGA 的二极管，本地温度是物理 TMP461 芯片的温度。 此设计中使用了两种通信协议。 第一种是将接口与 NCC FPGA 连接的 APB 总线。 另一种通信方式是接口使用的 I2C 总线，用于与两颗温度传感器通信。 该模块包含由自动轮询读取温度传感器填充的 APB 寄存器。 自动轮询读取温度传感器上的本地和远程寄存器。 它对这些值的轮询速率通过一个 APB 寄存器设置，该寄存器还更新温度传感器的转换速率寄存器，以防止多次轮询相同的值或以比需要更快的速度转换温度。 还有通过 APB 寄存器的功能，允许用户发送自定义读写命令，结果也会被放入 APB 寄存器。 还有多个计数器，用于查看这些命令是否被温度传感器返回的 NACK/ACK 接受或拒绝。
遥测 ADC 接口包含一个状态机，持续通过 SPI 对两颗 ADC128 设备进行轮询。 遥测 ADC 接口捕获 NCP 上的电压和电流混合，并将其存储到 APB 寄存器中，以供 FSW 捕获和监测 NCP 健康。
PDMA
并行直接存储访问（PDMA）桥提供了一种双向数据传输机制，在 OVP 与 NCC 之间。 PDMA 能够在主 FPGA 上的任意映射 AHB 地址与从 FPGA 上的任意映射 AHB 地址之间执行数据传输。 它通过类似于微处理器系统中用于卸载主微处理器数据传输的 DMA 引擎的机制来实现。 数据传输通过同步、16 位双向并行总线进行，由可由软件访问的描述符寄存器控制。 对于 Dragonfly，OVP 到 NCC 有一对主从配对，NCC 到 OVP 也有一对主从配对。 这两对配置支持由 OVP 或 NCC 启动的内存访问。
第4节：NCC LEON软件
NCC LEON 的主要作用是充当 NCP 上 NAND Flash 存储与 IEM 其余部分（尤其是 OVP FPGA 与 SBC）之间的中介。此角色带来的主要两项功能是从 NavCam 和 LiDAR 存储并检索图像数据，以及存储并擦除次级 OVP bitstream。为实现这些功能，NCC LEON 设计包含三个主要模块：航电软件命令与数据处理器（leon_app）接口、图像存储/槽接口（imgstr）以及 Flash 缓存控制器（FCC）和擦除接口（fccscrub）。FSW C&DH 模块，也称为 leon_app 模块，通过一组映射到 APB 的寄存器（称为 LEON 应用寄存器（LAR））与航电软件交互，FSW 可通过 PCI 总线访问这些寄存器。该模块响应来自 FSW 的命令以及 HDL 核的中断。这些操作由两个低层模块 imgstr 和 fccscrub 处理。这两个低层模块分别在图像数据和 bitstream 级别处理 Flash 操作，并基于 Draco 图像处理管道（DRIP）/DART 的 ssr 和 nandfctl_driver 模块继承而来 3 4。
在部署期间，LEON 有三种不同的工作模式：预飞行（PRE-FLIGHT）、飞行（FLIGHT）和后飞行（POST-FLIGHT）。在预飞行阶段，FSW 负责为飞行中的图像存储配置 LEON。除此之外，如果使用的是次级 OVP bitstream，LEON 还需要在此期间对 OVP 进行配置和擦除。在飞行模式下，NCC LEON 负责以高达 1Hz 的速率保存 NavCam 和 LiDAR 的图像，并可能在剩余 CPU 时间内对 OVP bitstream 进行擦除。最后，在后飞行阶段，LEON 负责处理来自 FSW 的图像检索和坏块管理命令。
第5节：设计与验证方法论
版本控制
设计人员使用 Git 对 FPGA 设计进行版本控制。每位设计人员为其负责的每个模块拥有单独的 Git 仓库。设计人员将对其模块的 Git 仓库提交更改并将更改推送到服务器。每个模块的 Git 仓库包含以下内容：RTL 设计文件、仿真测试平台以及描述设计和测试平台的 README。该 README 使其他负责更高层级集成和顶层仿真的工程师能够快速了解设计，并鼓励在未来项目中复用。为每个模块使用单独的仓库进一步强化了 FPGA 设计的模块化，使每位设计人员清楚自己的模块需要实现哪些功能。设计人员将所需集成的模块提交哈希值提供给 NCC FPGA 负责人。
还包含了嵌入式软核 LEON3FT 软件和验证脚本的仓库。
这些 Git 仓库都是位于名为 NCC FPGA 仓库的顶层仓库中的 Git 子模块。NCC FPGA 仓库在创建新的 NCC 构建时引用了这些子模块的提交哈希。FPGA 负责人提交了 NCC 构建产生的二进制文件，并在顶层仓库添加了 Git 标签以跟踪 NCC FPGA 的发布。顶层仓库还包含约束文件、构建脚本和顶层仿真平台。
构建过程
为了确保可重复性，FPGA 的构建过程被自动化。构建脚本会将 NCC FPGA 仓库的 Git 哈希和构建日期写入寄存器。这样，工程师可以通过读取寄存器来确定板上加载的是哪一个 FPGA 版本。此外，构建脚本还会自动包含一个唯一的硅签名 (SILSIG)，以便在需要时通过 JTAG 线缆编程器唯一识别 FPGA 设计。GRPCI2 的时序很难满足，因此先将 GRPCI2 放置并布线以满足时序。随后将 GRPCI2 设计锁定，并将已放置和布线的 GRPCI2 作为一个块插入到其余 NCC 设计中。
FPGA 负责人将集成来自设计者的最新模块并检查构建日志。 这在 FPGA 发布之前提供了额外的检查。
拥有 Git 哈希还使团队能够轻松比较两个 FPGA 设计的差异，以识别问题。这在新的 FPGA 设计出现问题但该模块的设计者无法解决时特别有用。通过运行 diff，其他设计者可以看到差异并快速解决问题，而不是尝试学习该模块进行调试或等待设计者休假归来。
图 4. NCC FPGA UVM 测试平台环境
验证
每个设计师都负责使用他们选择的语言编写的测试平台来模拟他们的模块，主要使用 VHDL，少数人选择 System Verilog。基于模块的测试平台被设计为自检，以便快速识别仿真是否通过，而无需设计师解释波形。使用代码覆盖率来确保分支和语句在测试平台中被模拟并覆盖。对于需要大量设计工作的模块，还额外使用了 Questa Autocheck（一款完全自动化的形式化错误检测工具，能够发现由于常见 RTL 编码错误导致的错误），作为附加检查。Autocheck 可以发现的错误示例包括未使用的逻辑、未驱动的端口、死锁状态和不可达状态。
在顶层仿真中，团队使用了来自西门子的现代统一验证方法框架（UVMF）来建立一个共同的框架，以测试 NCC 的复杂设计，并在 NCC 设计演进过程中提供灵活性和可扩展性。UVMF 使团队能够快速生成 UVM 仿真平台并采用 UVM。为 PCI 和 Spacewire 购买的 Questa 验证 IP（QVIP）被加入到顶层 UVM 仿真中，以快速生成 PCI 和 Spacewire 事务序列来测试 NCC。所得到的仿真平台环境如图 4 所示。PCI 代理模拟 FSW 并执行 PCI 读写。Spacewire 代理执行 RMAP 读写，以模拟测试平台用户进行的访问。UART 代理负责发送和接收 UART 数据，以模拟 RDE、NavCam 和 LiDAR UART。离散信号代理负责驱动重置和时间保持引脚到 NCC 并监控其值。为每个内部 NCC 模块开发并测试了序列，以与顶层 NCC 设计对照。还开发了类似飞行操作的序列，以验证 NCC 多个部件的协同工作方式。序列由代理的驱动程序执行，结果由代理的监视器接收并验证。在顶层仿真中，团队成员验证了他们未设计的模块，作为第二检查以消除设计者在模块级验证自身模块时的偏见。使用了 MRAM、SRAM 和 Flash 模型。
在实验台上，开发并测试了TCL脚本，以确保设计正常工作并进行回归测试。NCC 在 NavCam 和 LiDAR 仿真器上进行测试，以确保 NCC 正常通信。NCC 还对 RDE 通信仿真进行了测试，以确保功能性。随后，NCC 与 RDE 集成，并确认了指令发送和遥测接收的正常功能。为了确保 NCC 正确擦除 OVP，NCC 团队选择使用名为 FREtZ（通过 JTAG 的 FPGA 可靠性评估）的开源框架，该框架允许通过 JTAG 将配置存储器错误注入 OVP，作为与 NCC 使用的 SelectMap 接口分开的单独接口 5 6。团队关闭了擦除功能，使用 FREtZ 通过 JTAG 注入错误，确认错误已通过 FREtZ 注入，开启擦除功能，然后确认在 OVP 运行时错误已通过 FREtZ 被清除。
第6节 结果
NCC 设计采用最新的 Libero v2024.2 生成，并进行了多次布局与布线，以产生满足所有角落时序要求的 NCC 构建。NCC 的器件利用率如表1所示。
表1.
NCC 主要使用大量 RAM1K18，主要用于 PDMA 接口的缓冲、各类 UART 遥测数据的存储、NAND Flash 数据的缓冲以及 LEON 的 RAM。NCC 上未使用时钟调理电路。
图5和图6分别显示了NCC的最大和最小时序结果。所有时序均满足。图5突出了在PCI的最大时序中仅有0.087ns的裕度所带来的困难。为了解决此问题，PCI首先被布局和布线，并按本文前述方式作为一个模块插入到NCC设计中。
图5. 最大时序
图6显示了在PDMA B的最小时序中仅有0.010ns裕度所带来的困难。为满足最小时序，在物理设计约束中给PDMA B引脚添加了25的输入延迟。
图6. 最小时序
第7节 结论
NCC FPGA 是一项大型片上系统设计，多个设计师参与其中。NCC 设计包含第三方与约翰斯·霍普金斯 APL 开发的模块混合。为确保 FPGA 发行成功，构建过程被自动化，以确保每次构建使用相同的设置。每位设计师负责自己对模块的仿真，并使用代码覆盖率确保模块得到充分仿真。同一位设计师负责在实验台检查设计。通过自动检查来增强对高度定制模块的验证。FPGA 首席工程师负责在集成最新模块时检查构建日志。满足 PCI 的最大时序要求很困难，最终通过首先为 PCI 块寻找最佳布局和布线解决。顶层 UVM 仿真通过使用不同设计师编写的测试再次测试模块，充当额外检查。使用 Git 进行版本控制，使设计师能够通过寄存器中存储的 Git 哈希快速识别板上 FPGA 的版本，并通过比较两个不同 FPGA 版本来找出潜在 bug 的原因。通过这些检查和构建过程，团队能够按时向用户交付 FPGA 构建，并快速、准确地实现新功能请求。