Building a secure FPGA architecture: Deterministic, reliable, and resilient FPGA design

Objective

This Lab Note explains how to design FPGA architectures that behave securely and predictably. The goal is to show what matters both at power-up and during long-term operation. We highlight the practical techniques that make a real difference in the field, including secure configuration, disciplined clocking and reset, safe RTL structures, robust I/O behavior, and radiation-aware design.

The aim is simple. By the end, you will have a clear set of principles that help you design FPGA systems that are deterministic, reliable, and resilient in real-world environments.

Context

FPGAs sit at the core of many mission-critical systems, from secure communications to spacecraft control. Their flexibility is a strength, but it also opens the door to more ways things can go wrong. Threats come from adversaries who want to read messages or infer behavior, from weak engineering practice, and from the environment, including atmospheric neutrons and radiation-induced faults.

Secure FPGA architectures address these risks by ensuring confidentiality, integrity, and availability while avoiding common pitfalls such as unsafe startup behavior, poor clock domain crossing (CDC), weak configuration protection, or misunderstanding the operational environment. The techniques looked at here are typically used in aerospace, defense, secure communications, and any system where reliability and security are inseparable.

Real-world failures often come from simpler causes. Weak random number generation, unsafe startup behavior or over-complex designs can undermine an otherwise strong system. These issues appear more often than sophisticated attacks, so the engineering discipline behind the design is just as important as the security features themselves.

Overview

A secure FPGA architecture is built from several interacting subsystems that work together to ensure the device behaves predictably and resists both intentional and unintentional faults. The process begins with understanding the threat model, including confidentiality, integrity, availability, traffic-flow analysis, replay attacks, radiated emissions, and key compromise. With this in mind, the appropriate device technology like SRAM, Flash, or OTP can be selected based on performance, updateability, and how susceptible it is to configuration corruption.

Configuration security then ensures that only authorized bitstreams configure the device and that configuration memory remains intact. Clocking and reset architecture provide deterministic startup and safe synchronization of asynchronous inputs, for example. Code quality and safe synthesis practices prevent structural hazards such as latches, gated clocks, mismatched ranges, and unsafe state machines. I/O handling ensures that pins behave safely during power-up and reset, avoiding contention and glitch-induced behavior. Finally, radiation-aware design mitigates single-event effects such as SEU, SET, MBU, and SEFI, which can corrupt registers, memories, or even configuration frames.

In many secure systems, anti-tamper mechanisms and transmission-security considerations are also required. These include detecting enclosure tampering, monitoring supply anomalies, and ensuring that signaling patterns or radiated emissions do not reveal operational intent. While implementation varies by mission, these measures complement configuration security and architectural hardening.

Together, these elements form a reliable and systematic workflow that moves from threat analysis to device selection, secure configuration, deterministic clocking and reset, safe RTL, hardened I/O, radiation mitigation, and verification.

Requirements

The following tools are required to support a controlled, repeatable, and secure FPGA development flow:

• Requirements capture tool for documenting, tracking, and verifying requirements throughout the lifecycle.
• Editors with the ability to LINT and check structural issues, e.g., HDL Creator.
• Synthesis tools to generate the netlist, either third-party or vendor-supplied.
• Implementation tools, generally vendor-supplied.
• Simulation tools, either third-party or vendor-supplied.
• Source control such as Subversion or Git.
• Configuration control often called Product lifecycle management (PLM).
• Specialist tools for tasks like fault injection.

Certified tool chains

When formal assurance or regulatory compliance is required, the design flow must use a certified tool chain or apply additional verification to compensate for uncertified tools. IEC 61508, for example, is the international standard for the functional safety of electrical, electronic and programmable electronic systems. Under the standard, tools are classified according to the risk they introduce into development cycle:

• T1 tools are those like text editors of document management systems that cannot insert or hide errors in the software.
• T2 tools such as static analysis tools or test coverage analyzers are those that cannot introduce errors into the code but can fail to detect existing errors.
• T3 tools like compilers or code generators carry the highest risk because they can introduce errors into the code if faulty. They are subject to the most stringent certification.

Key concepts

Non-obvious threats

Secure FPGA systems must consider more than confidentiality, integrity, and availability. Adversaries can exploit indirect behaviors like traffic-flow patterns, timing changes, or predictable command sequences. Replay attacks can occur if commands are not bound to a session, timestamp, or number used once. Transmission-security considerations may also apply, including the detectability of signaling and the risk of revealing operational intent through activity patterns. These threats shape architectural decisions and must be understood early in the design process.

Deterministic startup

A secure FPGA architecture begins with deterministic startup. The oscillator startup time must be considered during design analysis to ensure the system does not begin operating before the clock is stable. Resets should assert asynchronously to guarantee immediate entry into a safe state, and de-assert synchronously to avoid metastability. Designs should not rely on the default value of the device output during power-up because the I/O pins are in an undefined state.

Clock-presence detection

Deterministic startup depends on the system operating only when clocks are present and stable. In addition to internal clock monitors, simple board-level techniques can provide basic clock loss detection, such as using a tristate buffer and capacitor to sense periodic transitions. When the clock stops, the capacitor discharges and the sense line falls, indicating loss of activity. The use of Schmitt-trigger inputs here improves noise immunity by providing a lightweight, device-agnostic method for detecting clock failure.

Reset-generation hazards

Board-level reset generation can introduce hazards if not carefully controlled. RC networks may produce slow-rising edges that violate logic thresholds unless buffered with a Schmitt trigger. Reset assertion must exceed oscillator startup time, and reset release must be clean and monotonic to avoid partial de-assertion. Importantly, systems should not rely on FPGA-driven signals to indicate power-good or readiness, as this can create circular dependencies during startup. Robust reset behavior is also essential for predictable system entry into a known state.

Clock domain crossing

Safe CDC is another foundational concept. Modern systems often use multiple clocks for ADCs, DACs, source-synchronous interfaces or internal processing, and signals must be transferred safely between them. Techniques include Gray code counters for monotonic multi-bit values, two-stage synchronizers for single-bit signals, handshake synchronizers for control transfers, and asynchronous FIFOs for high-throughput data. CDC structures should use device-appropriate primitives or hardened synchronizer cells when available, along with static CDC analysis tools to detect issues that may not appear in simulation.

Configuration security

Configuration security ensures only authorized bitstreams configure a device and that configuration memory remains intact. SRAM-based FPGAs require particular attention because their configuration is loaded at power-up and can be vulnerable to corruption by radiation or malicious interference. Authentication, encryption, and scrubbing are therefore critical. Flash and OTP devices offer stronger inherent protection, with OTP being ideal for fixed, security-critical functions such as cryptographic modules.

Entropy and random number generation

Many security mechanisms rely on high-quality randomness, including authentication, challenge-response, and key generation. FPGA designs should use robust hardware entropy sources such as jitter-based or metastability-based generators, and ensure outputs are continuously monitored for bias or degradation. Weak or predictable entropy can undermine strong security measures, so RNG behavior must be treated as a core security primitive.

RTL structural safety

RTL structural safety is equally important. Coding standards help prevent hazards such as latches, gated clocks, multiple drivers, incomplete sensitivity lists, and unsafe state machines. The use of enumerated types, consistent vector ordering, and avoidance of hard-coded values improves clarity and reduces synthesis mismatches. Safe state-machine encoding, such as Hamming-3, can help prevent SEU-induced lockup.

I/O hardening

I/O hardening ensures pins behave safely during startup and reset. Unused pins should be left unconnected on the board but driven low internally. JTAG pins require pull-downs, and pins such as PLL inputs must follow datasheet guidance. Bus contention should also be avoided during reset, while glitch filtering can protect against accidental transients.

Radiation effects

