FPGA Thermal Monitoring, Sequencing and Fan Control

Make one supervisor authoritative before choosing sensors #

An FPGA board can report a believable junction temperature and still fail thermally. The on-die monitor may not be readable until configuration or user mode, a board sensor can lag a fast hotspot, and a host-written fan command can disappear when firmware hangs. The design problem is therefore not simply “add a temperature sensor.” It is to assign authority for start-up cooling, normal fan control, thermal throttling and the last-resort shutdown path.

For a new board, freeze that control contract before selecting the fan controller or power sequencer:

• which temperature sources are valid before, during and after FPGA configuration;
• which component owns the fan's safe power-up duty cycle;
• which thresholds request more airflow, reduce workload, assert reset or remove rails;
• which actions remain available after the FPGA fabric or host processor becomes unresponsive;
• how the power-down sequence protects memory, I/O and still-powered peripheral rails;
• what configuration files, exact orderable codes and bench evidence travel with the production BOM.

This is a different decision from the AMD-Xilinx FPGA power-delivery guide or the Altera FPGA power-delivery guide. Those guides size and sequence the rails. This article defines the supervisory layer that decides when the rails may start, how the board reacts to rising temperature or a failed fan, and what remains in control when normal software is absent.

The figure separates measurement from authority. FPGA telemetry can improve the normal control loop, but the standby-powered supervisor and fan-start hardware must cover the intervals when that telemetry is unavailable. The hard shutdown path should not depend on the same firmware whose failure it is intended to contain.

Use on-die and external sensors for different jobs #

AMD Versal: configure SYSMON as part of the platform #

AMD's Versal System Monitor resides in the platform management controller and measures internal supplies, device temperature and external analog channels. In the current 2026.1 Vivado programming guide, designers must select the required sensors in CIPS or the applicable processing-system wizard; without that configuration, only device temperature is accessible. The architecture manual also supports configurable voltage and temperature alarms, hysteresis and an over-temperature response.

The response matters as much as the reading. AMD documents four over-temperature actions through the processing-system configuration: POR, system reset, error output or no automatic response; system reset is the default. That means the schematic, CIPS settings and field firmware must agree on whether an OT event resets the device, signals an external supervisor or deliberately leaves the response to software.

Large multi-SLR Versal devices add another boundary. The ordinary DEVICE_TEMP registers cover the master SLR; AMD directs current full-device temperature reads to FULL_DEVICE_TEMP, which reports the highest temperature across SLRs. A test plan that polls only the master-SLR value can miss the governing hotspot.

Altera Agilex 5: local readings and remote diode access differ #

Altera's April 2026 Agilex 5 power-management guide describes local on-chip sensors read through the Secure Device Manager mailbox and an external remote-temperature-sensing-diode path. The local sensors operate in user mode. The remote diode is read by an external temperature-sensing IC and can operate while the FPGA is powered on or off, although Altera requires user calibration for that path.

Agilex 5 devices provide up to four local sensor locations depending on series, density and package. The optional nCATTRIP output can be assigned to an SDM I/O pin and programmed from 95°C to 120°C in 1°C increments, but the guide says to monitor it only in user mode with the pin option enabled. It is therefore a useful device-level alarm, not a substitute for a standby-powered board guard that must exist before configuration.

Board sensors measure the cooling system, not just the die #

An external sensor earns its BOM line when it observes a different thermal state: inlet air, exhaust air, regulator stages, optical modules, memory, a heat-sink base or a cold plate. A multi-channel remote sensor can also read supported diode-connected junctions while reporting local board temperature.

TI lists TMP468AIRGTR as active. It is a 16-pin 3 mm × 3 mm VQFN device rated from −40°C to 125°C, with eight remote-diode channels plus one local channel, I²C/SMBus access, programmable limits, hysteresis, diode-fault detection and a maximum ±0.75°C local/remote accuracy under the data-sheet conditions. Those features make it a concrete candidate for multi-zone boards, but not every FPGA exposes a diode that can be connected arbitrarily. Confirm the FPGA pin guidance, sensor non-ideality-factor support, routing resistance, calibration method and required operation state before releasing the schematic.

Sequence cooling, rails, reset and configuration as one state machine #

A delay-only sequencer can produce the right cold-start waveform and still respond incorrectly to a brownout or fan failure. The state machine must qualify both the power rails and the cooling path.

At cold start, standby power should bring up the supervisor, external sensors and fan controller first. The fan starts from a hardware-defined duty or RPM target; the design then decides whether a valid tachometer is required before high-power FPGA rails are enabled. Low-power or sealed designs may not need a fan-prove gate, but the omission should be explicit rather than accidental.

The rail sequence then follows the exact device documentation. AMD's June 2026 XAPP1375 revision says that Versal power-down normally reverses the power-on order unless the Power Design Manager states otherwise; each prior rail should fall to 5% of target before the next rail ramps down, and rail discharge can require a bleed path or active discharge. Altera's Agilex 5 guide and AN 692 likewise require family-specific sequencing and I/O management. An external device driving an unpowered bank can create unwanted current even when the regulators themselves appear to start correctly.

Reset and configuration are release conditions, not just delays. The supervisor should release POR/reset only after required rails are in-window and the chosen fan/cooling preconditions are true. Configuration-done or user-mode status then allows the normal thermal manager to use on-die readings. Until that handoff, the fan controller's hardware start state and the external supervisor remain responsible.

