What this page controls (and what it does not)

Multi-rail PoL & sequencing is the board-level discipline of orchestrating multiple point-of-load regulators as a dependency-driven power tree: each rail reaches regulation in the right order, releases reset at the right time, and exposes enough observability (PG/RESET/telemetry) for deterministic bring-up and fault handling.

This scope stays strictly at the rail and domain level (core, memory, high-speed IO, analog references, RF bias, clock rails). It does not deep-dive aircraft 28 V input surge/spike compliance, hot-swap/eFuse input stages, emergency hold-up energy paths, or isolation/lightning/ESD protection design.

Why avionics sequencing is an engineering object (not a “power-up script”)

Avionics loads typically combine window-sensitive domains (DDR bring-up, FPGA configuration, SerDes PLL lock) with fault-containment needs (prevent back-powering, avoid repeated brownout oscillation, preserve forensic evidence). As a result, “all rails on, then release reset” is rarely stable.

• Order comes from dependency, not voltage magnitude (e.g., clock/PLL readiness gates high-speed IO).
• Timing is defined by windows (blanking/debounce/hold-off), not by one fixed delay.
• Proof requires observability: PG/RESET logic plus telemetry snapshots that explain “why it failed”.
• Fault policy (retry vs latch-off) is part of the design, not an afterthought.

Reference example: typical avionics board power domains

A practical power tree is best described by domains, each with its own “in-regulation criteria” and reset-release rules: compute core rails (high current), DDR rails (tight timing windows), IO/SerDes rails (clock dependency), analog/reference rails (settling & noise sensitivity), RF bias rails (controlled enable and current limits), and clock rails (must be stable before dependent logic is released).

Why “sort by voltage” fails: sequencing is defined by dependency

Rail order is almost never determined by whether a rail is 0.9 V or 3.3 V. The order is determined by what must be true before a domain is allowed to start and by what must be shut down first to prevent back-powering or repeated brownout oscillation. In practice, the true dependencies are logical and temporal: clocks must be stable, memory must be inside a valid initialization window, and reset must be released only after rails are proven “in criteria” for long enough.

• Clock/PLL readiness often gates high-speed IO and portions of compute logic.
• DDR windows depend on rail settling, reference stability, and reset-release timing.
• Analog references may require “time in regulation” before measurements are trusted.
• Pre-bias behavior can change restart behavior and inrush stress.
• Shutdown priority can be as important as power-up order (to avoid back-power paths).

Rail taxonomy: define domains before defining the order

Start by grouping rails into domains that share criteria and failure consequences. This prevents “one rail, one rule” chaos and makes the dependency graph readable.

• Core rails: high-current supplies with tight transient limits and strict PG windows.
• Memory rails: window-sensitive rails (e.g., DDR) where timing and reset-release conditions matter as much as voltage.
• IO / SerDes rails: often dependent on clock readiness and sometimes require staged enables.
• Analog / reference rails: settling, noise, and “time-in-window” are common criteria.
• RF bias rails: controlled enable and current limits; dependency typically ties to system mode (not to voltage level).
• Clock rails: treated as a gating domain; “stable then release” is the fundamental rule.

Per-rail specification fields: the minimum dataset that enables deterministic sequencing

Each rail should be specified with a small but complete set of fields. The goal is to make “rail ready” a testable predicate, not a subjective judgment.

• Vnom & tolerance (e.g., ±2%) and any allowed overshoot/undershoot at start-up.
• Ramp requirement: maximum and minimum ramp rates; soft-start expectations.
• Time-in-window: how long the rail must remain within limits before it is considered ready.
• Allowed pre-bias: whether the rail can start from a non-zero voltage without forced discharge.
• PG criteria: threshold, hysteresis, blanking, debounce, and any dependencies on other rails.
• Reset relation: required reset hold time and the safe release point relative to PG and clocks.
• Shutdown priority: what must turn off first to prevent back-power or unstable partial operation.
• Fault policy hooks: whether a fault leads to retry/backoff or latch-off, and what must be logged.

Dependency graph template: express requirements as predicates and ordering constraints

A dependency graph becomes actionable when each dependency is written as a predicate (what must be true) and a constraint (what must happen before/after). The following template scales cleanly into a state-machine sequencer later (H2-4).

Decision goal: choose the architecture that matches dependency complexity and maintainability

Architecture selection should be driven by dependency complexity (how many rails, how many “must-be-true” predicates), fault containment (how far a rail fault is allowed to propagate), and maintenance traceability (whether a field event can be explained using status + snapshots).

Option A — Single digital PMIC (multi-rail buck/LDO + built-in sequencer)

