What this page solves

Modern boards rarely run on a single rail. A typical digital or mixed-signal design carries six to twelve supplies: FPGA or SoC core, DDR rails, I/O banks, analog front ends, auxiliary clocks and external peripherals. These rails do not live in isolation – each one biases ESD structures, isolation barriers, I/O buffers or memory arrays that expect a certain power-up and power-down order.

If the core rail rises too late while I/O is already high, ESD paths and protection diodes can conduct in reverse, causing excessive inrush and even latch-up. If DDR supplies and references are not stable before configuration starts, memory initialization can fail in ways that are hard to reproduce. If analog rails arrive last with no coordination, self-calibration routines may capture offset or gain errors that persist for the entire mission profile.

Similar issues occur on the way down. Peripherals that remain powered while logic rails collapse can back-drive signal pins, leading to undefined states and intermittent lockups at the next restart. I/O banks that lose bias in the wrong order may violate absolute maximum ratings even though every individual rail stays within spec.

The role of power sequencing and supervisors is to sit above individual converters and protection devices, enforcing a predictable and verifiable order: which rail turns on first, which ones track together, which ones must shut down last, and under which fault conditions the entire system retreats into a safe state. This layer works with enable, power-good and reset pins rather than switching nodes or magnetics.

This page focuses on defining and implementing that sequencing and supervisor layer. It treats point-of-load regulators, hold-up stages and hot-swap or eFuse devices as building blocks that supply rails and fault signals. Converter topologies, energy storage calculations and safe operating area design are covered in their own dedicated pages, while this topic concentrates on timing, dependencies and system-level behaviour.

Typical multi-rail sequencing scenarios & constraints

Most real designs fall into a few recurring patterns. Each pattern carries its own power sequencing constraints, even when the same rail voltages appear on the schematic. Understanding these scenarios helps turn vendor timing diagrams into concrete rules for enable and power-good wiring.

A first example is the FPGA or SoC plus DDR board. Here, a low-voltage core rail biases logic, one or more DDR rails supply memory arrays and references, and several I/O banks connect to external logic. Typical constraints demand that the core rail rises before or together with I/O, that DDR rails reach a valid window before configuration starts, and that all of these rails stay within range before reset is de-asserted. On power-down, I/O rails should not remain powered long after the core to avoid back-biasing internal structures.

Industrial control and PLC mainboards add different priorities. A 24 V bus may feed several intermediate rails, safety domains and field I/O supplies. Safety-related outputs or monitoring rails often need to be last-off so that emergency stop paths and diagnostics remain active until the very end of the shutdown sequence. Some isolated I/O rails must power up before the CPU rail to guarantee that outputs stay in a known-safe state when the controller comes alive and configures its pins.

Communication and server boards add yet another layer. Compute rails, management rails and backplane supplies may come from different PSU modules or redundant sources. Board-level sequencing must ensure that management or BMC rails are first-on and last-off so that telemetry, logging and remote control remain available across hot-plug events and brown-outs. Core and memory rails still require strict relationships, but now these relationships span domains fed by independent upstream sources.

Across these scenarios, constraints can be grouped into a small set of patterns: tracking, where one rail follows another within a defined window; staggered enables, where large rails are delayed by tens of milliseconds to reduce inrush; and first-on/last-off rules for safety or management domains. This page focuses on expressing such timing relationships and enforcing them with sequencers and supervisors, without diving into converter topologies, efficiency tuning or layout, which are handled by dedicated power-stage pages.

Power-good signals, thresholds & window supervisors

Power-good signals sit between raw converter behavior and sequencing decisions. A DC-DC regulator may expose an internal PG pin, a discrete supervisor may monitor one or more rails, and a dedicated window supervisor can enforce a tighter valid range for precision or safety-critical domains. All of these devices convert analog voltage into a digital view of whether a rail is usable, but their thresholds, hysteresis and delays differ significantly.

Simple undervoltage supervisors usually assert reset when a rail drops below a single threshold and release it once the voltage rises again with some hysteresis. Window supervisors define a pass band between Vmin and Vmax; the rail is considered good only inside that band, and any excursion below or above forces the output low. This behavior is valuable for DDR supplies, reference rails and other nodes where both undervoltage and overvoltage are problematic for long-term reliability or data integrity.