When a thermal limit is crossed, use staged action with hysteresis and time qualification:

1. increase the affected fan zone to its high or full-speed target; 2. request workload reduction or clock gating while retaining telemetry; 3. assert reset or an error output if the temperature continues to rise or the fan remains stalled; 4. execute a documented, fault-aware power-down sequence while keeping the supervisor and required cooling alive; 5. latch the fault when automatic restart could create thermal cycling or repeated boot stress.

Thresholds must come from the FPGA's permitted junction range, sensor error, thermal impedance, control latency and the hottest validated workload. Do not publish one generic warning or shutdown temperature across AMD and Altera families. The nCATTRIP and Versal OT values are configurable mechanisms; they are not universal board setpoints.

Choose controllers by independence and failure behavior #

Three current component examples illustrate separate jobs. They are not a reference BOM and are not presented as AMD- or Altera-approved companions.

The important architectural distinction is independence. UCD9090A can enforce rail dependencies even when the FPGA is not configured. MAX31790 provides hardware power-up choices so fans do not have to wait for a host command. TMP468 can support an external thermal path, subject to the FPGA's diode interface and calibration rules. A design may combine these functions differently, but it should preserve the same safety properties.

Do not hide configuration behind a base part number. A production RFQ for UCD9090ARGZR without the approved configuration file is incomplete. A quote for “MAX31790” does not state tray versus tape-and-reel packing; MAX31790ATI+ and MAX31790ATI+T are separate production orderables. A sensor substitution is not valid merely because it has the same I²C address range: remote-diode accuracy, non-ideality correction, alert behavior and register lock can change validation results.

Validate faults, not only steady temperature #

Thermal qualification should correlate the on-die reading, external sensors and a calibrated physical reference at several controlled operating points. The goal is not to force them to show the same number; it is to understand offset, location, time constant and the controlling worst case.

Run at least these fault injections on the assembled board:

• cold start with the fan disconnected, tach stuck and I²C unavailable;
• delayed or missing power-good on every sequence dependency;
• configuration failure while fan control remains in its hardware start state;
• maximum qualified workload at minimum and maximum airflow;
• blocked inlet or heat sink, fan slowdown and complete fan stall;
• external-sensor open/short or remote-diode fault indication;
• on-die warning, critical alarm and hysteretic recovery;
• commanded power-down, abrupt input loss and restart after a latched fault.

Capture rail voltages at the FPGA sense points, reset/configuration pins, PWM duty, tach pulses, alarm outputs, workload state and all temperature channels on one time base. A PMBus or I²C log is useful for sequence history, but it is not high-bandwidth proof of rail ramp or transient compliance. Conversely, an oscilloscope waveform does not prove that the deployed configuration file and field firmware implement the same policy.

Acceptance should answer five questions: Did cooling start before the high-power load? Did every required rail reach its threshold in order? Did on-die telemetry become authoritative only after its documented availability point? Did a fan or sensor failure cause the intended staged response? Did shutdown preserve I/O and memory integrity while keeping supervision alive long enough to finish?

Release the supervisory BOM as a controlled assembly #

The FPGA OPN, sequencer, sensor and fan-controller rows are one engineering configuration, not independent catalogue matches. Before production release, ask the supplier or contract manufacturer to return:

• complete orderable codes, package, temperature grade, packing method and lifecycle status;
• sequencer binary/project file, checksum, PMBus address and programming method;
• fan-controller start straps, PWM frequency, tach pole count, spin-up and watchdog settings;
• sensor channel map, remote-diode calibration constants, thresholds and alert polarity;
• schematic/PCB revision, approved firmware build and the thermal policy table;
• fan model, connector/pinout, minimum qualified RPM or airflow, tach characteristics and replacement boundary;
• lot/date-code and traceability requirements for the production quantity.

A fan with the same dimensions can have a different PWM input, tach output, minimum start duty, pressure-flow curve or connector. A power sequencer with enough channels can still be invalid if its programming flow, threshold accuracy, NVM control or fault outputs differ. Treat alternates as system-level changes that repeat the relevant thermal and fault tests.

Conclusion #

Reliable FPGA thermal management comes from an explicit authority chain. Use on-die monitors for device-aware temperature and alarms, external sensors for pre-configuration and board-level context, a hardware-defined fan start state, and a standby-powered supervisor that can enforce rail dependencies and fault shutdown without relying on the FPGA fabric it protects.

The release package should tie those choices to exact OPNs, programmed files, thresholds, fan data and fault-injection evidence. That turns “thermal monitoring and fan control” from a firmware feature into a testable power-and-cooling contract.

Official references #

• AMD Versal Adaptive SoC System Monitor Architecture Manual AM006, revision 1.5
• AMD Simplified Power Sequencing XAPP1375, revision 1.4
• AMD Vivado 2026.1 System Monitor setup for Versal devices
• Altera Agilex 5 Power Management User Guide, April 2026
• Altera AN 692 Power Sequencing Considerations
• Texas Instruments UCD9090A product and orderable information
• Texas Instruments TMP468 product and orderable information
• Analog Devices MAX31790 product, lifecycle and orderable information