A single digital PMIC is strongest when a power tree can be expressed with a moderate number of rails and predicates, and when a unified controller reduces integration risk. Sequencing, PG aggregation, and protection behaviors are consolidated into one configuration space, which simplifies bring-up.

• Best fit: moderate rail count; limited cross-domain exceptions; consistent “one policy” behavior is preferred.
• Watch-outs: fault coupling can be broader; late rail additions may force re-validation of the whole configuration.
• Traceability: ensure the device can expose status history or snapshot hooks; otherwise root-cause time increases.

Option B — Distributed PoLs + external sequencer / MCU

Distributed PoLs separate power execution (each PoL owns its rail dynamics and protections) from power orchestration (a sequencer/MCU enforces dependencies and system policy). This scales well when the dependency graph grows or when different domains require different fault responses.

• Best fit: high rail count; complex dependencies; domain-specific policies (some domains may degrade, others must shut down).
• Watch-outs: integration becomes a system responsibility (PG timing alignment, bus latency, consistent predicate evaluation).
• Traceability: stronger by design when a controller captures “what happened” at the moment predicates failed.

Option C — Two-layer control (PMIC handles hard real-time protection; MCU handles policy, telemetry, logs)

Two-layer control combines deterministic protection with flexible maintainability. The PMIC/PoLs enforce fast safety actions (limits, immediate fault signaling, basic sequencing), while an MCU implements a policy layer: dependency predicates, retry/backoff budgeting, snapshot capture, and service-friendly diagnostics.

• Best fit: both deterministic protection and deep field forensics are required; policy is expected to evolve.
• Watch-outs: define authority boundaries (what PMIC may force vs what MCU may override); avoid conflicting actions.
• Traceability: strongest when snapshots include “predicates + raw telemetry + status registers” with a stable event ID.

Why a state machine (not a timing table)

A timing table works only when the number of rails and exceptions stays small. Once sequencing includes predicates (PG stability, time-in-window, clock readiness), fault branches (retry vs latch), and brownout behavior (partial dropouts), the correct representation is a state machine. Each transition carries a measurable condition, making validation and troubleshooting repeatable.

• State = objective (what is being achieved) + readiness predicate (how “done” is proven).
• Transition = measurable guard (PG=1, V>Vth, t_blank done, FAULT=0).
• Fault path = policy decision (retry/backoff or latch-off) + snapshot capture.

Core sequence states and measurable predicates

A minimal yet scalable sequencing machine can be expressed with six states. Each state is validated by one or more predicates, rather than by a single delay.

• OFF: controlled rails disabled; fault latches cleared or recorded.
• PRECHECK: configuration valid; required conditions met; retry budget available.
• RAIL_RAMP: rails enabled in dependency order; ramp constraints enforced.
• IN_REGULATION: rails meet tolerance and time-in-window; PG debounced.
• RESET_RELEASE: resets deasserted only after dependency predicates are satisfied.
• RUN: continuous monitoring; snapshot triggers armed for PG drop or FAULT assert.

Fault policy and brownout handling (rail-level)

Fault policy determines whether the sequencer attempts recovery or locks the system into a safe state. The policy must be explicit because repeated automatic restarts can create oscillation and mask root causes.

• RETRY_BACKOFF: limited retries with increasing delays; each attempt requires a clean precheck and a new snapshot.
• FAULT_LATCH: used when continued retries risk undefined behavior; requires a deliberate clear action and a forensic record.
• BROWNOUT path: on partial rail dropout, dependent rails are shut down in priority order while logging the first failing predicate.

Power-good is a predicate, not a “looks-up” indicator

A Power-Good (PG) signal should represent a verified operating window: the rail is above its threshold, remains within tolerance for long enough, and is evaluated with filtering that matches real-world transients. PG should be treated as a measurable predicate used by a sequencer or supervisor, not as a cosmetic “power is on” LED.

Common failure modes (and why they happen)

• PG released too early: logic starts before a dependent rail or readiness window is stable. The root cause is a PG definition that checks only a threshold, not a stable window.
• PG glitch / chatter: threshold-edge noise, load steps, or near-threshold ramps cause spurious toggles. Without proper blanking and debounce, the reset tree can oscillate.
• Multi-PG merge hides the “first-fail” rail: a wired-AND/OR global PG is fast for safety action, but it can erase the identity of the rail that failed first, raising diagnostic time.

PG/RESET parameter checklist (field-ready spec template)

Treat each rail (and each reset domain) as a small specification. The checklist below defines what “good” means, how long “good” must persist, and when reset may be released.

Why the same load can produce different ramps (predictability starts with initial conditions)