Threshold accuracy defines how close a rail can be allowed to approach its specified limits before supervisors begin to react. Loose accuracy plus multiple stages of supervision can consume much of the safety margin that was assumed during timing analysis. Hysteresis and internal glitch filtering determine whether short transients and ripple are ignored or translated into real PG drops. In a noisy environment, insufficient hysteresis can cause repeated fault entries and exits even though the underlying rail never leaves its guaranteed operating region.

Propagation delay is equally important for sequencing. The time between a rail crossing a threshold and the corresponding PG or reset output changing can range from microseconds to many milliseconds, especially when built-in filters, blanking periods and deglitch timers are active. When several stages of supervisors and AND gates are cascaded, these delays add and may extend the actual reset release or fault reaction well beyond the apparent timing suggested by voltage ramp plots alone.

Multiple PG signals are typically combined to form a global ALL_GOOD condition that governs resets, configuration start and system enables. It is common to group related rails, such as core and memory, into one composite PG and to treat analog or reference rails as a separate group. Logical AND then ensures that reset is released only when every required rail lies within its defined window, while OR paths can trigger immediate fault handling when any monitored rail exits its safe band. The details of this logic, including polarity and open-drain wiring, strongly influence how predictable sequencing remains under normal operation and corner cases.

Sequencing topologies: daisy-chain, tracking & timed enables

Once power-good information is available, the next step is to decide how rails will actually be turned on and off. Several topologies are used in practice: simple daisy-chain connections, explicit timed enables based on delay elements or dedicated sequencer ICs, and tracking schemes that keep rails moving together rather than strictly before or after each other. Each approach carries distinct implications for fault behavior, timing accuracy and ease of modification late in the design cycle.

In a daisy-chain topology, the PG output of one rail directly drives the enable or shutdown pin of the next rail. This method is attractive because it uses minimal components and visually encodes dependencies in the schematic. However, any spurious PG drop on an upstream rail propagates through the chain, potentially causing repeated restart cycles further downstream. The deepest rail in the chain tends to inherit the slowest response, and debugging which rail failed first can become difficult once multiple levels of PG and enable are linked in series.

Timed-enable schemes introduce explicit delays between rails. At the simplest level, an RC network and a threshold device can provide a coarse delay between a global power-good and a particular enable pin. More sophisticated designs use dedicated sequencing controllers or digital power managers with per-rail delay and dependency settings. These devices allow absolute on/off timing to be tuned without rewiring the board and can coordinate fault retries or latched shutdown across many rails. The trade-off is extra cost and configuration effort, which is often justified in systems with complex bring-up procedures or strict inrush limits.

Tracking schemes take a different angle by shaping ramp profiles rather than only defining order. Two or more rails may be forced to rise with matched slopes or fixed ratios so that the voltage difference between domains never exceeds a specified limit. This behavior is valuable in FPGA or SoC designs where core and I/O banks must not be biased far apart, and in mixed-signal designs where bias and reference rails must follow each other during startup. Tracking relies on converter features such as dedicated tracking pins or shared ramp references, and it pushes requirements onto compensation and soft-start design even though those details are handled in the power-stage domain.

In practice, real systems often combine these topologies. A small number of rails may use true tracking, critical groups may be sequenced with programmable delays, and lower-priority peripherals can still rely on simple daisy-chain connections. The key is to base every choice on clear timing constraints, supervised PG signals and a documented view of how the board should behave during startup, shutdown and fault recovery, rather than letting enable wiring evolve organically with each design revision.

Fault response, retries and latch-off strategies

From a sequencing perspective, fault handling is largely a question of classifying events and assigning a response profile. Short transients, cold-start difficulties and momentary line disturbances are candidates for limited automatic retries. Repeated hard short circuits, sustained overtemperature conditions and faults that recur after cooldown belong in a latched category that requires inspection before the system returns to service. The distinction is not made by the converter itself but by how power-good, fault and temperature signals are interpreted by the supervisory layer.

Practical schemes start by counting how often a rail fails to reach its power-good window within a defined time or how frequently an eFuse or hot-swap device asserts FAULT. A single failure during initial startup can be retried after a brief delay to overcome inrush-related effects or marginal connections. A cluster of closely spaced faults or repeated failures after thermal cooldown is a strong indicator of wiring mistakes, damaged loads or persistent shorts. In that case, the sequencer should move into a latched fault state, ensure that affected rails are disabled and expose a clear diagnostic condition to a host controller or service interface.

