In short: Power sequencing is the disciplined control of the order, timing, and slew of every voltage rail on a board so that SoCs power up and down within their datasheet windows, avoiding latch-up, back-powering, and inrush that trip supervisors or crowbars.
Modern embedded boards no longer run on a single 5 V rail. A typical SoC design — a quad-core applications processor with LPDDR4, a PMIC, an eMMC, and a PHY or two — may carry eight to fifteen distinct rails ranging from 0.8 V core to 3.3 V I/O. Those rails cannot simply be switched on together. Many silicon vendors specify a strict sequence, a maximum skew between rails, and sometimes a monotonic ramp requirement. Get it wrong and you risk CMOS latch-up, excessive gate leakage, or an undefined logic state that hangs the boot ROM. This article walks through why sequencing matters, how to enforce it, and the real parts and tools engineers use.
Why rail order matters: the physics
Every CMOS die has parasitic structures. If an I/O rail (say 3.3 V) comes up while the core (0.8 V) is still at ground, current can flow through ESD clamp diodes and the parasitic PNP/NPN of the substrate, forward-biasing a junction that should stay reverse-biased. In the worst case this fires the parasitic SCR — classic latch-up — and the only recovery is removing power. Even short of latch-up, a powered I/O pin driving into an unpowered core is "back-powering": it sneaks current into the core rail through the clamp, raising it uncontrolled and sometimes corrupting NAND or configuration straps that are sampled at reset release.
This is exactly why datasheets for parts like the NXP i.MX 8M or TI Sitara AM62x publish a sequencing table: core-before-I/O (or the reverse), with a stated maximum delay such as "VDD_SOC must reach 90% before VDD_IO, within 10 ms." A clean, repeatable ramp is what keeps the device inside that window.
Rule of thumb: when the datasheet gives no explicit order, bring up the lowest voltage (core logic) first and the highest (I/O) last on power-up, then reverse that order on power-down. This keeps I/O from ever driving into an unpowered core.
The building blocks
Sequencing is implemented with a small, well-understood toolkit:
- PMICs with built-in sequencers — devices like the TI TPS65219 or Dialog/Renesas DA9063 contain a one-time-programmable sequence table. You set the delay and order per rail in OTP or I²C; the PMIC handles everything autonomously at the next power event.
- Load switches — a high-side P- or N-channel FET (e.g. TI TPS22965) gated by an enable from the previous rail's power-good. These are cheap, add controlled slew via a slew-rate pin, and are ideal for gating a downstream rail off an upstream one.
- Sequencing / supervisor ICs — parts like the TI LM3880 or Analog Devices ADM1186 generate cascaded enables with fixed or resistor-set delays, independent of the regulators.
- Voltage supervisors (reset ICs) — these watch a rail and assert RESET until it is valid. More on these below.
Supervisors and the reset window
A sequencer gets the rails up in order; a supervisor (a.k.a. reset IC or voltage detector) guarantees the processor is held in reset until every monitored rail is valid, and re-asserts reset if any rail sags. Multi-channel supervisors such as the TI TPS3890 or Analog Devices ADM13305 monitor several rails against independent thresholds and OR their faults into a single open-drain RESET#. Critically, the supervisor also applies a reset timeout — tens to hundreds of milliseconds after the last rail is good — so clocks and the DDR controller stabilise before the CPU fetches its first instruction. If the supervisor threshold is too close to the nominal rail, normal ripple can glitch reset; if too low, the CPU may run before logic is guaranteed. This same monitoring feeds brown-out protection, covered in our companion piece on brown-out reset and BOR thresholds.
Inrush and soft-start
When a rail switches on into bulk and ceramic decoupling capacitance, the initial di/dt can be enormous: a 470 µF bank charged through a 5 mΩ FET can momentarily pull tens of amps. That spike can collapse the upstream rail (triggering the supervisor and causing a boot loop), stress the FET, or create EMI. The fix is soft-start: a controlled ramp. Load switches expose a slew-rate (dV/dt) pin; sizing a capacitor there to ramp, say, 3.3 V over 2 ms limits inrush to roughly I = C × dV/dt. For a 1000 µF load that is about 1.65 A instead of an uncontrolled spike.
Inrush current ≈ Cload × (dV/dt). Ramping 3.3 V across 1000 µF in 2 ms gives ~1.65 A; the same cap charged in 20 µs would demand ~165 A. Slew control is not optional on large rails.
A worked sequencing table
| Step | Rail | Voltage | Enable source | Delay after prev. |
|---|---|---|---|---|
| 1 | VDD_CORE | 0.8 V | PMIC buck 1 | t=0 |
| 2 | VDD_DDR | 1.1 V | PMIC buck 2 / PG1 | 2 ms |
| 3 | VDD_IO | 1.8 V | LDO / PG2 | 2 ms |
| 4 | VDD_3V3 | 3.3 V | Load switch / PG3 | 5 ms (slew-limited) |
| 5 | RESET# | — | Supervisor OR + 100 ms timeout | after all PG |
Power-down walks this table in reverse. Many PMICs let you define the down-sequence independently; where they do not, a diode-OR'd discharge path or active pull-downs on each load switch ensure I/O collapses before core.
Verifying the design
Sequencing is one of the few areas you must validate both in simulation and on the bench. In SPICE (Cadence Spectre, Synopsys HSPICE/PrimeSim, or Siemens' Eldo-lineage simulators) you model the PMIC enables, cap banks, and switch RDS(on) to confirm ramp timing and peak inrush before committing to silicon. On power-integrity, tools like Cadence Sigrity or Ansys SIwave check that the rail stays within its DC tolerance under the inrush load. On the bench, a 4-channel scope capturing all rails plus RESET# against a current probe is the ground truth — you are looking for monotonic ramps, correct skew, and no reset glitch. For teams designing custom silicon or complex PMIC boards, specialist power-integrity help from a design house such as Avecas VLSI design services can shorten that bring-up. The related timing of clean reset assertion is covered in our note on reset supervisor circuits.
Want to design bring-up-clean boards and read any SoC datasheet's sequencing table with confidence? Our CourseTron Embedded Hardware track covers PMICs, supervisors, and power integrity hands-on — see the full course catalogue.
Frequently asked questions
Does every multi-rail board need a dedicated sequencer?
No. If your PMIC has a programmable sequence table that satisfies the SoC datasheet, that alone is usually enough. A separate sequencer IC is needed mainly when regulators are discrete, when rails come from different sources, or when the required skew is tighter than the PMIC can guarantee.
What is the difference between a sequencer and a supervisor?
A sequencer controls the order and timing of turn-on and turn-off. A supervisor monitors rails against thresholds and holds the processor in reset until they are valid, re-asserting reset on any fault. They solve different problems and are often used together.
How do I pick a soft-start time?
Choose the slowest ramp that still meets the SoC's maximum rail-to-valid window and any monotonic requirement. Then compute inrush as Cload × dV/dt and confirm it stays below the upstream source's current limit and the load switch's SOA. Typical embedded rails ramp in 1–5 ms.
Can I sequence rails purely in firmware over I²C?
You can for non-critical rails, but the earliest rails (core, DDR) must be hardware-sequenced because no CPU is running yet. I²C control is best for later, software-managed peripheral rails after boot.