# Titan Bound: The FPGA SoC Design of the Navigation Coprocessor Controller

## Abstract

This paper describes the architecture and verification of the Navigation Coprocessor Controller (NCC) FPGA and its soft processor implemented for NASA's New Frontiers Dragonfly mission to Titan. NCC is a Peripheral Component Interconnect (PCI) target to Flight Software (FSW) and resides on the Navigation Coprocessor Board (NCP). Some of the key functionalities for NCC include sending commands to, and receiving telemetry from, the Rotor Drive Electronics (RDE) on a precise interval., providing an interface to the Onboard Vision Processing (OVP) on FPGA, recording of raw images and Light Detection and Ranging (LiDAR) relief map to NAND Flash, booting of components on the NCP, scrubbing of OVP, and sending commands to the NavCam and LiDAR over universal asynchronous receiver / transmitter (UART). NCC contains an Advanced Microcontroller Bus Architecture (AMBA) that is segmented into two portions connected via an advanced high-performance bus AHB to AHB bridge in order to separate frequent traffic from FSW and OVP. The team used a mixture of traditional and modern verification practices to verify the NCC. Many designers verified their modules individually in the NCC using traditional very high speed integrated circuit (VHSIC) Hardware Description Language (VHDL) testbenches. The top-level simulations used the modern Universal Verification Methodology Framework (UVMF) from Siemens to establish a common framework to test the complex design of the NCC, and to allow both flexibility and scalability as the NCC design evolves.

## Authors

Steven Zhan *Applied Physics Laboratory, The Johns Hopkins University, Laurel*

Matthew Gile *Applied Physics Laboratory, The Johns Hopkins University, Laurel*

Christopher Monaghan *Applied Physics Laboratory, The Johns Hopkins University, Laurel*

Ethan Mellert *Applied Physics Laboratory, The Johns Hopkins University, Laurel*

Owen Pochettino *Applied Physics Laboratory, The Johns Hopkins University, Laurel*

Justin Kelman *Applied Physics Laboratory, The Johns Hopkins University, Laurel*

Ankita George *Applied Physics Laboratory, The Johns Hopkins University, Laurel*

Minh Quan Tran *Applied Physics Laboratory, The Johns Hopkins University, Laurel*

Jeffrey Boye *Applied Physics Laboratory, The Johns Hopkins University, Laurel*

## Publication Information

