← Back to: Supervisors & Reset
What It Solves
Typical failures → cost → actionable mitigations for a multi-rail power sequencer. Define up/down sequences, unify PG semantics, set tolerances, and provide a repeatable validation template.
Problem: I/O Back-Power
Symptom: I/O drives high before core rails.
Cost: Latch-up, hidden current, early field returns.
Mitigation: Enforce Vref→Vio→Vcore sequence; release reset only after PG vote.
Problem: PG Chatter
Symptom: Reset toggles due to PG glitches.
Cost: Boot loops, sporadic faults, low yield.
Mitigation: Unify PG to Active-High OD + pull-up; deglitch ≥ 1 ms before aggregation.
Problem: RC Chain Drift
Symptom: Timing differs across temp/boards.
Cost: Unstable bring-up, rework, delays.
Mitigation: Specify ±10% timing tolerance or move to programmable sequencer profile.
Problem: Cross-Brand Mismatch
Symptom: PG polarity/delays differ after part change.
Cost: Regression bugs, NPI slips.
Mitigation: Maintain PG/delay mapping in NVM/script and re-validate waveform windows.
Sequencing Basics
Clarify core terms and signal semantics: power-up/down, ratiometric tracking, PG-OR voting, and glitch filtering. Standardize names and test probes before design reviews.
Power-up / Power-down
Formal order for enabling/disabling rails; reference who leads and who follows.
Probe: CH1/CH2 rails; markers on Enable-After / Power-Down-Before.
Ratiometric Tracking
Maintain ΔV within a window during ramps; prevents I/O back-power and lock-ups.
Probe: ΔV cursor template; record max deviation.
Daisy-chain
PG→EN chain controls order only; no guarantee on level ratios—don’t confuse with tracking.
Probe: logic analyzer on PG/EN edges.
PG-OR & Glitch Filter
Unify PG to Active-High (OD + pull-up). Deglitch ≥ 1 ms before aggregation to avoid chatter.
Probe: PG_agg with deglitch window; count glitches < t_glitch_max.
Architectures: A/B/C
Three implementation tiers and their fit. Use the decision matrix to balance rail count, risk, maintainability, and cost; validate with rollback policies.
When to pick A
≤3 rails, low risk, fast proto, relaxed tolerances. Validate with ±10% timing window.
When to pick B
3–6 rails or mid/high risk; need rollback/retry and stable tracking windows.
When to pick C
>6 rails, multi-SKU, remote tuning/diagnostics, audit logs; profile in NVM.
| Crit | A | B | C | Notes |
|---|---|---|---|---|
| Rail count | ≤ 3 | 3–6 | > 6 | Mix allowed with guardrails |
| Risk level | Low | Mid/High | High | Critical I/O or ref domains → B/C |
| Maintainability | Low | Mid | High (remote) | Logs/PMBus favor C |
| BOM budget | Low | Mid | High | Prototype vs mass production |
Slew & Ramp Control
Quantify dV/dt, limit inrush under ILIM margin, enforce ratiometric tracking windows, and verify crossing points (t90/t95) across temperature and loads.
| Rail | V_target | SS_cap | dV/dt | TrackTo | ΔV_max | T_rise | t90 / t95 | Note |
|---|---|---|---|---|---|---|---|---|
| Vref | 1.2 V | CSS=… | … V/ms | — (root) | k·V (e.g., 5%) | … ms | … / … | Set reference first |
| Vio | 3.3 V | CSS=… | … V/ms | Vref (ratio) | k·V (e.g., 5–10%) | … ms | … / … | Hold ΔV within window |
| Vcore | 0.9 V | CSS=… | … V/ms | Vio (ratio) | k·V (tight) | … ms | … / … | Release reset after PG vote |
dV/dt target
Ensure I_inrush ≤ ILIM_margin while meeting T_boot. Use I_inrush ≈ C_load · dV/dt to size SS.
Tracking window
Enforce |ΔV| ≤ ΔV_max (e.g., 5–10% of Vtarget); capture t90/t95 for acceptance.
Validation cursors
Scope template: CH1/CH2 ramps, ΔV(t) cursor, markers at 90/95% crossing; test at −40/25/85 °C.
Dependencies & Order
Enforce the industry sequence Vref → Vio → Vcore on power-up and strict reverse on power-down. If peripherals depend on the host, release reset only after PG voting meets the acceptance window; preserve sensitive analog domains for T_hold.
| Rail | Role | Enable-After | Power-Down-Before | T_hold | Depends_on | Notes |
|---|---|---|---|---|---|---|
| Vref | Reference | 0 ms (root) | Last | ≥ target | — | Keep until I/O/Core safe |
| Vio | I/O domain | after Vref (±10%) | before Vref | ≥ spec | Vref | Avoid back-power |
| Vcore | Core domain | after Vio (±10%) | before Vio | ≥ spec | Vio | Release reset after PG vote |
| Analog | Sensitive | parallel / guarded | before final off | T_hold ≥ spec | Vref | Keep ref valid for ADC/PLL |
PG Aggregation & Reset Tree
Normalize PG to Active-High via open-drain + pull-up, deglitch each rail before aggregation, then buffer/fan out into the reset tree with level-domain compatibility.
| Rail | PG_Type | Polarity | Debounce_ms | Pullup_k | Fanout | Level | Needs_Buffer | Notes |
|---|---|---|---|---|---|---|---|---|
| Vref | OD | AH | ≥ 1 | 10–47 | 2 | 3.3 V | No | Reference ready first |
| Vio | OD | AH | ≥ 1 | 10–47 | 3 | 3.3 V | If >10 cm | Schmitt buffer across boards |
| Vcore | OD | AH | ≥ 1 | 10–47 | 4 | 1.8 V | Yes | Level-translate to 1.8 V tree |
Normalize polarity
Convert all PGs to Active-High before aggregation. Prefer OD + pull-up for safe voting.
Deglitch before OR
Per-rail deglitch ≥ 1 ms; aggregation node should see clean signals only.
Reset fanout & levels
Size the buffer for fanout; ensure compatibility across 1.8/3.3/5 V reset domains.
Fault Rollback & Retry
On any per-rail timeout or violation, execute Rollback → Wait(backoff) → Retry with N_max cap. Roll back at least one upstream level, keep reset asserted, and log Fail-Code / rail-id / timestamp. Lock out on critical codes or exhausted retries.
| rail_id | Timeout_ms | N_max | Backoff_seq | Backoff_max_s | RollbackDepth | LatchOnFail | LogFields |
|---|---|---|---|---|---|---|---|
| Vcore | 120 | 3 | 0.5,1,2,4 | 8 | 1 | 0 | code,rail,ts,k,temp,load |
| Vio | 150 | 2 | 0.5,1,2 | 4 | 2 | 1 | code,rail,ts,k |
CriticalCode
Immediate Lockout on over-temp or crowbar events; require manual clear.
Snapshot
Store PG_agg and Reset_out at fail instant for audit.
Cooling-off
Keep domains low during Wait(backoff) to avoid half-powered states.
Validation Playbook
Channel map: CH1=Vcore, CH2=Vio, CH3=PG_agg, CH4=Reset_out. Verify t_lead, t_lag, ΔV window, t_reset_rel, and the Rollback→Wait→Retry loop under injected faults.
| ID | Load_A | Temp_C | Fixture_rev | Shot_png | CSV_path | JSON_path | t_seq (lead/lag/reset) | ΔV_window | Glitches | Pass | Comment |
|---|---|---|---|---|---|---|---|---|---|---|---|
| ps-batch1-01 | 0.3 | 25 | A1 | /shots/…/01.png | /csv/…/01.csv | /json/…/01.json | 12/18/22 ms | ≤ 5% | 0 | Yes | Nominal case |
Channel assignment
CH1(Vcore), CH2(Vio), CH3(PG_agg), CH4(Reset_out); short ground leads; digitize PG/Reset.
Cursor template
Auto place t90/t95/ΔV/t_lead/t_lag/t_reset_rel; export PNG+CSV+JSON for audit.
Fault campaign
Inject OC / UV / PG_glitch / Timeout; verify Rollback→Wait→Retry and N_max limit.
Cross-Brand Options & Migration Notes
When migrating sequencing/monitoring, align PG semantics (prefer OD→Active-High), timing windows (Enable-After / Min-Stable / Max-Timeout / t_reset_rel), retry policy (Rollback / Backoff / Latch), slew/tracking (per-rail dV/dt & ΔV window), and NVM/PMBus scripts.
Signal semantics
Normalize PG to OD + pull-up → AH; verify level (1.8/3.3/5 V) and reset-tree fanout.
Timing windows
Port over Enable-After / Min-Stable / Max-Timeout / t_reset_rel from scope evidence, not from memory.
Retry policy
Keep Rollback→Wait(backoff)→Retry(k) and N_max/Latch behavior consistent across brands.
Slew & tracking
Match dV/dt, SS-Cap, ratiometric tracking and ΔV window at cross-points; validate in Chapter 8.
NVM/PMBus
Map profiles to target’s PMBus/I²C/OTP; re-scale telemetry (mV/LSB, thresholds, filters).
| Brand | Family / Example PNs | SequencingMethod | PG_Polarity | Config | Notes |
|---|---|---|---|---|---|
| TI | UCD9090, UCD90120A | PMBus Sequencer/Monitor (10–12 rails) | OD→AH (recommended) | PMBus profiles, Fusion GUI | Logs & ADC telemetry; map backoff/latch in script. |
| Renesas | ISL70321SEH, ISL73321SEH | Hardware delay/sequence (4 rails, cascadable) | OD/AH per rail (unified to AH) | Passive timing (R/C), ext. MCU for logs | Deterministic; suited to harsh/space/auto. |
| NXP | PF8100, PF8200 (family) | PMIC with built-in up/down order (NVM) | OD→AH (normalize) | OTP/NVM (Rank/rail setup) | Match SoC rails (i.MX/S32) and DVS order. |
| ST | STPMIC1 (family) | PMIC rank-based sequencing (NVM) | OD→AH (normalize) | NVM ranks + IRQ/PG lines | Align rank steps to legacy ms delays. |
| Microchip | MIC2800, MCP16502 | µP Sequencer/Monitor · PMIC with order | Normalize to AH | I²C/IRQ (MIC2800), NVM (MCP16502) | Good for 2–6 rails & embedded MPU. |
| onsemi | NCP308/NCV308 (supervisor), NCP45520/21 (load switch) | Distributed: supervisor + soft-start switch + MCU logic | Unify to AH via OD bus | Discrete config (R/C + GPIO) | Cost/availability oriented; validate slopes & PG bus. |
| Melexis | — | Not a power sequencing line | — | — | Declare non-applicable to avoid scope creep. |
Profile remap
Convert PMBus profiles to target NVM/OTP ranks; re-scale telemetry and alarm thresholds.
Reset tree
Unify PG polarity before aggregation; buffer long branches; level-translate for 1.8/3.3/5 V domains.
Backoff & latch
Retain Rollback/Retry cadence and Latch decisions; document in migration log.
IC Shortlist (Series & Reasons)
Only list real series and representative PNs. Selection must be confirmed with official datasheets and Chapter 8 validation before pilot runs.
TI — UCD9090 / UCD90120A
Why: 10–12 rail PMBus sequencer/monitor, ADC telemetry & logging, mature Fusion GUI.
- UCD9090 (10-rail)
- UCD90120A (12-rail)
Renesas — ISL70321SEH / ISL73321SEH
Why: Deterministic hardware sequence with precise delays; suited to harsh reliability.
- ISL70321SEH (rad-hard family)
- ISL73321SEH (auto/space lineage)
NXP — PF8100 / PF8200
Why: PMIC with built-in NVM sequencing for i.MX/S32 platforms; single-chip >6 rails.
- PF8100
- PF8200 (family member)
ST — STPMIC1 (family)
Why: Rank-based sequence with NVM; proven with STM32MP/SoC platforms.
- STPMIC1A / STPMIC1B (variants)
Microchip — MIC2800 / MCP16502
Why: Light-weight µP sequencer/monitor (MIC2800) and PMIC with order (MCP16502) for 2–6 rails.
- MIC2800-x (sequencer/monitor)
- MCP16502 (multi-rail PMIC)
onsemi — Supervisor + Load-Switch
Why: Modular sequencing via supervisor thresholds + soft-start load switches; good availability.
- NCP308 / NCV308 (voltage supervisor)
- NCP45520 / NCP45521 (PG load switch)
Melexis — (N/A for this function)
No dedicated multi-rail sequencing/monitor families. Declare non-applicable to avoid scope creep.
| Brand | Family | Type | Key Hooks | Doc Link |
|---|---|---|---|---|
| TI | UCD9090 / UCD90120A | Sequencer/Monitor | PMBus, ADC telemetry, logging | UCD9090 DS · UCD90120A DS |
| Renesas | ISL70321SEH / ISL73321SEH | Sequencer (HW) | Precise delay, deterministic | Datasheet |
| NXP | PF8100 / PF8200 | PMIC (NVM order) | Multi-rail, OTP/NVM ranks | Datasheet |
| ST | STPMIC1 (family) | PMIC (ranked) | Rank steps, NVM, IRQ/PG | Datasheet |
| Microchip | MIC2800 / MCP16502 | Sequencer · PMIC | I²C/IRQ, small systems | MIC2800 DS · MCP16502 DS |
| onsemi | NCP308 + NCP45520/21 | Supervisor + Load-Switch | Thresholds, soft-start, PG | NCP308 DS · NCP45520/21 DS |
| Melexis | — | N/A | — | — |
Pilot first
Run Chapter 8 validation for any cross-brand change before PO; attach scope PNG + CSV + JSON.
Script parity
Keep the same PG/timeout/retry semantics in PMBus/NVM scripts to avoid field regressions.
Reset release
Unify polarity at aggregation, then release reset only after PG vote ≥ window.
Request a Quote
BOM Remarks for Procurement
Power-up order Vref → Vio → Vcore; power-down reverse. Substitutes must preserve order/delays within ±10% (unless noted). PG unified to Active-High (open-drain + 10–47 kΩ pull-up) with ≥1 ms deglitch. Sequencer profile stored in NVM/script; changing brands requires updating PG/Delay mapping before build release. Parts without track/slew are not allowed unless waveform windows are re-validated.
For AEC-Q and extended-temperature lots, verify Rollback/Retry cadence and log Fail-Code / rail-id / timestamp per Chapter 7; attach scope PNG + CSV + JSON per Chapter 8.
| Key | Text | Owner | Must-Have? | Evidence |
|---|---|---|---|---|
| SEQ_ORDER | Vref→Vio→Vcore; reverse on power-down | EE | Yes | Scope PNG |
| DELAY_TOL | Enable-After / Min-Stable / Max-Timeout within ±10% | PE | Yes | CSV |
| PG_POLICY | PG = OD → Active-High; pull-up 10–47 kΩ; deglitch ≥1 ms | EE | Yes | PNG + CSV |
| TRACK_SLEW | Ratiometric tracking and per-rail dV/dt required; ΔV window enforced | EE | Yes | Scope PNG |
| PROFILE_CTRL | PMBus/NVM profile updated & re-signed before build release | Proc | Yes | Signed JSON |
| RETRY_POLICY | Rollback→Wait(backoff)→Retry(k); N_max & Latch per Chapter 7 | EE | Yes | Log JSON |
| VALIDATION | Attach Chapter 8 deliverables: PNG + CSV + JSON | SQE | Yes | PNG + CSV + JSON |
| CHANGE_TRIGGER | Any brand/family/PG/track capability change requires re-validation | PE | Yes | ECR |
Frequently Asked Questions
How strict should production tolerances be for up/down order and delays?
Keep the up/down order fixed and treat delays as a window. Start with ±10% for Enable-After / Min-Stable / Max-Timeout and tighten to ±5% on fragile platforms. Always base limits on Chapter 8 scope evidence rather than nominal design values.
Track vs. delay-chain—when does ratiometric tracking prevent real failures?
Use ratiometric tracking when peripherals are sensitive to cross-points: ADC references, high-speed PHYs, or bias domains. Tracking holds ΔV within a proportional window during ramps, avoiding early/late crossings that lock up devices. Verify the window with scope cursors and load corners.
What PG polarity and deglitch window minimize cross-brand surprises?
Normalize the PG bus to open-drain → Active-High with a 10–47 kΩ pull-up and at least 1 ms deglitch. Buffer long branches and level-translate between 1.8/3.3/5 V domains. Release resets only after a PG vote meets the acceptance window.
How to size slew/soft-start so inrush stays under ILIM while meeting boot-time?
Choose dV/dt so inrush ≤ ILIM_margin yet overall boot time meets system requirements. Tune soft-start capacitance or switch ramp control, then validate with min/typ/max load and temperature. If limits conflict, prioritize inrush safety and adjust early-boot dependencies.
Rollback choice: partial vs. total power-down after a rail timeout?
Prefer a partial rollback one or two stages up to recover quickly and preserve logs. Escalate to total shutdown only after repeated failures or when safety domains are affected. Document the chosen cadence in scripts and capture Fail-Code, rail-id and timestamp.
How many retries before latch-off for field reliability targets?
Use a small N_max (typically two to three) with exponential backoff such as 0.5/1/2/4 s. Latch immediately for hazardous faults, or after exhausting retries for non-recoverable rails. Ensure telemetry records each attempt for failure-rate analysis.
Can RC-based rails and PMBus-sequenced rails safely mix in one product?
Yes, provided you unify PG semantics, control RC tolerance, and validate ΔV windows at crossings. Treat RC rails as wider-tolerance members and let the sequencer enforce release timing and retries. Re-validate after any brand or family change.
What fixture/probing proves margin across temp/load without over-engineering?
Use four channels: Vcore, Vio, PG_agg, Reset_out. Sweep −40/25/85 °C and min/typ/max load. Apply a cursor template for t_lead, t_lag, ΔV_window, t_reset_rel and export PNG+CSV+JSON. This keeps evidence minimal yet actionable.
How to prevent PG chatter across temperature and load corners?
Set deglitch to at least 1 ms, size pull-ups appropriately, buffer long lines, and avoid level-mismatch between domains. If chatter persists, move release to a PG vote node and increase RC filtering slightly within startup limits.
Migrating brands—what to re-map first: PG polarity or delay tables?
Remap PG polarity first (normalize to OD → Active-High), then port delay/timeout tables, and finally align retry and logging semantics. This order avoids false releases and makes validation more deterministic.
For procurement: which specs must appear on PO/BOM to keep substitutes safe?
Include the up/down order, delay tolerances, PG semantics + deglitch, tracking/slew requirement, and the PMBus/NVM profile pre-approval. Require Chapter 8 artifacts (PNG/CSV/JSON) for any brand or family change before PO release.
For testing: which screenshots/CSV fields are mandatory for sign-off?
Provide scope PNGs with labeled t_lead, t_lag, ΔV_window, t_reset_rel, glitch_count and CSV data for the same cursors. Include any induced-fault traces to show Rollback → Retry → Latch behavior under policy limits.