Radiation effects are a major concern in high-altitude and space environments, where atmospheric neutrons and trapped particles can trigger SEU, SET, MBU and SEFI. An SEU flips stored bits in registers or memory, while an SET creates a transient pulse in combinational logic that may be captured by downstream registers. MBUs occur when a single strike disturbs several adjacent bits, and SEFIs can disrupt device -level functionality to the point that reconfiguration is often required. Mitigation typically combines TMR, ECC or EDAC, configuration scrubbing, derated timing constraints and a clear understanding of which fault mechanism is likely to dominate in the target environment.

Design trade-offs

Secure FPGA architecture requires balancing performance, updateability, power, and reliability, based on the device under development. SRAM devices, for example, offer high performance and capacity but require secure configuration and are susceptible to configuration corruption. Flash devices provide non-volatile storage and field updateability with lower risk of corruption, while OTP devices offer the strongest security but cannot be modified once programmed.

Redundancy techniques such as TMR improve resilience to SEU, although they increase area and power consumption, so they must be applied selectively when resources are tight. Isolation flows introduce placement constraints yet prevent unintended interactions between red and black domains. Additional synchronizer stages increase latency while reducing metastability risk. Glitch filters add delay while protecting against false triggering. Designers must also consider the operational environment, since systems operating at altitude or in space require more aggressive mitigation than terrestrial deployments.

Implementation

Implementing a secure FPGA architecture follows the same steps as any FPGA build process. By including a security mindset from the beginning, it makes it a natural part of the workflow rather than an unwelcome checkpoint at the end.

During implementation, each architectural requirement is translated into concrete design steps that ensure predictable and secure behavior. The process begins by selecting the appropriate device technology, for example, which will guide many of the decisions that follow. The succeeding steps then ensure a robust security posture from secure configuration and deterministic startup, to applying radiation-mitigation techniques if required, and documenting and verifying module-level behavior.

By the end of the implementation process, each module should behave predictably and be supported by evidence that the system meets its security and reliability objectives.

Select the FPGA technology

Device selection is a foundational security decision. SRAM, Flash, and OTP devices each offer different tradeoffs in performance, updateability, and susceptibility to configuration corruption. The choice must reflect the threat model and mission requirements.

• Evaluate whether the design requires high performance (SRAM), field updateability (Flash) or immutability (OTP).
• Assess susceptibility to configuration corruption and whether mitigation (e.g., scrubbing) is required.
• Determine whether the device must be live at power-up or can tolerate configuration loading time.
• Consider power constraints – Flash and OTP devices typically consume less power.
• Align device selection with typical use cases – crypto modules often favor OTP, for example, while SDR and image processing favor SRAM.

Implement secure configuration

Secure configuration ensures that only authorized bitstreams are loaded, and that configuration memory remains intact, and is essential for both security and reliability.

• Enable bitstream authentication to prevent unauthorized configuration.
• Enable bitstream encryption to protect confidentiality.
• Lock or disable JTAG in deployed systems and apply pull-downs to TDI, TMS, and TCK.
• Where antitamper requirements apply, define how tamper events are detected and how sensitive material is zeroized.
• Implement configuration scrubbing for SRAM devices to correct SEU-induced corruption.
• Apply red/black separation in the floorplan using isolation flows where available.
• Ensure that configuration security aligns with Kerckhoffs’ principle, remembering the algorithm must not be secret, only the key.
• Specify how random numbers are generated for authentication, challengeresponse or key generation, and define any required health checks for entropy sources.

Architect clock and reset behavior

It’s important to note here that deterministic startup is essential for secure and reliable operation, and the incorrect handling of clocks and resets can leave the system in undefined states.

