FPGA Power-Up, Configuration and Field Updates: Designing the Boot Path That Does Not Brick Your Product

The part of FPGA design that nobody puts on the schedule

Teams plan the logic, the timing and the board. They often leave the question of how the FPGA gets its design at power-up, and how a new design gets in after the product has shipped, to the end. That is where a lot of field failures live: a board that sometimes does not start, a product that locks up after a failed update, a motor that twitches at power-on. All of them are designed in or out early.

Two kinds of FPGA, two kinds of boot

• SRAM-based devices keep their configuration in volatile memory, so at every power-up the bitstream has to be loaded from somewhere: usually an external serial flash that the FPGA reads itself, or a processor that sends it over a serial or parallel link. The load takes a measurable time, from tens to hundreds of milliseconds depending on the device size and the speed of the link, and until it ends the logic does nothing. The design includes an extra memory part and a boot sequence.
• Flash-based devices (the families that store the configuration on the chip itself) are running almost at once after power is stable, with no external boot memory, and the configuration is not lost or corrupted by the radiation-induced upsets that can flip a bit in volatile configuration memory. We chose a PolarFire part for our core board partly for this reason, and some small Lattice families work the same way.

Neither is better in general. The question is whether the product can afford the start-up time, the extra part and the exposure of the configuration, and whether the application needs the density and speed that only an SRAM-based family offers.

Start-up time is a requirement, not a detail

Write down the longest time the product may take to be ready, and check the boot path against it. A device on a PCI Express link, for instance, has to answer within a limited time after power is stable, and an FPGA that is still loading when the host enumerates the bus will simply not be found. Many designs solve it with a fast configuration mode, a wider or faster flash link, a smaller bitstream, or by splitting the design so that a small part starts first and the rest is loaded afterwards.

Power sequencing and supervision

• FPGAs have several supplies: the core, an auxiliary supply, and one for every bank of I/O. Read the datasheet's order, ramp-time and monotonicity requirements, and design the power tree to meet them with margin, not merely on the bench.
• Use a supervisor that holds the FPGA in reset until all supplies are good, and one that detects a drop during operation. Slow or noisy ramps cause configuration failures that look random.
• Test the supplies' behaviour at the extremes: cold start at low temperature, slow ramp from a weak source, brown-out and recovery.

What the pins do before the design starts

During configuration, before your logic exists, the I/O pins are in a default state, usually high impedance, sometimes with weak pull-ups, depending on the family and a configuration pin. Anything connected to them sees that state. A pin that will later drive a motor, a heater, a relay or a reset line must have an external pull resistor to the safe level, so that it is safe while the FPGA is blank. Check this in the schematic review for every output, including the ones that drive another chip's chip-select or reset. A shared bus whose peripherals all see floating lines at power-up can produce a surge in current.

Configuration modes and how the board is programmed

• Leave a JTAG connection available on every board, including production units. It rescues a board with a corrupted flash, and it supports debug.
• Decide how the configuration memory is programmed in the factory: pre-programmed parts before assembly, programming through the FPGA over JTAG after assembly, or by a processor. The cheapest choice for ten boards is not the cheapest for ten thousand.
• Check the configuration pins' pull-ups and the mode-select straps for every board revision, because a wrong strap makes the device wait for a configuration that never comes.

Field updates that survive power loss

An update is the most dangerous operation a deployed product performs. It must survive an interruption at any point, a supply that dips, a cable pulled, a corrupted download.

1. Two images, not one. Keep a golden image that is never overwritten in the field, and a second slot for updates. If the primary image fails its check, the device falls back to the golden one and can still communicate, so it can be repaired remotely. Most families support loading from more than one location, with a fallback if the first fails.
2. Write the new image to the inactive slot, verify it, then switch. Check a CRC or hash over the whole image after writing, and only then change the pointer that selects it. The switch itself should be a single, small write.
3. Verify before trusting. A watchdog or a handshake from the new design, within a time limit after it starts, confirms it works. If it does not, revert to the golden image on the next boot.
4. Sign the image. A signature check, with the public key stored in the device or the processor that performs the update, stops an unauthorised or corrupted file from being installed. Use the device's bitstream encryption and authentication features where they exist.
5. Report the version. Let the design expose its build identifier through a register so that support knows what is running in the field.

Tests that find boot failures

• Power-cycle the board thousands of times, with random off-times, and count the failures to start.
• Interrupt the update at every stage: during the erase, during the write, during the final switch. The device must always come back.
• Power it from a slow ramp and from a brown-out dip.
• Run at the temperature extremes, since flash timing and supply behaviour both change.
• Corrupt an image on purpose and confirm that the fallback takes over.

Where we can help

We design FPGA boards and logic including the configuration, power and update path, on Lattice, Microchip PolarFire and Xilinx devices. See our FPGA design service, our guide to timing constraints and closure, and our guide to choosing an FPGA for an embedded product.