**Journal:** 2025 IEEE Aerospace Conference **Year:** 2025 **Pages:** 1-10 **DOI:** [10.1109/AERO63441.2025.11068457](https://doi.org/10.1109/AERO63441.2025.11068457) **Article Number:** 11068457 **ISSN:** Electronic ISSN: 2996-2358, Print on Demand(PoD) ISSN: 1095-323X

## Metrics

**Total Downloads:** 18

---

## Keywords

**IEEE Keywords:** VHDL, Laser radar, Navigation, Transmitters, Computer architecture, Very high speed integrated circuits, Timing, Integrated circuit modeling, Field programmable gate arrays, Coprocessors

**Index Terms:** 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

undefined
## SECTION 1. Introduction

NASA's New Frontiers Dragonfly mission to Titan aims to land a rotorcraft on Saturn's moon Titan. During its 3.3-year baseline mission, the rotorcraft will explore diverse locations on the surface to investigate prebiotic chemical processes and whether they are producing chemical building blocks of life.

It will be the first vehicle to fly its entire science payload to various locations on the surface, providing targeted access to surface materials. Dragonfly is managed by Johns Hopkins APL for the NASA Planetary Missions Program Office.

The Navigation Coprocessor Boards (NCP) on the Dragonfly lander are located on the main PCI spacecraft bus with a single initiator, a RAD750 Single Board Computer (SBC). There are two NCP cards per Integrated Electronics Module (IEM) box, referred to as NCP A and NCP B, with one card connected to each separate, redundant PCI bus in the IEM. Each NCP board contains a Microchip RTG4 FPGA (Field Programmable Gate Array) known as the Navigation Coprocessor Controller (NCC) and a Xilinx KU060 FPGA known as the Onboard Vision Processing FPGA (OVP). The two NCP boards are identical including the FPGA designs. Flight software (FSW) on the SBC communicates with NCC, a PCI target-only device, on the spacecraft bus to access the functionalities on the NCP.

The NCC supports FSW accessing the UART interfaces for the RDEs, NavCams, and LiDAR. NCC is designed to send commands to, and receive telemetry from, the RDE UARTs at a precise 10 milliseconds interval to control the rotors. FSW sends NavCam commands to NCC at 1Hz which NCC forwards and stores the response from NavCam in NCC buffers for FSW to read. FSW commands LiDAR through NCC to receive telemetry at 1Hz which NCC stores in its buffers.

The NCC is the only means to access OVP. FSW accesses NCC to command OVP to performs its hardware-accelerated processing needed for the NavCam images and the LiDAR relief maps to be used for navigation. NCC programs the OVP over SelectMap interface and scrubs the configuration memory of OVP to fix any errors that could occur during the rotorcraft flight. NCC also receives the raw NavCam images and LiDAR relief maps from OVP and stores them onto the NAND Flash on NCP which FSW later retrieves post-flight.

NCC is a System on Chip (SoC) design that contains a soft-core LEON processor. The NCC LEON is involved with all data movement of the NAND flash.

NCC interfaces with magnetoresistive random-access memory (MRAM) and static random-access memory (SRAM). MRAM contain a single OVP bitstream and two boot images for each of the soft-core processors of the NCC and OVP. NCC contains logic to choose an uncorrupted boot image for booting each of the processors.

![Figure 1](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/11068190/11068395/11068457/11068457-fig-1-source-large.gif)

*Figure 1. NCP hardware block diagram*

NCC gives FSW the option to choose to program OVP from the OVP bitstreams stored in either MRAM or NAND Flash.

NCC uses SRAM as a temporary buffer for FSW to load data to and receive data from either the OVP or the NAND Flash.

## SECTION 2. Hardware Overview

A block diagram of the Navigation Coprocessor (NCP) board hardware is shown in Figure 1. A rendering of the full hardware assembly is shown in Figure 2. The NCP is an auxiliary computer card within the Avionics Integrated Electronics Module (IEM) that primarily provides the Mobility subsystem computational resources to perform terrain sensing for navigation and control functions outside and in support of the main RAD750 processor (running flight $\text{software} + \text{mobility}$ GNC application). The NCP also provides interfacing to the Rotor Drive Electronics (RDE), Navigation Camera(s) (via the IEM's Redundancy Controller Card / RCC), and LiDAR.

The NCP features two FPGAs. The primary FPGA is a Microchip RTG4 and is referred to as the Navigation Coprocessor Controller (NCC), the focus of this paper. The NCC FPGA is a reprogrammable flash-based device which permits both agile development through flight delivery as well as a self-booting logic fabric, simplifying and increasing the reliability of the hardware design. The auxiliary FPGA is a Xilinx Kintex Ultrascale referred to as the Onboard Vision Processor (OVP). The OVP provides additional logic resources for the Electro-Optical Terrain Sensing (ETS / Navigation Camera Based) and LiDAR Terrain Sensing (LTS / LiDAR based). The OVP is a SRAM based FPGA and must be programmed on boot. The NCC manages the power state, programming, scrubbing and communication to/from the OVP with the IEM Box.

![Figure 2](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/11068190/11068395/11068457/11068457-fig-2-source-large.gif)

*Figure 2. NCP hardware assembly*

![Figure 3](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/11068190/11068395/11068457/11068457-fig-3-source-large.gif)

*Figure 3. Dragonfly NCC FPGA architecture*

The NCC FPGA features a PCI controller and GPIO for box internal communications, LVDS buffers for box external communications, SelectMAP interface for programming and scrubbing the OVP FPGA and a custom inter-FPGA interface for NCC-to-OVP communications. The NCC has direct access to 8 GB of ONFI 2.0 NAND Flash for bulk storage, 16 MB of SRAM (with BCH EDAC) for working memory and 24 MB of MRAM for OVP FPGA and NCC software boot storage.

The OVP FPGA features LVDS buffers for box external interfaces (Navigation Camera and LiDAR). The OVP has direct access to 24 Gbit of DDR3 SDRAM for image storage during ETS processing. The OVP also has two independent banks of Quad Data Rate (QDR) Synchronous SRAM (SSRAM) to support the high throughput requirements of ETS (2D-FFT / Phase Correlation) and LTS processing. The throughput and random-access requirements of the ETS and LTS pipelines forced the use of a fast SRAM (with flat/deterministic random-access times) as opposed to SDRAM (which has variable, and sometimes quite large delays depending on access patterns).

The NCP supports a range of power states to accommodate various mission scenarios ranging from a “sleep mode” (All core rails powered down, < 0.5 W), “surface mode” (NCC Power domains on, OVP power domains off, ~2.5W), to “surface flight mode” (NCC and OVP power domains on, ETS & LTS pipelines operational, ~25 W). To accommodate the thermal dissipation of the higher power modes, the NCP incorporates a robust copper heat sink and fixtures for a direct thermal attachment to the IEM box chassis and spacecraft deck. The full assembly (board, frame, heat sink) weighs 1 kg. The board adheres to a 6U cPCI form factor $-6.299^{\prime\prime} \times 9.187^{\prime\prime}$. The board consists of a 24-layer polyimide construction using blind and through vias with a finished thickness of $0.116^{\prime\prime} +/-0.012^{\prime\prime}$.

## SECTION 3. FPGA Architecture

The architecture for the Dragonfly NCC FPGA is shown in Figure 3. The dotted line represents the NCC FPGA; all blocks outside the dotted line are external to the NCC FPGA. Each block of the NCC FPGA represents an IP core. The blocks labeled “APL” include modules designed by engineers at Johns Hopkins APL. The blocks labeled “Gaisler” indicate that those cores were purchased from a third-party IP provider. The amount of plus signs indicate the amount of modifications done to the Gaisler IP cores. The modifications were to deal with interfacing to the particularities of external peripherals or adding additional debug info in registers for FSW.

### Clocks and Resets

The NCC FPGA receives the main 30 MHz clock from the local board oscillator and is used throughout the FPGA as the clock for the AMBA bus. No phase locked loop (PLL) is used in the design to avoid any loss of lock that could result in causing FSW to experience a software exception with NCC disappearing from the PCI bus.

The module also provides the ability for flight software to command a NCC reset which is tracked in a reset cause register. There are also registers to specifically reset the LEON3FT and the OVP.

### Bus Architecture

The NCC FPGA's internal bus architecture is an AMBA network, divided into two AHB buses connected by an AHB-AHB bridge. The AHB-AHB bridge is unidirectional because NCC, as a PCI-target, can only respond to transactions initiated by FSW and also avoids potential deadlock problems that could occur with a bidirectional bus. Each of the AHB buses contain an APB as shown in Figure 3. The APB buses provide accesses to the registers for those modules. Both AHB buses, referred to as AHB0 and AHB1, are configured to operate in a round robin fashion.

The AHB1 bus is primarily mastered by Flight Software, which is running on the RAD750, over the PCI-AHB Bridge (GRPCI2 in Figure 3). The other two significant bus masters on AHB1 are Spacewire AHB Bridge (GRSPW2) and the AHB JTAG. These two AHB masters are for debugging by allowing users to gain access to NCC other than PCI by using remote memory access protocol (RMAP) commands over SPW or GRMON over JTAG. The two AHB masters can also access debug modules not accessible over PCI. The RDE UARTs which are frequently accessed by FSW are also placed on the same AHB1 bus to optimize bus traffic. FSW accesses the modules on AHB0 at a less frequent rate of lHz by going across the AHB-AHB bridge.

The AHB0 bus is most frequently mastered by the LEON3FT soft processor and the scrubber during rotorcraft flight. The soft processor uses the bus for instruction and data fetches to and from application memory and to store NavCam images and LiDAR relief map into NAND Flash. The scrubber is performing blind scrubbing of OVP at a designated rate specified by FSW. The scrubber periodically reads configuration frames of OVP bitstream stored in either MRAM or NAND Flash and overwrites them on the OVP. Having the LEON3FT and the scrubber on a separate AHB bus from the RDE UARTs optimizes the bus traffic.

### PCI Interface

The PCI interface is the link between the NCP and the spacecraft bus. This link serves as the sole conduit by which Flight Software can access the NCC. The PCI Interface is implemented using the GRPCI2 core from Gaisler. The PCI Interface implements a 32-bit PCI Target compatible with the 2.3 PCI Local Bus Specification.

The connections to the AMBA bus are an AHB master interface for the PCI target functionality and an AMBA APB slave interface for access to the configuration registers in the core. The PCI and AMBA interfaces belong to two different clock domains, 33.3 MHz and 30 MHz, respectively. Synchronization between these domains is performed inside the core using dual-clock FIFOs.

Access to the NCC FPGA's AMBA bus via the bridge is accomplished by accessing one of five base address registers (BARs). All of NCC's memory and registers can be accessed over PCI except debug modules such as the debug support unit (DSU) on the AHB0 bus. Prefetch was enabled for all of the BARs.

The fifth BAR contains all of readable registers on the NCC. These readable registers also exist in other BARs but are mirrored and placed consecutively to improve FSW's execution of PCI reads by allowing a large PCI burst read.

### NCC LEON

The LEON3FT boots at the start of AHBROM, a PROM containing the boot code, and a jump to application memory where the image is stored. The FTAHBRAM, also known as the LEON application memory, is where application code is executed from, and is protected by scrubbing and EDAC for fault tolerance. The IRQ controller handles the LEON's allotted interrupts sourced from the AMBA bus, and the General Purpose Timers are available for use by the processor. The design also includes APBUART and JTAG controllers, which provide console and GRMON access for processor debugging and user interaction.

### RDE UARTs

The NCC FPGA's RDE Command and Telemetry UARTs (referred to as RDE UARTs) interface with the Rotor Drive Electronics FPGA. There are four UARTs, each with identical architecture and independent memory maps.

The Tx (commanding) side of the UARTs receive 24-byte RDE commands over an AHB interface, copy the commands into a buffer for transmission, and transmit the bytes in order over the UART interface every 10 ms.

The Rx (telemetry) side of the UARTs receive RDE telemetry. The received telemetry is staged in a dual-port RAM and accessible by flight software (FSW) via AHB interface. The Rx uses a ping-pong approach, so while FSW is reading telemetry from one buffer, NCC is writing the new telemetry to the other buffer. The NCC word-aligns the high priority telemetry based on data fields to remove FSW's burden of unpacking the bytes into data fields.

### NavCam and LiDAR UARTs

The NavCam and LiDAR UARTs are used to connect the NavCam and LiDAR. The design uses an AMBA interface to connect the design with the NCC FPGA. The APB registers can be used to change UART operating configuration or to view status counters such as the number of bytes received. The AHB bus is used to send and receive data into a memory-mapped command or telemetry ram buffer. The control logic will shuttle the data between these buffers and the Tx and Rx UARTs which are used to communicate with the NavCam and LiDAR. NCC handles the HDLC (high-level data link control) encoding and decoding required by LiDAR, so that FSW does not need to be concerned with encoding or decoding the packet.

### Memory Interfaces

There are three different types of memories local to the NCP which are controlled by the NCC. The MRAM and Flash devices serve as the primary non-volatile memory for boot images and science data, while the SRAM serves as volatile memory for transient commands and telemetry.

The MRAM Controller is responsible for interfacing the MRAM device on the NCP. MRAM controller features include control of read, write, sleep, and detecting multibit-errors (MBEs). A persistent MBE error from MRAM becomes an AHB error which appears as a PCI target abort if being accessed by FSW over PCI. The core includes a test mode to inject MBEs and provides APB registers to provide status and error information.

The Flash controller is implemented using Gaisler's NANDFCTRL core with EDAC enabled. The EDAC uses a BCH algorithm that can correct 4 bits per 60 bits of data. It serves as the interface to store collected science data of raw NavCam images and LiDAR relief map for two flights. After 2 flights, FSW will pull the desired science data from the NCP Flash before performing the next flight. NANDFCTRL also serves as the interface to access three striped copies of the OVP bitstream in flash. The three striped copies of the OVP bitstreams are identical, and CRCs are included every 7 configuration frames. If any of the CRC fails, the 7 configuration frames can be pulled from another striped copy. This was done to guard against any flash errors that could occur especially over time.

The SRAM controller provides access to the SRAM, which is used for FSW accesses to OVP and NAND Flash. FSW loads commands to send to OVP on SRAM and also receives the response back on SRAM. Similarly, FSW retrieves stored science data on NCP Flash by asking NCC to dump the science data from Flash to SRAM. SRAM has EDAC enabled, so that it can correct one bit and detect two bit errors (SECDED). A multi-bit EDAC error would present to FSW as a PCI target abort but is unlikely to happen as the SRAM data is transient.

### AHBFSM

The AHBFSM IP core is used to implement several simple tasks that would otherwise require software control. The AHBFSM handles the CRC checking and image selection/handoff for the NCC LEON, OVP bitstream and OVP LEON. The AHBFSM initiates configuration of the OVP_FPGA (KU060 device) by configuring GRSCRUB to program the bitstream image selected by the boot controller. Whenever the 1st MRAM MBE is encountered while checking that image during the boot process, AHBFSM commands the MRAM controller in NCC_FPGA to sleep and then wake the appropriate MRAM devices. It also initiates or disables continuous scrubbing of the OVP_FPGA by configuring the GRSCRUB control registers appropriately.

### FCC

The FCC or “Flash Cache Controller” IP core enables KU060 configuration and scrubbing using a bitstream image stored in NAND flash. FCC contains 8kiB of internal block RAM that it uses as “caches” for OVP bitstream data. It implements 2 AHB slave interfaces: 1 which AHB masters, such as GRSCRUB, can read configuration data from and another which can be used to write configuration data to. FCC stores data from flash in its internal caches and maps the requested AHB reads to data in these internal buffers. Whenever FCC does not have the requested data for an AHB read in either cache, it raises an interrupt to the NCC_LEON to request that it perform a cache fill of the next block of bitstream data that contains the requested address.

### Timekeeping

The Timekeeping Module on the NCC is used to maintain SCLK (Spacecraft clock). The NCC receives two input discrete pins named SCLK latched pulse and 1PPS (1 pulse per second) from the SCIF FPGA [^1] [^2]. SCIF asserts the SCLK latch pulse to allow the lander system to assess latency throughout the system by comparing system seconds and sub-seconds in the various endpoints of interest.

The Timekeeping Module latches full 48 bit SCLK within 20 µs of the assertion of SCLK latch pulse and make the latched SCLK value available in a 32 bit read-only register that represents seconds and a 16-bit read-only register that represents subseconds at 20µs resolution. A 32 bit register is provided for FSW to write the SCLK. Register holds the value to update the seconds of the SCLK value upon next 1PPS and puts it into current SCLK register. The Timekeeping Module also provides two read-only registers (the seconds register is 32 bits, and the subseconds register is 16 bits; both registers combined holds the value of the current SCLK) for FSW to read the current SCLK value.

### NCP Health

The Temperature Sensor Interface is used to connect the Navigation Co-Processor Controller (NCC) FPGA with two Texas Instruments TMP461 temperature sensors. Each temperature sensor has a remote and local temperature reading. The remote temperature uses diodes from the FPGA, and the local temperature is the temperature at the physical TMP461 chip. There are two communication protocols used in this design. The first is an APB bus which connects the interface with the NCC FPGA. The other form of communication is an I2C bus which the interface uses to talk to the two temperature sensors. The module contains APB registers populated by automated polling reads from the temperature sensor. The automatic polling reads the local and remote registers on the temperature sensor. The rate it polls these values are set through an APB register which also updates the temperature sensors conversion rate register as to prevent polling the same value multiple times or converting temperatures faster than needed. There is also functionality through APB registers for a user to send custom read and write commands which result will also be put in an APB register. There are multiple counters to see if these commands were accepted or rejected using the NACK/ACK returned from the temperature sensor.

The Telemetry ADC interface contains a state machine that continuously polls the two ADC128 devices over SPI. The Telemetry ADC interface captures a mixture of voltages and currents on the NCP and stores them into APB registers for FSW to capture and monitor NCP health.

### PDMA

The Parallel Direct Memory Access (PDMA) bridge provides a bi-directional data transfer mechanism between the OVP and NCC. PDMA is able to perform data transfers between any memory-mapped AHB address on the host FPGA to or from any memory-mapped AHB address on the client FPGA. It does this through a mechanism akin to the DMA engines used on microprocessor systems to offload data transfers from the main microprocessor. Data transfers occur over a synchronous, 16-bit bi-directional parallel bus, controlled by descriptor registers accessible by software. For Dragonfly, there is one host-client pair from OVP to NCC, and one host-client pair from NCC to OVP. The two pair configuration supports memory access initiated by either the OVP or NCC.

## SECTION 4. NCC LEON Software

The main purpose of the NCC LEON is to act as an intermediary between the NAND Flash storage on the NCP and the rest of the IEM, specifically the OVP FPGA and the SBC. The main two functionalities that come out of this role are the storage and retrieval of image data from the NavCam and LiDAR, as well as the storage and scrubbing of the secondary OVP bitstream. In order to implement these features, the NCC LEON design has three main modules, the Flight Software Command and Data Handler (leon_app) interface, the Image Storage/Slot Interface (imgstr), and the Flash Cache Controller (FCC) and Scrubbing Interface (fccscrub). The FSW C&DH module, also referred to as the leon_app module, interacts with Flight Software via a set of APB mapped registers called the LEON Application Registers (LAR), which are accessible to FSW over the PCI bus. This module responds to commands issued from FSW as well as interrupts from HDL cores. These operations are handled by the two lower-level modules, imgstr and fccscrub. Both of these lower-level modules handle the flash operations at the image data and bitstream level, and are built upon the ssr and nandfctl_driver modules that are heritage from Draco Image Processing Pipeline (DRIP)/DART [^3] [^4].

While deployed, the LEON has three distinct operational modes, PRE-FLIGHT, FLIGHT, and POST-FLIGHT. During PRE-FLIGHT, FSW is responsible for configuring the LEON for image storage during flight. In addition, if the secondary copy of the OVP bitstream is being used, the LEON will also need to configure and scrub the OVP during this time. During the FLIGHT mode, the NCC LEON is responsible for saving both NavCam and LiDAR images at a rate of up to 1Hz, and potentially scrubbing the OVP bitstream with all remaining CPU time. Finally, during POST-FLIGHT the LEON is responsible for handling commands from FSW for image retrieval and bad block management.

## SECTION 5. Design and Verification Methodology

### Version Control

The designers used Git to version control the FPGA design. Each designer had a separate Git repository for each of the modules he/she was responsible for. The designer committed changes to the Git repository of his/her module and pushed the changes to the server. The Git repository for each module contained the following: the RTL design files, the testbench, and a README that described the design and testbench. The README allowed the other engineers working on higher level integration and top-level simulation to quickly grasp the design while also encouraging re-use for future projects. Having separate repositories for each module further enforced the modularization of the FPGA design, so that each designer was clear what should be implemented in his/her module. The designer would provide the NCC FPGA lead the commit hash of the module to use to integrate with the rest of the NCC FPGA design.

Also included were repositories for the embedded soft-core LEON3FT software and verification scripts.

Each of these Git repositories were Git submodules under the top repo known as the NCC FPGA repo. The NCC FPGA repo referenced the commit hashes of the Git submodules in creating a new NCC build. The FPGA lead committed the produced binaries for the NCC build and added a Git tag to keep track of the NCC FPGA releases in the top repo. The top repo additionally contained the constraints, build scripts, and top level testbench.

### Build Process

To ensure repeatability, the FPGA build was automated. The build scripts place the Git hash and the build date of the NCC FPGA repo in registers. This allows the engineers to determine which FPGA version is loaded on the board by reading the registers. Additionally, the build scripts also automatically include a unique silicon signature (SILSIG), so that the FPGA design can be uniquely identified through a JTAG cable programmer if needed. The GRPCI2 proved to be difficult to meet timing, so the GRPCI2 was first placed and routed to meet timing. The GRPCI2 design was then locked, and the build script inserted the placed and routed GRPCI2 as a block into the rest of the NCC design.

The FPGA lead would integrate the latest modules from the designers and check the build logs. This served as an additional check prior to a FPGA release.

Having the Git hashes also allowed the team to run a diff between two FPGA designs easily to identify the issue. This proved useful when a new FPGA design had issues, but the designer of that module was unavailable to address it. By running a diff, other designers were able to see the difference and quickly resolve the issue rather than trying to learn the module to debug or wait for the designer to return from vacation.

![Figure 4](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/11068190/11068395/11068457/11068457-fig-4-source-large.gif)

*Figure 4. NCC FPGA UVM testbench environment*

### Verification

Each of the designers were responsible for simulating their modules using testbenches written in the language of their choice that predominately was VHDL with a few choosing System Verilog. The module-based testbenches were designed to be self-checking, so that the results of the simulation can quickly identify if the simulation passed or failed instead of requiring the designer to interpret the waveforms. Code coverage was employed to ensure that the branches and statements were simulated and covered in the testbench. For modules that required a large degree of design effort, Questa Autocheck (a fully-automatic formal bug hunting app that finds bugs due to common RTL coding errors) was done as an additional check. Examples of bugs Autocheck could discover are unused logic, undriven ports, deadlock states, and unreachable states.

For the top-level simulation, the team used the modern Universal Verification Methodology Framework (UVMF) from Siemens to establish a common framework to test the complex design of the NCC, and to allow both flexibility and scalability as the NCC design evolves. The UVMF allowed the team to quickly generate a UVM testbench and adopt the use of UVM. Purchased Questa Verification IP (QVIP) for PCI and Spacewire were added into the top level UVM simulation to quickly generate sequences of PCI and Spacewire transactions to test the NCC. The resulting testbench environment is shown in Figure 4. The PCI agent mimicked FSW and performed PCI reads and writes. The Spacewire agent performed RMAP reads and writes to mimic accesses performed by a testbed user. The UART agents dealt with transmitting and receiving UART data to mimic the RDE, NavCam, and LiDAR UARTs. The discrete signals agent dealt with driving resets and timekeeping pins to the NCC and monitoring the values. Sequences for each of the internal NCC modules were developed and tested against the top level NCC design. Sequences to resemble flight-like operations were also developed to verify how multiple parts of the NCC works conjunctionally. The sequences are executed by the driver of the agents with the results received by the monitor of the agents and verified. On the top level simulation, the team members verified modules they didn't design as a second check to remove any bias when the designers verified their own modules on the module-level. MRAM, SRAM, and Flash models were used.

On the bench, TCL scripts were developed and tested against the design to ensure design is working and for regression testing. NCC tested against the emulators for the NavCam and LiDAR to ensure NCC was communicating properly. NCC also tested against RDE telemetry emulation to ensure functionality. The NCC later integrated with the RDE and confirmed proper functionality of commanding and receiving telemetry. To ensure NCC was correctly scrubbing OVP, the NCC team chose to use the open-source framework called FREtZ (FPGA Reliability Evaluation through JTAG) that allowed injection of configuration memory errors on OVP thru JTAG as a separate interface from the SelectMap interface that NCC uses [^5] [^6]. The team turned off scrubbing, injected errors through FREtZ over JTAG, confirmed errors were injected over FREtZ, turned on scrubbing, and then confirmed errors were removed through FREtZ while the OVP is running.

## SECTION 6. Results

The NCC design was produced in the latest Libero v2024.2 and required several place and routes to produce a NCC build that meets timing in all corners. The device utilization of the NCC is shown in Table 1.

![Figure 5](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/11068190/11068395/11068457/11068457-table-1-source-large.gif)

*Table 1.*

The NCC used a high amount of RAM1K18 primarily for buffering of the PDMA interface, storage of the various UART telemetry, buffering of the NAND Flash data, and RAM for the LEON. No clock conditioning circuits were used on the NCC.

Figure 5 and Figure 6 show the max and min timing results of the NCC respectively. All timing was met. Figure 5 highlights the difficulty of meeting max timing for the PCI with a slack of barely 0.087ns. To resolve this, the PCI was placed and routed first and inserted as a block into the NCC design as mentioned earlier in the paper.

![Figure 6](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/11068190/11068395/11068457/11068457-fig-5-source-large.gif)

*Figure 5. Max timing*

Figure 6 shows the difficulty of meeting min timing for the PDMA B with a slack of 0.010ns. An input delay value of 25 was added to the PDMA B pins inside the physical design constraint to meet the min timing.

![Figure 7](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/11068190/11068395/11068457/11068457-fig-6-source-large.gif)

*Figure 6. Min timing*

## SECTION 7. Conclusions

The NCC FPGA was a large system on chip design that had multiple designers working on it. The NCC design contains a mixture of third party and Johns Hopkins APL developed modules. To ensure successful FPGA releases, the build was automated to ensure the same settings were applied for each build. Each designer was responsible with his/her simulation of the module and used code coverage to ensure the module was adequately simulated. The same designer was responsible for checking the design at the bench. Autocheck was done to enhance verification for highly custom modules. The FPGA lead engineer was responsible for checking the build logs while integrating the latest modules. Meeting max timing for PCI was difficult and was resolved by finding an optimal place and route for the PCI block first. The top level UVM simulation served as an additional check by testing the modules again with tests written by a different designer. Using Git as version control allowed designers to quickly identify the FPGA version on the board through Git hashes stored in registers and identify what may have caused a potential bug by comparing two different FPGA versions. From these checks and build process, the team was able to successfully deliver FPGA builds to users on time and implement new features requests quickly and correctly.

## References

[^1]: A. Mizes, M. Griffith and M. Hoffmann, “A Spacecraft Interface Card with Flexible Architecture for Multi-Mission Applications,” 2024 IEEE Aerospace Conference, Big Sky, MT, USA, 2024, pp. 1–8, doi: 10.1109/AERO58975.2024.10521062. [IEEE](https://ieeexplore.ieee.org/document/10521062) [Google Scholar](https://scholar.google.com/scholar?as_q=A+Spacecraft+Interface+Card+with+Flexible+Architecture+for+Multi-Mission+Applications&as_occt=title&hl=en&as_sdt=0%2C31)

[^2]: M. Hoffmann and M. Griffith, “FPGA and Embedded Software Implementation for Dragonfly Spacecraft Interface Card,” 2024 IEEE Aerospace Conference, Big Sky, MT, USA, 2024, pp. 1–10, doi: 10.1109/AERO58975.2024.10521102. [IEEE](https://ieeexplore.ieee.org/document/10521102) [Google Scholar](https://scholar.google.com/scholar?as_q=FPGA+and+Embedded+Software+Implementation+for+Dragonfly+Spacecraft+Interface+Card&as_occt=title&hl=en&as_sdt=0%2C31)

[^3]: S. Zhan et al., “The Design and Verification of the DART Single Board Computer FPGA,” 2021 IEEE Aerospace Conference (50100), Big Sky, MT, USA, 2021, pp. 1–11, doi: 10.1109/AERO50100.2021.9438523. [IEEE](https://ieeexplore.ieee.org/document/9438523) [Google Scholar](https://scholar.google.com/scholar?as_q=The+Design+and+Verification+of+the+DART+Single+Board+Computer+FPGA&as_occt=title&hl=en&as_sdt=0%2C31)

[^4]: D. Bekker, R. Smith and M. Q. Tran, “Guiding DART to Impact - the FPGA SoC Design of the DRACO Image Processing Pipeline,” 2021 IEEE Space Computing Conference (SCC), Laurel, MD, USA, 2021, pp. 122–133, doi: 10.1109/SCC49971.2021.00020. [IEEE](https://ieeexplore.ieee.org/document/9546293) [Google Scholar](https://scholar.google.com/scholar?as_q=Guiding+DART+to+Impact+-+the+FPGA+SoC+Design+of+the+DRACO+Image+Processing+Pipeline&as_occt=title&hl=en&as_sdt=0%2C31)

[^5]: A. Sari, V. Vlagkoulis and M. Psarakis, “An open-source framework for Xilinx FPGA reliability evaluation ”, Proc. Workshop Open Source Design Autom. (OSDA), pp. 1–6, Mar. 2019. [Google Scholar](https://scholar.google.com/scholar?as_q=An+open-source+framework+for+Xilinx+FPGA+reliability+evaluation&as_occt=title&hl=en&as_sdt=0%2C31)

[^6]: https://github.com/unipieslab/FREtZ.

### Additional References