Fault handling also determines whether the entire system powers down or only the affected domain is disconnected. A global shutdown strategy is common when core logic, memory and I/O rails are tightly coupled and any partial loss risks back-biasing or latch-up. Local containment is more appropriate when the design cleanly separates domains, such as field I/O, auxiliary peripherals or noncritical sensors. In that case, a faulted rail can be shut down or retried independently while core compute rails and communication links remain active to report alarms and log events. Clear grouping of rails into core, safety, I/O and auxiliary domains is essential before adopting selective shutdown.

Supervisors, sequencers and eFuse or hot-swap controllers must therefore share information. Protection devices indicate whether a rail has hit current limit, tripped on SOA constraints or opened a series pass element, while the sequencer tracks how many such events occur and how long recovery takes. Based on this view, the sequencer can assert global or local shutdown signals, decide whether to attempt another startup cycle and update system fault status. The power tree remains protected by local hardware, but the higher-level state machine defines whether the board recovers automatically, enters a degraded mode or remains safely latched until maintenance.

Reset architecture, brown-out and window watchdogs

Reset behavior ties the power system to digital startup and recovery. Power-on reset ensures that MCUs, SoCs and FPGAs remain held in a defined state until all critical rails have entered their valid windows and clocks are stable. Brown-out reset responds when supply voltages sag into a region where logic may still switch but no longer meets timing or noise margins. External supervisors and internal POR/BOR circuits together define which combinations of rail and clock conditions qualify the system to leave reset, and which require an immediate return to a safe baseline.

Simple designs may base reset only on a single VDD rail, but multi-rail boards benefit from a composite approach. Core, memory and I/O rails can be grouped into power-good domains, combined by logic into an ALL_GOOD signal and then stretched by a reset supervisor to guarantee a minimum stable time before release. Additional inputs such as clock lock indicators or reference voltage windows can be included where required. This arrangement allows reset de-assertion to be tied directly to the power sequencing intent rather than a single rail crossing a threshold at an unspecified ramp rate.

Watchdogs complement POR and BOR by supervising runtime behavior instead of static voltage levels. A basic watchdog confirms only that firmware continues to toggle a pin or write a register within a maximum interval. A window watchdog adds a lower bound and accepts kicks only within a defined time window, allowing it to detect both stalls and runaway loops that execute too quickly. In safety-related and communication-centric systems, window watchdogs provide finer-grained coverage that aligns with expected task timing and protocol cycles.

At the board level, reset architecture should treat watchdog resets as one class of event alongside brown-out and supervisor faults. Some watchdog expirations justify resetting only a processor or logic device, leaving power rails on. Others may require a coordinated power cycle of selected domains or the entire system. Mapping these decisions into a clear reset tree, with global and local reset lines feeding MCU reset pins, FPGA PROGRAM or configuration inputs and peripheral reset nets, ensures that every power and logic anomaly leads to a predictable and verifiable recovery path rather than ad hoc reactions scattered across the design.

Hold-up, early power-fail warning and controlled shutdown

A well-designed hold-up scheme gives the sequencer a short but predictable window between a power-fail indication and the point where core rails can no longer be maintained. Signals such as PWR_FAIL or AC_FAIL are asserted when upstream input conditions fall outside an acceptable range, but while the bulk capacitor or backup source can still sustain the load for a defined time. The role of the sequencing and supervisory layer is to use that window to preserve state, reduce load and bring rails down in an ordered way instead of allowing an uncontrolled collapse.

Upon receipt of a power-fail warning, the sequencer or a dedicated power-fail monitor typically raises an interrupt or status line to the main MCU or SoC. Firmware then suspends noncritical tasks, stops accepting new high-power work and commits a minimal set of state information to nonvolatile storage where available. The emphasis is on a short, bounded checklist: closing open transactions, logging that the shutdown was abnormal and preparing the application to resume cleanly on the next startup rather than attempting full diagnostic dumps that would consume hold-up energy.

In parallel, the sequencer can actively reduce power demand by disabling nonessential rails and peripherals. Field I/O, backlight, motor drivers, auxiliary 5 V or 12 V supplies and other high-current domains are prime candidates for early shutdown. Retaining only the rails needed for core processing, safety logic and critical communication extends the effective hold-up time and creates headroom for orderly shutdown of the remaining domains. The exact grouping of rails into early-off, late-off and always-on categories is a key part of the sequencing strategy and should reflect both power priorities and back-bias constraints.