• Verify oscillator startup time and ensure reset assertion exceeds this duration.
• Implement asynchronous reset assertion to guarantee immediate entry into a safe state.
• Implement synchronous reset de-assertion to avoid metastability.
• Avoid gated clocks and internally generated clocks, and use dedicated global clock resources instead.
• Clock monitors have detection limits, and glitches typically shorter than one period of the reference clock cannot be detected. They should therefore be treated as advisory rather than absolute indicators of clock health.
• Define how clock presence is monitored, whether through internal monitors, boardlevel detection or both.
• Specify the resetgeneration method (e.g., supervisor IC, RC network with Schmitt trigger) and ensure reset edges and timing meet deterministic startup requirements.
• Ensure powerintegrity measures such as filtering and decoupling support stable clock behavior and reduce unintended emissions.

Apply safe CDC structures

Modern FPGA designs often contain multiple clock domains. Unsafe crossings can lead to metastability, data corruption, or intermittent failures that are difficult to reproduce.

• Use two-stage synchronizers for single-bit signals crossing domains.
• Use Gray code counters for multi-bit monotonic values such as FIFO pointers.
• Use handshake synchronizers for control signals requiring acknowledgement.
• Use asynchronous FIFOs for high-throughput or burst data transfers.
• Use asynchronous reset synchronizers for cross-domain reset assertion/de-assertion.
• Use vendor CDC macros (e.g., Xilinx XPM) for optimized placement and timing.
• Run static CDC analysis to detect incorrect domain associations or missing synchronizers.
• Synchronize all asynchronous inputs to the appropriate clock domain.

Enforce RTL coding standards and structural safety

Code quality directly affects security, maintainability, and synthesizability. Poor RTL can introduce hazards such as latches, mismatched ranges or unsafe FSMs.

• Use enumerated types for FSMs and apply safe encoding (e.g. Hamming-3).
• Ensure consistent indentation, naming and file-header structure as defined in coding standards.
• Avoid hard-coded numeric values, and use constants in shared packages.
• Ensure complete sensitivity lists in combinatorial processes.
• Avoid latches, gated clocks and multiple drivers.
• Ensure consistent vector ordering and avoid mismatched ranges.
• Apply linting tools to enforce DO-254-aligned coding rules.
• Use structural analysis tools to detect FSM issues, CDC hazards and undriven or unused nets.

Harden I/O and startup behavior

I/O behavior during power-up and reset is a common source of unintended or unsafe system states. Proper handling prevents contention, glitching and misinterpretation of signals.

• Leave unused pins unconnected on the board but drive them low internally.
• Ensure bus interfaces enter high-impedance during reset to avoid contention.
• Apply asynchronous reset assertion to guarantee safe I/O behavior during startup.
• Use glitch filtering on sensitive inputs to prevent malicious or accidental triggering.
• In systems with transmissionsecurity requirements, ensure signaling patterns do not reveal operational intent. Here, padding or batching may be required.
• Consider emissions behavior when defining I/O drive strength and switching patterns.
• Follow datasheet guidance for special pins such as PLL inputs and no-connect pins.
• Avoid relying on default I/O states during power-up.

Apply radiation mitigation techniques

In high-altitude or space environments, radiation can induce SEU, SET, MBU, or SEFI. These effects can corrupt registers, memories or configuration frames, and must be mitigated.

• Apply TMR to critical logic, ensuring spatial separation of redundant elements.
• Use ECC or EDAC on memories, including BRAM and distributed RAM.
• Enable configuration scrubbing for SRAM devices.
• Derate timing constraints to account for parametric changes due to TID.
• Analyze whether SEU or SET is more likely to dominate based on path delays and clock frequency.
• Consider SEFI behavior and recovery mechanisms where applicable.
• Use safe FSM encoding to prevent SEU-induced lockup.

Document and verify module-level behavior

Each module should be designed as an independent, verifiable unit with clearly defined behavior under normal and fault conditions. This supports maintainability, reuse and fault containment.