Start-up waveforms can vary even with the same nominal load because the initial conditions are not identical: pre-bias may leave a rail at a non-zero voltage, large load capacitance changes the demanded charge, and rails can interact through unintended paths during sequencing overlap. Ramp predictability requires explicit control of slope, current limits, and evaluation windows.

Phenomenon → root cause → countermeasure (one issue per card)

Ramp controllability checklist (what to define and verify)

Make ramp behavior a specification. These parameters reduce start-up randomness and improve cross-build consistency.

Telemetry is an evidence chain: analog values, status meaning, and event history

PMBus telemetry becomes engineering evidence only when it answers three questions consistently: what changed (V/I/T), what the device concluded (status registers), and whether it repeats (event counters such as retry and brownout counts). The goal is not to “collect everything,” but to collect a minimal, stable set that can reconstruct first-cause timing.

Minimal PMBus field set (stable core + optional MFR extensions)

A minimal field set should be small enough to log reliably, yet rich enough to support fault reconstruction. The core fields below cover most power-domain failures without inflating bandwidth.

How to log: periodic sampling vs triggered black-box snapshots

How to trust telemetry: bandwidth, averaging vs peaks, thresholds, and calibration bias

Telemetry can mislead when it hides fast events or mixes incompatible interpretations. Trust improves when readings are paired with context: sampling window, avg vs peak meaning, and configuration identity.

• Bandwidth: slow polling may miss spikes; use trigger snapshots to capture first transitions.
• Average vs peak: store both when possible; a normal average can coexist with a critical peak event.
• Threshold + hysteresis: define pairs to avoid alert chatter and ambiguous “near-edge” conditions.
• Calibration bias: record calibration version or bias terms so trends remain comparable over time.

Power-domain fault tolerance is a pattern library, not a one-off schematic

Fault tolerance should be expressed as reusable patterns with explicit policy: what triggers a transition, what action is taken, what signals prove the action worked, and how recovery is handled. The focus here is strictly power-side behavior: rails, PG/RESET behavior, isolation boundaries, and observability.

Pattern cards (trigger → action → observability → recovery)

Rail protection is a policy: threshold + delay + action + evidence

Rail-level protection must be defined as a repeatable policy, not a list of acronyms. Each protection path should specify what is detected (UV/OV/OC/OT), how long it must persist (deglitch/blanking), what action is taken (hiccup, latch-off, or limiting policy), and what evidence is recorded (snapshot + counters). This prevents “reset storms” and enables first-cause diagnosis.

How to set thresholds and delays (rail-level template)

Thresholds should be chosen with a clear boundary between normal transient behavior and true fault conditions. Delays must prevent false trips without masking real failures. Use separate windows for startup and runtime.

Action selection: hiccup vs latch-off (and why automatic retry can be risky)

Safe state policy: RESET first or rail-off first?

Safe state must be defined as a deterministic action sequence. The correct order depends on whether the rail can remain powered long enough to perform a controlled stop. This section stays at policy level: it defines action order and evidence requirements without depending on a specific storage or device implementation.

Fault dictionary (rail-level): fault code → first action → second action → log snapshot

A fault dictionary prevents ambiguity. It turns each protection decision into a consistent playbook that can be validated in the lab.

Validation goal: prove timing predicates and evidence quality (not just “it boots”)

Lab bring-up is complete only when it proves three things: (1) sequencing and power-down behavior follow the dependency policy, (2) PG and RESET logic behaves deterministically across repeats and stress, and (3) telemetry and snapshots remain trustworthy when faults are injected.

Waveform acceptance: ramps, overshoot, PG edges, and RESET release windows

Use repeatable capture points to validate slope, overshoot boundaries, PG edge behavior (blanking/debounce), and RESET release timing relative to the defined PG windows.

• Ramp shape: slope range is consistent across runs; overshoot stays within the allowed window.
• PG behavior: no early asserts; no chatter near thresholds; edges match debounce expectations.
• RESET timing: deassert occurs only after required rails are in-window, with explicit release delay.
• Power-down: rail-off order respects dependency policy; no uncontrolled reset storms.

Injection tests: force UV/OV/OC/OT paths and verify state transitions + logs

Fault injection validates that protection policies produce the intended first and second actions, and that black-box snapshots contain the expected minimal field set for reconstruction.

PMBus alignment: compare telemetry against external instruments with declared sampling policy

Telemetry alignment is meaningful only when sampling behavior is declared. Record the averaging window, update period, and whether values represent averages or peaks, then compare against external measurements across temperature and load.

• Static offset: V/I/T deviations at nominal points.
• Thermal drift: trend consistency over temperature changes.
• Policy declaration: sampling window + avg/peak identity + config hash for comparability.

Acceptance checklist (Pass/Fail/Notes) + artifact naming rules for traceability