As the hold-up window nears its end, the sequencer initiates a final, deterministic power-down sequence. Noncritical domains are already off; remaining rails are then turned off in an order that avoids stressing devices through reverse-bias or uncontrolled signal levels, with core logic rails typically among the last to be removed. Where a small standby or real-time clock supply is present, that domain can remain powered to support wake logic or time keeping while all other rails are fully de-energized. The detailed energy budgeting and capacitor sizing that define how many milliseconds are available for this process are covered in the dedicated Hold-Up / Backup for Adapters subpage.

Digital power sequencers and PMBus supervisors

Digital power sequencers and PMBus supervisors extend traditional sequencing by adding programmability, telemetry and logging. Instead of fixing delays, thresholds and fault responses in resistors and capacitors, these devices implement multi-rail timing tables and state machines in firmware or configurable logic. They drive enable pins, margining controls and in some cases the PWM signals of digital power stages, allowing behavior to be tailored in the lab or even adjusted in the field without altering the PCB.

Through interfaces such as PMBus or I²C, a digital sequencer can define the order in which rails turn on and off, per-rail delay times, ramp characteristics and dependencies on power-good or clock-lock conditions. Undervoltage, overvoltage and overcurrent limits, as well as the number and spacing of automatic retries, are similarly configured as data rather than hardwired. The same hardware platform can therefore support multiple product variants, operating modes or derating profiles by loading different configuration sets during manufacturing or commissioning.

Digital supervisors also monitor rail voltages, currents and temperatures and maintain fault logs. When a rail fails to reach its target, trips a protection limit or experiences repeated brown-out, the device can record which rail was involved, what limits were exceeded and how many times the event has occurred. Host controllers can read these logs over PMBus to distinguish between rare transients and systematic issues, and to correlate shutdowns with environmental conditions or system-level events. This information feeds back into improved sequencing policies and more informed maintenance decisions.

At the system level, digital sequencers act as the coordination layer between individual power stages and higher level controllers. They translate power-up and power-down recipes, safety limits and hold-up strategies into actual enable and shutdown actions across all rails. Detailed PMBus command sets, digital control loop design and complete digital PSU architectures are covered in the dedicated Digital PSU Controller (PMBus) subpage; the focus here is on the sequencing and supervisory roles that these devices play in a multi-rail power tree.

Design checklist & IC role mapping

This section is intended as a one-page checklist for planning power sequencing and supervision. The questions help capture how many rails are present, which ones require tracking or staggered delays, how power-good and reset trees are structured and whether hold-up and watchdog mechanisms are needed. Once these requirements are clear, suitable sequencer, supervisor and rail manager ICs can be selected with appropriate thresholds, timing accuracy, polarity, output structure and qualification level.

1. Rail inventory and basic specifications

• How many distinct rails are present on the board? (core, memory, I/O, analog, aux, safety-related)
• For each rail, what are the nominal voltage, worst-case current and allowed tolerance (for example ±2 % or ±5 %)?
• Which rails share a common upstream supply or connector and should be treated as a group from a hold-up perspective?
• Which loads are safety-critical or mission-critical and which can be considered noncritical or shed first?

2. Sequencing relationships and tracking requirements

• Which rails must track each other during ramp-up or ramp-down to avoid back-bias (for example core vs I/O, analog vs reference)?
• Which rails only require simple delays (staggered enables) to reduce inrush and limit bus droop?
• Are there any “last-off / first-on” rails, such as RTC, always-on logic or safety control domains?
• Do any devices specify explicit timing constraints between their rails (datasheet requirements for SoCs, FPGAs or memories)?

3. Power-good sources and supervision strategy

• For each rail, will power-good come from the DC-DC converter itself or from an external voltage supervisor?
• Which rails require window supervision (undervoltage and overvoltage) rather than a simple undervoltage-only monitor?
• How will individual PG signals be combined into domain-level and system-level ALL_GOOD signals?
• Are clock-valid or PLL-lock indicators also required as part of the conditions for releasing resets?

4. Reset architecture and reset domains