• Document inputs, outputs, reset states and behavior under fault conditions.
• Identify which tools fall under T1, T2, and T3 classifications and ensure appropriate verification evidence is generated.
• Describe algorithms, quantization and expected timing.
• Create an independent test plan covering corner cases and boundary conditions.
• Use continuous integration to run regression tests and constrained-random simulations.
• Verify stuck-at-0 and stuck-at-1 behavior for all module inputs to confirm single-bit faults cannot falsely assert control signals or block module progress.
• Include poweron selftest or continuous healthmonitoring requirements where mandated, especially for cryptographic or safetycritical modules.
• Verify entropy sources and other security primitives behave correctly under fault conditions.

Verification

Verification is used to demonstrate that the architecture behaves deterministically and securely under all expected conditions. Linting, for example, ensures RTL structural correctness, while CDC analysis confirms safe domain crossings. Similarly, FSM analysis checks for unreachable, terminal or unsafe states, while timing analysis incorporates derating to account for parametric changes due to radiation. Hardware testing then confirms oscillator startup, reset timing and glitch filtering.

Where anti-tamper or emissions constraints apply, verification must also include the testing of tamper-response behavior, monitoring of entropy sources and confirmation that signaling patterns do not reveal operational intent. These checks complement structural analysis and timing verification to ensure the architecture behaves securely under all expected conditions.

Verification checklist

• Deterministic startup: Oscillator startup time, reset assertion, and reset release behave predictably, with no undefined I/O states.
• Clock and reset integrity: Clock presence detection, reset generation, and reset synchronization operate correctly under all poweron and fault conditions.
• Safe CDC behavior: All domain crossings use approved synchronizers, FIFOs, or handshakes; static CDC analysis reports no violations.
• Configuration security: Bitstream authentication/encryption is enabled; JTAG is locked; scrubbing (if required) is active and verified.
• Entropy source validation: Hardware RNGs produce unbiased output and pass health checks under normal and stressed conditions.
• RTL structural safety: Linting, FSM analysis, and structural checks confirm no latches, gated clocks, unsafe FSMs, or multiple drivers.
• I/O hardening: Startup I/O behavior is safe; unused pins are handled correctly; no contention or glitchsensitive paths exist.
• Radiationmitigation effectiveness: TMR, ECC/EDAC, scrubbing, and derated timing constraints operate correctly under injectedfault or simulatedfault conditions.
• Modulelevel verification: Each module behaves correctly under nominal, boundary, and fault conditions, including stuckat faults and reset recovery.
• Antitamper and emissions behavior: Tamper detection, zeroization paths, and emissionsrelated constraints behave as intended without revealing operational intent.
• Documentation and traceability: Requirements, test plans, and verification evidence trace cleanly from architectural intent to implementation.

Expected output

A successful implementation produces deterministic startup, with all registers and FSMs entering known states.

• Clock domain crossings behave safely without metastability-induced failures.
• Only authenticated bitstreams configure the device, and JTAG is locked.
• I/O pins exhibit stable behavior during power-up, with no contention or unintended transitions.
• Radiation-induced faults are tolerated through TMR, ECC, and scrubbing, and timing remains predictable under derated constraints.

Finally, each module behaves correctly under fault conditions and is fully traceable through its documentation and test plan.

Variations

Variations depend heavily on the operational environment and the role the FPGA plays within the wider system.

Designs intended for high-radiation missions may require full-device TMR, hardened libraries, and aggressive scrubbing to maintain configuration integrity, for example. In contrast, cost-constrained designs may apply TMR more selectively, with ECC and safe FSM encoding providing the primary defense against single-event effects.

Other systems are shaped more by power or security considerations. Low-power platforms will often favor Flash or OTP devices and apply selective redundancy to balance resilience with energy constraints. The same often applies to security-critical cryptographic modules, where strict red/black separation and controlled update paths reduce the attack surface.

Finally, some designs are driven primarily by throughput. High-performance systems typically rely on SRAM-based FPGAs, combining isolation flows with robust scrubbing to protect configuration frames under load.

Revision history

August 2026 – v1.0 – Initial release