* Question

The power sequence is often implemented in a cascaded way. What is wrong with this approach?

* Answer

Short answer: daisy-chaining “PG→EN→PG→EN…” looks simple, but it’s fragile and hard to control.

What goes wrong with cascaded sequencing

• No control of power-down. The chain only guarantees power-up order. On brownouts or shutdown, rails collapse in whatever order their loads and capacitances dictate, risking back-powering through ESD diodes and I/O structures, latch-up, or corrupted state.
• Timing drift stacks up. Each stage’s soft-start, PG threshold, hysteresis, and deglitch time vary with tolerance, temperature, and load. In a chain, these errors accumulate, so the final rail timing can be far from what the datasheet sequence requires.
• PG isn’t “rail is truly ready.” Many PG pins assert around ~90–95% of nominal and don’t guarantee settling under dynamic load. The next rail may start while the previous one is still marginal; when downstream loads come up, the upstream rail can droop and chatter PG, causing oscillation.
• Poor fault handling. If an upstream rail hiccups or trips current limit, downstream rails may partially start or repeatedly bang on/off. There’s no global fault latching, retry policy, or coordinated shutdown.
• Scalability and routing pain. With many rails, you get long PG traces, level-mismatch issues (open-drain vs push-pull, pull-up rails), and more susceptibility to noise and false triggers.
• Inflexible by design. Changing order or delays means hardware edits (RCs, reroutes). You can’t easily meet tight POR windows, monotonic-ramp requirements, or “A and B must rise together” constraints.
• Race conditions at corners. Different ambient, input ramp rates, or hot-plug conditions can change which PG asserts first; a design that “works on the bench” can fail at cold start or light load.

When a cascade can be acceptable

Very few rails, loose timing requirements, no strict power-down order, and loads tolerant to back-powering. Even then, add a global master-enable and good brownout behavior.

Better approaches

Centralized sequencer/PMIC: Programmable order, delays, UV/OV monitoring, fault latching, coordinated shutdown, and power-good that actually references thresholds you set.

Small CPLD/MCU + FET enables: Measure rails (ADC/comparators), gate ENs, enforce both power-up and power-down order, and implement retries/timeouts.

If you must keep the cascade

Gate every EN with a global master-enable so all rails drop together on faults.

Add power-down control (discharge FETs or timed disables) to enforce reverse order.

Debounce/deglitch PG, and ensure PG thresholds and pull-up rails are correct.

Verify at corners: cold/hot, min/max VIN, slow/fast VIN ramps, no-load/full-load.

Provide margin (≥2× required delay) and ensure monotonic ramps for sensitive rails (CPU/FPGA core vs I/O).

Bottom line: cascaded PG chaining is easy to draw but hard to make robust. For multi-rail systems or anything safety/uptime-critical, use a real sequencer or PMIC.