• How many reset domains are required? (global system reset, processor reset, FPGA configuration, peripheral resets)
• Which events should trigger only a local reset (for example watchdog timeout on an MCU)?
• Which events should trigger a full system reset or coordinated power cycle (for example loss of core rail or ALL_GOOD)?
• Do processors, FPGAs or SoCs require dedicated reset or configuration pins to be tied directly to supervisor outputs?

5. Hold-up, power-fail warning and shutdown behavior

• Is a hold-up or backup energy source present and does the upstream PSU expose PWR_FAIL or AC_FAIL signals?
• How many milliseconds of warning are available between power-fail assertion and the loss of core rails?
• What is the minimum time needed for firmware to save critical state and for the sequencer to turn off noncritical rails?
• Which rails should be shed immediately after a power-fail warning and which should remain active until the final shutdown step?

6. Watchdog requirements and system reaction

• Is an independent watchdog device required or is the on-chip watchdog of the MCU or SoC sufficient?
• Should the watchdog be a classic design or a window watchdog that detects both stalled and runaway code?
• When the watchdog expires, should only the processor be reset or should selected rails be power-cycled by the sequencer?
• Should watchdog events be logged or exposed to a system controller via status pins or a serial interface?

7. IC selection criteria for sequencers and supervisors

• Required rail count and number of monitored channels.
• Threshold accuracy, temperature drift and hysteresis requirements for critical rails.
• Propagation delay, reset timeout and programmable delay range.
• Output polarity and structure (active-high or active-low, open-drain or push-pull).
• Supply voltage range, quiescent current and package size.
• Qualification level and operating temperature range (for example industrial, extended or AEC-Q100 automotive).
• Availability of PMBus / I²C / SPI interfaces, NVM configuration and evaluation tools.

IC role mapping for power sequencing and supervision

Once the checklist has been answered, suitable ICs can be chosen for each role in the power tree. The examples below are representative families only; final selection should always be based on current datasheets, parametric filters and availability.

Multi-rail power sequencer ICs

Multi-rail sequencers coordinate enable, delay and basic fault handling across several rails. They are useful when most rails already have suitable DC-DC controllers but need a central timing engine.

• Typical features: 4–16 rail support, programmable on/off delays, dependency graphs, monitoring inputs and consolidated ALL_GOOD outputs.
• Example IC families (for reference): LTC2927, LTC2937, ADM1066/ADM1186 rail-sequencing controllers; UCD9090/UCD90120A-style rail managers; ISL6123/ISL6146-class multi-channel power controllers.

Single- and dual-channel window supervisors

Window supervisors monitor one or two rails with defined undervoltage and overvoltage thresholds and generate clean reset or power-good signals. They are suited to core, memory, reference and analog rails that need tight voltage control.

• Typical features: fixed or adjustable windows, precision thresholds, built-in delay and manual reset options.
• Example IC families (for reference): TPS37x/TPS38x window supervisors (for example TPS3702/TPS3703), ISL8800/ISL8801-class voltage supervisors and ADM67xx/MCP13xx-style reset monitors.

MCU / SoC supervisors with watchdog

Dedicated supervisors for processors combine supply monitoring with watchdog timing and sometimes window watchdog functionality. They are often used in safety and industrial designs where an independent device must decide whether the main controller is behaving correctly.

• Typical features: accurate reset thresholds, programmable watchdog timeout, optional window mode, separate reset outputs for core and peripherals.
• Example IC families (for reference): MAX706/MAX708/MAX16055-style supervisor plus watchdog devices; TPS382x/TPS385x/TPS386000-series processor supervisors; MCP1319/MCP1320-class watchdog supervisors.

Digital rail managers and PMBus-based sequencers

Digital rail managers implement sequencing, margining and telemetry in firmware, expose PMBus or I²C control and log faults for later analysis. They are ideal when a board has many rails, needs in-field reconfiguration or requires detailed logging of power events.

• Typical features: multi-rail enable and soft-start control, per-rail UV/OV/OC thresholds, fault retry policies, telemetry for voltage/current/temperature and nonvolatile fault logs.
• Example IC families (for reference): LTC2974/LTC2977 digital power system managers, UCD9090/UCD90120A-style PMBus rail managers and ZL200x/ZL610x-series digital power management devices.

Power sequencing & supervisor FAQs

The questions below highlight common design decisions for multi-rail power sequencing and supervision. They point back to the scenarios, topologies, fault handling and IC roles discussed in the previous sections and help frame practical trade-offs when selecting sequencers, supervisors, watchdogs and PMBus rail managers.

1. When is a dedicated power sequencer IC needed instead of simple PG-chaining?

A dedicated power sequencer IC is recommended once the board has more than a few rails, complex dependencies or strict tracking requirements. When core, DDR, I/O and analog rails must follow a defined recipe, or when fault logging, retries and multiple power-up profiles are required, a central sequencer is far more robust than simple PG-chaining.

2. How tight must rail tracking be for FPGA core and I/O supplies?

FPGA datasheets usually require core rails to be valid before I/O rails, and they often limit how far I/O pins may be driven while core is still ramping. As a guideline, aim for tightly matched ramp rates and ensure I/O power-good is only asserted after core rail is inside its window and stable for several microseconds.

3. What are the benefits of window supervisors over simple undervoltage monitors?

Window supervisors monitor both undervoltage and overvoltage and only release reset when the rail sits inside a defined good window. This prevents half-supply or overvoltage operation on sensitive rails such as references, DDR and precision analog. Compared with simple UV monitors, they give clearer pass or fail decisions and reduce the risk of marginal behavior.

4. How should fault retries be limited to avoid stressing DC-DC converters?

Fault retries should be limited to a small number of attempts with generous delay between them so converters and hot-swap FETs can cool and magnetics can reset. Allow a few controlled restarts for benign cold-start issues, then latch the fault and require manual or host intervention rather than hammering on a short or overloaded output.

5. How should sequencing handle a rail that never reaches power-good during startup?

If a rail never reaches power-good during startup, the sequencer should time out rather than waiting indefinitely. After the timeout, it can attempt a limited number of restart cycles, log the fault and then either shut the whole system down or isolate the failing rail. The chosen policy should be documented and reviewed for the application.

6. When should reset de-assertion be tied to all rails instead of only the core rail?

Reset de-assertion should depend on all critical rails when incorrect voltages on memory, I/O or analog domains could corrupt data or create unsafe states. In that case, a combined ALL_GOOD signal, including window supervisors and clock-valid flags, is used to release resets. Limiting reset only to the core rail fits simpler or loosely coupled systems.

7. How can watchdog timeouts be coordinated with power-fail warnings to avoid data loss?

Watchdog timeouts and power-fail warnings should be treated as separate but coordinated events in the reset strategy. When a watchdog expires, the system should still follow a minimal data protection routine, such as flushing logs, and avoid immediate power cycling if a power-fail window is active. Clear priority rules prevent overlapping recovery actions from causing data loss.

8. What timing margin is recommended between a power-fail warning and actual rail collapse?

Recommended timing margin between a power-fail warning and rail collapse is the sum of measured shutdown needs plus safety headroom. First determine how long firmware and the sequencer require to save state and shed noncritical loads, then add margin for tolerances and aging. This timing must be validated in real drop tests rather than assumed from calculations alone.

9. When does it make sense to move sequencing into a digital PMBus controller or rail manager?

Moving sequencing into a digital PMBus controller or rail manager makes sense when there are many rails, multiple operating profiles or strong requirements for telemetry and fault logging. In server, telecom and industrial racks, digital managers simplify configuration changes and remote diagnostics. For small, static designs a simpler analog sequencer or PG-chaining often remains more economical.

10. How should sequencing handle rails powered from different upstream sources?

When rails come from different upstream sources, such as main PSU, PoE or USB-C, the sequencing plan must account for source selection and backfeed prevention. Ideal-diode or ORing stages define which source is active, while the sequencer applies different timing profiles per mode. Every combination of sources should be tested for clean power-up, switchover and shutdown.

11. What IC features matter most for automotive or industrial power supervisors?

For automotive and industrial supervisors, wide temperature range, AEC-Q100 or equivalent qualification and strong EMC robustness are primary concerns. Precision thresholds and low drift help maintain correct reset behavior over life and temperature. Diagnostic features such as reset cause flags, watchdog status and separate reset outputs for core and safety domains are valuable for functional safety analysis.

12. How should a multi-rail power-up and power-down timing plan be documented and validated?

A multi-rail timing plan is best documented with a combined rail table, timing diagram and reset tree. The table lists each rail voltage, sequence order and dependencies; the diagram shows power-up and power-down edges with key delays and margins; the reset tree ties ALL_GOOD, clock-valid and watchdog outputs into each reset domain, then guides laboratory validation.