What problem does a safety PMIC solve in ADAS compute?

On most of my earlier MCU or gateway projects, I could get away with a generic PMIC plus a few DC-DC converters. As long as the rails came up in roughly the right order and the power-good pins behaved, the system felt “good enough”. Once I moved into ADAS compute, the picture changed. My SoC suddenly wanted eight to fifteen rails, the OEM asked for ASIL-level evidence, and my familiar PMIC story stopped being convincing.

In a demo lab, a generic PMIC can still power an ADAS compute SoC. The board boots, the camera feed looks fine, and benchmarks run. The problem starts as soon as I have to answer questions like “what is the diagnostic coverage of your power tree?” or “how do you prove this PMIC failure does not lead to an unsafe vehicle behaviour?”. That is the gap a safety PMIC is designed to close.

Generic PMIC vs safety PMIC – from my decision checklist

• Who controls rail sequencing? With a generic PMIC, I usually tune sequencing around inrush current and EMI. With a safety PMIC, sequencing has to follow the safety concept: always-on and safety island first, then cores and memory, then high-speed I/O, with explicit rules for brown-out and safe-state.
• Is the watchdog independent enough? A generic PMIC might expose a simple watchdog or rely entirely on the SoC’s internal WDT. A safety PMIC adds its own window watchdog, its own clock source and its own fault reaction path so that it can still take action when the SoC is stuck or running the wrong code.
• How much diagnostic coverage do I get per rail? On a generic device, I may only know that a rail went out of range. A safety PMIC gives me programmable thresholds, latched status bits per domain and a way to argue that undervoltage, overvoltage and over-temperature conditions are actually covered in the safety case.
• Can I reconstruct what happened after a reset? A generic PMIC usually forgets everything once power is gone. A safety PMIC maintains counters, fault logs and “last reset cause” registers so I can explain intermittent field resets or brown-outs to both safety engineers and OEM quality teams.

This difference becomes obvious when I walk through real ADAS use cases. On a Level 2+ domain controller, a silent power anomaly on the compute SoC can directly affect lateral and longitudinal control decisions. On a front camera ECU, borderline rails may not crash the SoC, but they can quietly degrade object detection quality and increase false positives. On a centralized compute box, a single power-tree fault can impact several perception and planning chains at once. In all of these cases, the PMIC is no longer a background component: it becomes part of the safety case.

Once I accept that, my first step is not to pick a part number. My first step is to redraw the power tree from a safety point of view: group the rails into safety domains, define how they come up and go down, and decide which failures are degradations and which ones must trigger a safe-state. That is the foundation for the next section.

Planning the power tree & multi-rail sequencing

When I open the datasheet for an ADAS compute SoC, the power chapter can easily list ten or more rails, each with its own voltage range, tolerance and timing notes. If I treat each rail as an isolated electrical requirement, the drawing quickly becomes unreadable. From a safety PMIC point of view, I get much more control by grouping rails into a few domains and assigning clear sequencing and brown-out behaviour to each domain.

In practice, I compress the SoC rails into a small number of functional and safety domains: cores, memory, high-speed I/O, general I/O and always-on. For each domain I decide three things: how it powers up, how it powers down and what should happen if that domain sags or drops while the vehicle is in motion. The safety PMIC then becomes the coordinator that enforces these rules instead of being a passive source of voltages.

Grouping rails into safety-oriented domains

I do not start from exact voltages; I start from what each rail is responsible for. A typical ADAS compute module ends up with something like this:

• Core domain (≈0.8–1.2 V): feeds CPU, GPU and AI accelerators. If this domain misbehaves, I cannot trust any high-level decisions. In most safety concepts, a core failure leads directly to a safe-state rather than a graceful degradation.
• Memory domain (≈1.1–1.8 V): powers DDR or LPDDR. Loss of this domain affects code fetch, model parameters and runtime state. Depending on the architecture, short disturbances might be tolerated with ECC and retries, but persistent faults usually require a controlled reset or shutdown.
• High-speed I/O domain: supplies SerDes, PHYs and other high-bandwidth interfaces. A failure here may drop individual sensor links; in some designs I can still run a degraded mode with fewer cameras or radars.
• General I/O and peripheral domain (3.3/5 V): covers GPIO, low-speed interfaces and miscellaneous peripherals. Some I/O failures are safety critical, others only affect convenience features; the domain plan should make that distinction visible.
• Always-on / standby domain: keeps the safety island, real-time clock and wake-up logic alive. If this domain dies, my monitoring and logging may die with it, so I treat it as one of the highest priority domains in the safety PMIC configuration.

Once the domains are defined, I can express my requirements to the safety PMIC in a much simpler way: “these rails belong to the core domain and must always rise after the safety island”, or “these high-speed rails may be shut down in a degraded mode, but the always-on rail must be protected as long as possible”.

Power-up, power-down and brown-out as a single plan

Sequencing is not only about inrush current and EMC. In an ADAS compute module, sequencing defines which parts of the system are allowed to be alive and making decisions at each stage of operation. I treat power-up, power-down and brown-out as a single, consistent plan.

• On power-up, I bring up the always-on and safety island domain first so supervision is running. Then I enable core and memory domains so the SoC can boot under supervision. High-speed and general I/O domains only follow once the compute and safety software have reached a known state.
• On power-down, I usually reverse the process: drop non-critical I/O and some high-speed domains first, bring the compute to a safe stop and only then release the core and memory rails. The always-on domain is the last one to go, or in some concepts it remains powered for logging and wake-up duties.
• On brown-out or partial faults, I decide in advance which domains may trigger a degraded mode and which domains must trigger an immediate safe-state. That decision is then implemented with the safety PMIC thresholds, timing and fault-reaction configuration instead of being left to accidental behaviour.

For example, if a high-speed I/O domain sags, I may want to log the event, mark some sensors as temporarily unavailable and keep a reduced ADAS function running. If the core domain sags below a defined threshold, the only acceptable reaction may be to put the vehicle into a defined safe-state and record the fault. The safety PMIC is the device that sees those rail conditions first and can enforce these policies deterministically.

Thinking in dependencies instead of isolated rails

When I look at the power tree only as a set of voltages, it is easy to miss the dependencies between domains. From a safety PMIC view, I try to write down, for each domain, what the system is allowed to do if that domain fails while the others are still within tolerance.

• If the core domain fails but I/O domains are still alive, I must avoid a situation where peripherals keep talking to a compute chip that is no longer executing valid code. The safety PMIC and safety MCU work together to pull the system into a safe-state.
• If the high-speed I/O domain fails while core and memory stay nominal, I may accept a degraded mode: some sensors are intentionally disconnected, but the remaining functions still operate within the safety concept.
• If the always-on domain is at risk, I treat this as a top-priority alarm. Losing supervision and logging at the same time as losing compute power makes safety arguments much harder, so the power tree is designed to protect this domain as long as possible.

Once this thinking is captured on paper, the next step is to map it into a concrete power tree. The illustration below is the simplified view I keep in mind: vehicle supply and front-end converters on the left, a safety PMIC in the centre with its domains, and the ADAS compute SoC and safety island on the right. Later sections on watchdogs, diagnostics and safe-state behaviour all build on this same picture.

Watchdog strategy and safe-state reactions

On a small MCU board I can sometimes rely on the on-chip watchdog and call it a day. On an ADAS compute module I no longer have that luxury. The compute SoC is executing safety-relevant functions and talking to several other ECUs; if it hangs, runs the wrong code or silently stops processing sensor data, the risk goes beyond a simple reboot. A safety PMIC is one of the few components that can still make an independent decision when the SoC has lost control.

When I design the watchdog strategy, I treat it as a system made of at least three layers: the internal SoC watchdog, the safety PMIC watchdog and, in higher ASIL designs, an external safety monitor or voter. Each layer watches the others from a slightly different angle. The goal is not to add complexity for its own sake, but to make sure that no single stuck software task or failed clock can silently disable all supervision.

Three layers of supervision instead of a single watchdog

• SoC watchdog (software / hardware): this is the first line of defence. I use it to detect tasks that stop running, hung state machines and scheduling issues. It is close to the application, but it also depends on the same clock, the same code and, in many cases, the same CPU that might be failing.
• Safety PMIC watchdog (window WDT with its own clock): this watchdog sits outside the SoC. It expects a heartbeat from the compute domain, but it measures time with its own oscillator and enforces a minimum and maximum interval between kicks. That independence is what turns it into a genuine safety mechanism rather than a convenience feature.
• External safety monitor / voter: in some ASIL D architectures, a separate safety monitor or voter observes both the SoC and the safety PMIC. It compares channels, checks timing and decides whether to keep the system in an operational or safe state. On this page I only reference its role; the detailed implementation belongs to a dedicated safety monitor topic.

From my point of view, the safety PMIC watchdog is the piece that connects the power tree to the safety concept. It does not understand perception or planning, but it does understand whether the compute domain is behaving like a live, timely system or like a stuck piece of silicon that should no longer be trusted.

Why the window watchdog matters in ADAS compute

A simple watchdog only cares that the software kicks it before a timeout expires. In practice, some of the nastiest bugs are not “no heartbeat” but “the wrong heartbeat”: the code falls into a tight loop that keeps feeding the watchdog too often, or it runs in bursts that violate the expected timing. A window watchdog in the safety PMIC lets me declare both a minimum and a maximum interval between kicks, so abnormal timing becomes a fault instead of a blind spot.

• If the SoC feeds the watchdog too quickly, the PMIC treats this as a sign that the main loop may have collapsed into an unintended spin or that scheduling has gone out of control.
• If the SoC feeds the watchdog too slowly or not at all, the PMIC interprets this as a classic hang or lock-up for the compute domain.
• Because the watchdog logic and the clock source live inside the safety PMIC, they remain trustworthy even when the SoC clock tree is suspect.

I configure the window watchdog timing so that a well-designed application has comfortable margin, but abnormal behaviour shows up as a reproducible trigger. That configuration is part of the safety argument: it links the PMIC datasheet parameters to real ADAS task timing and worst-case execution times.

What “safe-state” means at the compute and PMIC level

At vehicle level, safe-state is defined in the safety concept and involves braking, steering and driver alerts. On this page I focus on the part of safe-state that is under the control of the ADAS compute power tree and the safety PMIC. For the compute module, safe-state is not just “everything goes dark”; it is a controlled transition from “I am providing ADAS functions” to “I am no longer a trusted ECU”.

• Status first: as soon as the safety PMIC declares a watchdog or power fault, a status needs to reach the safety MCU, safety island or central gateway so other ECUs know that the ADAS compute module is no longer reliable.
• Rails down in a controlled order: the goal is to stop unsafe decisions while still allowing the system to store logs and send a final message. High-load compute and I/O domains may be shut down quickly, while a minimal set of rails stays up long enough to flush buffers and report the fault.
• Minimal safe-path rails stay alive: in many designs I want the network interface, the safety island or a gateway path to remain powered as long as practical so the vehicle can broadcast a degradation state and keep a basic communication link.

The safety PMIC is involved in each of these steps. It detects the fault, announces it with clear signals and then enforces the power-down strategy that the safety concept calls for. Other ECUs implement the vehicle-level response, but the PMIC makes sure the compute module does not keep pretending everything is fine.

A simple three-step reaction path

1. Detect: the safety PMIC watchdog detects a missing or mistimed kick, or its power monitors detect that a critical rail has violated the configured thresholds. Internally, the PMIC latches the event and records a fault cause.
2. Signal: the PMIC asserts a fault or reset output, and it exposes status bits over SPI, I²C or PMBus. Those signals go to the safety MCU, safety island or external safety monitor, and they can also reach the ADAS SoC itself through power-good and fault pins.
3. React: the safety MCU or safety logic decides whether to reset the compute module, force a safe shutdown or request a vehicle-level degradation. The PMIC executes the corresponding power actions on its rails. The same fault information is forwarded to the logging path so that later analysis can reconstruct what happened.

I treat this three-step path as a design pattern. Once it is clear on paper, I can map it into real pins, timing parameters and diagnostic registers on a specific safety PMIC and compute platform.

ASIL diagnostics, coverage and telemetry paths

When I read a safety PMIC datasheet, the list of UV, OV, OT flags and monitoring channels can look like a block of acronyms. For an ASIL project, these flags are not just features; they are the observable points that let me claim diagnostic coverage for power-related faults. I do not need to memorise the formulas behind FMEDA to make use of them, but I do need a clear picture of what the PMIC can see, what it can remember and how those signals reach the rest of the system.

A useful way to think about diagnostics is to list the kinds of faults I care about and then check whether the safety PMIC helps me observe them. Voltage deviations on critical rails, overcurrent events, over-temperature conditions and repeated watchdog failures are all power phenomena that can push an ADAS compute module out of its safe operating area. If the PMIC can detect and report these events, they become part of the safety case instead of hidden failure modes.

What the safety PMIC can actually see

On a typical safety PMIC I group the diagnostic capabilities into four blocks. Each block covers a family of power faults and maps to one or more status bits or counters.

• Per-rail voltage monitoring: undervoltage and overvoltage thresholds, sometimes programmable and sometimes fixed. This lets me distinguish between rails that are slightly out of tolerance and rails that are completely unusable, and it gives me a way to align the thresholds with the safe-state criteria.
• Per-rail current or load monitoring (where available): on some domains the PMIC can sense load current or detect short circuits and overloads. That allows me to argue that not only power-source faults but also certain load faults are being observed.
• Temperature monitoring: the PMIC senses its own die temperature and in some cases external sense points. Over-temperature warnings and shutdowns become diagnosable events instead of unexplained resets.
• Error counters and “last cause” registers: counters for watchdog timeouts, undervoltage occurrences or thermal events, plus registers that record the last reset or fault cause. These give me a history, not just a snapshot, and they are invaluable when debugging intermittent issues in an ADAS compute module.

From an engineering point of view, diagnostic coverage boils down to three questions: which power faults can the PMIC see, whether it keeps that information long enough for someone to read it, and whether the rest of the system is actually listening. Once those answers are clear, writing the safety documentation becomes a matter of reflecting that behaviour rather than guessing.

Telemetry paths: who learns about power faults

A diagnostic flag inside the PMIC is only useful if it reaches the right piece of software or the right ECU. In an ADAS compute design I rely on three main telemetry paths for power information coming out of the safety PMIC.

• PMIC → safety MCU / safety island: a serial bus such as SPI, I²C or PMBus carries register-level diagnostics: per-rail status, temperature readings, error counters and last fault causes. Safety software polls or reacts to these values as part of its monitoring tasks.
• PMIC → ADAS SoC or main MCU: power-good and fault pins provide immediate hardware indications that something is wrong, even before software can read a register. The SoC can use these signals to suspend certain tasks, stop using unstable interfaces or prepare for a reset.
• PMIC → EDR or data logger: the PMIC itself does not write to storage, but its fault information is forwarded by the safety MCU or SoC into an event data recorder. In a field incident analysis, having the power fault snapshot next to vehicle dynamics data can be the difference between guessing and knowing what happened.

I try to keep these paths explicit in my schematics and documentation. For each important diagnostic bit I ask myself: who will read it, how often and what decision it will influence. If there is no good answer, that bit is not really part of the safety story yet.

Directly readable vs inferred diagnostics

Not all observations are equal from a safety perspective. Some events appear as clean status bits or counters in a PMIC register map; others can only be inferred from external pins. When I prepare requirements or an RFQ, I separate these two categories explicitly.

Diagnostics I can read directly from registers

• Per-rail undervoltage and overvoltage status bits with clear rail identifiers.
• Overcurrent or short-circuit flags on selected domains, sometimes with limited numeric current readback.
• Temperature warning and shutdown flags, plus an internal temperature reading.
• Watchdog timeout flags, reset cause codes and counters for how many times each kind of fault has occurred since power-up or since the last clear.

Diagnostics I can only infer from PG / fault pins

• A generic fault pin that asserts when any of several conditions are true, without telling me which rail or which threshold was crossed.
• A power-good pin dropping on a group of rails, where I know “something in this group failed” but not exactly what or for how long.
• Brief pulses on fault or reset lines that may indicate transient issues, but that I might miss entirely if there is no latched status behind them.

In discussions with vendors I make this distinction explicit. I ask which events are latched in registers until software clears them, which events only appear as pulses on pins and what happens to the counters and reset causes when the PMIC itself loses power. These details influence how much diagnostic coverage I can credibly claim in an FMEDA.

At the end of the day, every UV, OV, OT flag, every counter and every “last cause” register ends up in a table somewhere in the safety documentation. The better I understand the diagnostic behaviour of the safety PMIC, the easier it is to build that table from real capabilities instead of optimistic assumptions.

Integration patterns with ADAS SoCs and safety islands

Choosing a safety PMIC is only the starting point. On an actual ADAS compute board I still have to decide where it sits in the power tree, which SoC or safety island it talks to and how its fault outputs and logs end up influencing the rest of the vehicle. Depending on the architecture, the same PMIC part number can play very different roles: sometimes it only watches a single SoC, sometimes it becomes the shared power arbiter for two lockstep devices, and sometimes it is the core of a central compute box surrounded by satellite camera ECUs.

In practice I start by classifying my design into a few common integration patterns. Once I know whether I am building a single-SoC ECU, a dual-SoC lockstep controller or a central compute box with satellites, I can map the safety PMIC connections much more cleanly: which heartbeat lines to expose, where to route fault pins, and how to route diagnostic registers into the safety MCU and logging path without creating new single points of failure.

Single SoC + safety PMIC + external safety MCU

In a classic ADAS compute board with one high-performance SoC, I usually end up with three major devices: the compute SoC, a safety PMIC and an external safety MCU or safety island. The safety PMIC generates and supervises the SoC rails, while the safety MCU supervises the PMIC and runs its own safety software. The SoC feeds a heartbeat into the PMIC watchdog, and the PMIC in turn feeds faults and diagnostic status into the safety MCU.

• Power topology: front-end DC-DC stages feed the safety PMIC, which then creates core, memory, I/O and always-on domains for the SoC. The safety MCU is powered either from a dedicated always-on output of the PMIC or from a small independent regulator so that it can stay alive during certain compute brown-out conditions.
• Supervision and watchdogs: the SoC provides a heartbeat or watchdog kick signal to the safety PMIC. The safety PMIC supervises the SoC timing and rails and presents fault pins and status registers to the safety MCU. The safety MCU decides when to reset the SoC or request a safe-state at vehicle level.
• Logging: the safety MCU collects PMIC fault causes, counters and rail snapshots and forwards them to an EDR or central logging ECU over CAN, LIN or Automotive Ethernet. The SoC may add context such as software state or perception load at the time of the event.

On most L2+ projects this is the pattern I default to. It keeps the power supervision and the safety software on two separate devices and makes it easier to argue that power-related faults will be seen, logged and reacted to even when the main SoC firmware is in a bad state.

Dual SoCs with a shared safety PMIC

At higher automation levels or in domain-consolidated designs, I sometimes face a dual-SoC architecture: two compute devices in lockstep, in hot-standby or in loosely coupled redundant roles. Sharing a single safety PMIC between them can save cost and simplify the power tree, but it also turns the PMIC into a common-cause element that the safety analysis must treat with care.

• Shared rails and supervision: one safety PMIC generates the core, memory and I/O domains for both SoCs or for a subset of their domains. Each SoC has its own watchdog heartbeat into the PMIC and receives power-good and fault signals in return.
• Fault distribution: the PMIC fault pins are typically wired to both SoCs and to an external safety MCU or voter. The safety MCU or voter compares the two SoCs’ views of the world and decides which outputs to trust or whether to bring both down into a safe-state.
• Safety trade-offs: a shared PMIC means both SoCs depend on the same power supervisor. I mitigate that by placing a strong emphasis on the PMIC’s own safety manual, self-tests and diagnostics, and by letting the external safety monitor arbitrate the final decision on whether the cluster is still safe to operate.

I only adopt this shared pattern when the system-level safety concept and the OEM are comfortable with the common-cause implications and when the rest of the architecture includes an external safety monitor or voter that can overrule both SoCs if needed.

Central compute with satellite camera ECUs

In a central compute architecture, the ADAS domain controller sits at the centre and several satellite ECUs handle local sensing and preprocessing: front cameras, surround view modules, radar or lidar units. Each satellite has its own local PMIC and power concept. The safety PMIC in this topic is focused on the central compute box; it does not try to supervise every remote rail across the vehicle.

• Central focus: the central safety PMIC is responsible for the main ADAS compute SoC and its safety island. It ensures that the heart of the perception and planning stack either runs on known-good rails or transitions to a defined safe-state.
• Satellite independence: camera and sensor ECUs have their own PMICs and local diagnostics. They report health over the network, but their detailed power supervision is covered in separate topics, not here.
• Integration concern: when the central safety PMIC declares a fault, the central compute functions must notify satellites and the vehicle network that ADAS capability is degraded or unavailable. I make sure that safe-state information coming from the PMIC ultimately influences how camera streams and outputs are used, even if the remote PMICs are still perfectly happy.

Thinking in these integration patterns helps me choose pin assignments, interface types and logging strategies that match the real architecture instead of treating the safety PMIC as an isolated component. The figure below is the mental map I refer to when I place the PMIC on the ADAS compute schematic.

Layout, grounding and practical wiring notes

Most safety PMIC datasheets devote only a few lines to layout and wiring hints, but the majority of embarrassing power faults show up later, in HIL benches, cold-crank tests or durability drives. Spurious Brown-out flags, one-in-a-thousand watchdog resets and noisy fault pins often trace back to avoidable layout and grounding decisions. Over time I have collected a short list of rules that I now treat as part of the design, not as afterthoughts.

The goal of these notes is not to replace a full power integrity or EMC review, but to give myself a checklist for the parts of the design that directly affect how the safety PMIC sees the world: where it senses rails, how its PG and fault pins are wired and what it considers to be “ground” in a noisy automotive environment.

Rail sense routing: what the PMIC actually measures

When the safety PMIC offers per-rail voltage sensing, it is tempting to tie the sense pins to the nearest convenient node and move on. On an ADAS compute board, that shortcut can easily lead to phantom undervoltage faults or, worse, to missed droops at the SoC. The sense pins define the PMIC’s view of each rail; if that view is filtered by long, high-impedance traces or noisy reference points, the resulting diagnostics become unreliable.

• □ For safety-critical rails I prefer a Kelvin sense arrangement, routing separate sense traces from the PMIC to the load point near the SoC or memory pins instead of sampling the rail next to the PMIC power FET.
• □ I avoid long, thin or high-impedance sense traces that cross noisy regions of the board. A hundred millivolts of transient drop across a trace can look like a Brown-out to the PMIC even when the rail at the load is within tolerance.
• □ I keep sensitive sense lines away from high-speed differential pairs and fast switching edges, and I use a solid reference plane underneath rather than routing them over split grounds or heavy return currents.

A few extra minutes spent on sense routing often pays off later when I start sweeping power profiles and temperature in the lab. Clean sense connections make it much easier to distinguish real rail problems from layout artefacts.

Fault, PG and watchdog wiring: keep the safety signals clean

Fault and power-good pins, along with watchdog kick and reset lines, form the nervous system of the safety PMIC. If these lines pick up noise, float during partial power scenarios or stretch across the vehicle on long harnesses, it becomes very hard to trust the safe-state decisions that depend on them. I try to treat them as safety signals, not just generic GPIO.

• □ I keep PG and fault traces short and local to the ADAS compute board, avoiding long cross-board or cross-connector runs whenever possible. If a signal must travel far, I consider adding buffering or filtering instead of wiring it directly to a distant ECU.
• □ I choose clear pull-up or pull-down strategies for fault and PG pins so that their logic level is well defined during power sequencing and brown-out events. Floating safety signals are an invitation to unpredictable behaviour.
• □ On critical watchdog kick lines I avoid routing next to noisy digital buses and I ensure that the return current has a short, low-impedance path. Spurious edges caused by crosstalk should not be able to masquerade as valid heartbeats.
• □ For especially important safe-state triggers I sometimes add a redundant path, such as combining the safety PMIC fault output with an independent comparator or supervisor into a small voting circuit.

These wiring details rarely make it into glossy architecture slides, but they show up quickly when I start running HIL or EMC tests. A clean, well-defined safety signal layout is often the difference between a reproducible, explainable reaction and a mysterious intermittent reset.

Grounding around the safety PMIC: give it a stable reference

The safety PMIC sits at the intersection of sensitive analog measurements and noisy digital control. Its idea of “ground” affects how it interprets rail voltages, sense thresholds and transient events. In an automotive environment, where large currents and fast transients flow through the chassis and harness, grounding choices around the PMIC can make or break diagnostic reliability.

• □ I reserve a clean local reference region for the safety PMIC, avoiding high current return paths directly under or through this area. Analog sense returns and decoupling grounds tie into this region first before joining the noisier digital or power grounds.
• □ I avoid routing heavy load currents or switching return paths between the PMIC and its sense targets. Apparent Brown-out events that only exist between two ground points are some of the hardest to diagnose later.
• □ I pay attention to how the board connects to vehicle ground and to other ECUs. Star-like or well-controlled connections help, while random ground loops across the harness tend to inject noise into the PMIC’s reference.

These layout and grounding notes do not replace a full safety analysis, but they make it much easier to stand behind the diagnostic behaviour I claim for the safety PMIC. When I carry this checklist into design reviews, I find that many potential “mystery faults” are prevented before the first prototype is even built.

IC selection and RFQ checklist for safety PMICs

On smaller MCU projects I used to write “PMIC for XX V / YY V rails” in an RFQ and let suppliers guess the rest. That stops working on an ADAS compute board. Once the PMIC enters the safety case, I need to describe my requirements in a way that covers rails, sequencing, watchdog behaviour, diagnostics and safety documentation, not just voltage numbers. This section is the checklist I use when I prepare an RFQ for a safety PMIC.

I treat the RFQ as a way to compress everything I decided in the previous sections into a few clear fields: how many rails I really need, which rails must be sequenced, what kind of window watchdog I expect, what diagnostics I want to read back and what ASIL level and safety documentation my project requires. When I send this as a structured list, suppliers can map their safety PMIC families much faster and I avoid long email threads where we keep discovering implicit assumptions.

Parameter-level RFQ checklist

At the parameter level I want the RFQ to read like a short, technical specification rather than a vague wish list. The bullets below are the fields I usually include and the kind of wording I use.

• Required rail count & voltage ranges: I describe how many regulated rails I expect and in which ranges. For example: “Around 8–12 rails covering core (0.8–1.0 V), DDR memory (1.1–1.5 V), high-speed I/O, general I/O (1.8/3.3 V) and at least one always-on/safety island domain.” This tells the supplier I am in ADAS compute territory, not building a small gateway.
• Sequencing requirements: I state that sequencing is driven by the safety concept, not just inrush considerations. A typical phrase is: “We need configurable power-up, power-down and brown-out sequencing that supports the order AON → safety island → core → memory → high-speed I/O, with programmable delays and dependency logic.” This makes it clear that fixed, hard-wired sequencing may not be enough.
• Window watchdog expectations: I explicitly ask for a window watchdog with its own clock. For example: “The PMIC shall integrate an independent window watchdog with configurable minimum and maximum timing windows. Typical application heartbeat periods are in the tens of milliseconds range.” That way I am not offered a simple timeout-only watchdog that cannot catch “too fast” failures.
• Diagnostic coverage per rail: I list which rails must have individual UV/OV status bits and where basic current monitoring or short detection is desired. I might write: “Please indicate which rails in your proposal support per-rail UV/OV status bits and, where available, overcurrent/short detection with readable status.” This keeps me from buying a black box that only has one generic fault pin.
• Fault logs, counters and reset-cause registers: I ask suppliers to highlight what history the PMIC can provide. A typical line is: “Please describe available watchdog, UV/OV and thermal fault counters, last reset/fault cause registers and whether these are latched until software clears them.” That information is essential when I later try to debug intermittent field issues.
• Target ASIL level & safety documentation: I state the safety target for my ADAS compute function and what I expect from the PMIC. For example: “The target function is ASIL C/D. Please propose safety PMICs with appropriate ASIL capability and provide safety manuals and FMEDA summaries as part of the technical evaluation.” This makes safety documents part of the RFQ from day one.
• Diagnostics interface & fault pins: I specify preferred interfaces and whether I need redundant fault outputs. I might write: “Primary diagnostics interface: SPI (preferred) or I²C/PMBus. Please detail global fault, watchdog fault and per-domain power-good outputs and their electrical behaviour (open-drain vs push-pull, level, reset state).” This helps me design clean safety signal paths.
• Environmental and reliability notes: For ADAS compute I briefly mention ambient and junction temperature ranges, expected lifetime and derating assumptions. I do not need a full reliability report at RFQ stage, but I want to avoid parts that are clearly misaligned with the environment my ECU will see.

Mapping requirements into the supplier’s view

Beyond the raw parameters, I have learned that suppliers respond much better when I give them a simple power map they can annotate. Instead of only naming the SoC, I attach a one-page power tree and a rail table and ask them to show me where their safety PMIC fits.

In the power tree, I sketch the front-end DC-DC stages, the safety PMIC and the main rails for core, DDR, high-speed I/O, general I/O, always-on and safety island. In the rail table I add one line per rail with a name, function, voltage range, estimated current and a simple safety relevance flag such as “high/medium/low”.

Then I explicitly ask the supplier to annotate this table: which rails their safety PMIC can generate directly, which rails would require external DC-DC or LDO devices from their portfolio and where they see potential limitations on current or sequencing. This turns the RFQ into a collaborative exercise instead of a guessing game and helps me quickly see whether their family really matches my architecture.

At the same time, I ask up front for safety manuals and FMEDA summaries under NDA. I do not need every formula in the first round, but I need a clear overview of the safety mechanisms in the PMIC, the supported ASIL level and the assumptions they make about my system. If a supplier cannot provide that, I know early that I may have to look elsewhere.

Example RFQ wording I use for safety PMICs

When I send an RFQ, I usually describe my safety PMIC requirements in one compact paragraph and attach the power tree and rail table as context. A typical wording looks like this:

“We are designing an L2+/L3 ADAS compute ECU with an SoC requiring approximately 8–12 rails (core, DDR, HSIO, general I/O, AON/safety island). We are looking for an automotive safety PMIC with configurable power-up, power-down and brown-out sequencing matching the attached rail map, an independent window watchdog, per-rail UV/OV diagnostics on the safety-relevant domains, basic current and temperature monitoring and fault counters/reset-cause registers. The target function is ASIL C/D; please propose devices with suitable ASIL capability and provide safety manuals and FMEDA summaries. Primary diagnostics interface should be SPI (or I²C/PMBus as an alternative), with clearly defined global fault, watchdog fault and power-good outputs. In the attached rail table, please indicate which rails your PMIC can generate directly and which rails require external DC-DC or LDO devices from your portfolio.”

Once this text and the power tree are ready, I can reuse them across suppliers and still keep the discussion technical and focused on safety and diagnostics instead of only on voltage and price.

Neutral family mapping across suppliers

Different vendors organise their safety PMIC offerings in different ways. I have seen two main patterns in the market, and I keep them in mind when I compare responses to my RFQ.

• Some families are tightly coupled to a specific ADAS SoC line. Rail mix, sequencing templates and safety documentation are optimised for that SoC, and the PMIC is marketed as the natural companion. These devices can be easy to integrate when my architecture matches that SoC family closely.
• Other families are more generic safety PMICs designed to be paired with different vendors’ SoCs. They offer flexible rail configuration, broad voltage ranges and interface options so I can map them onto my own power tree more freely, sometimes at the cost of slightly more design work on external DC-DC and LDO stages.
• There is also a split between highly integrated PMICs that aim to generate most rails on their own and combination strategies that encourage PMIC + external DC-DC for higher power or efficiency. In my RFQ I state whether I prefer a more integrated or more modular power concept so replies are easier to compare.

When I classify my project as “closer to a tightly coupled SoC solution” or “closer to a generic platform”, suppliers can position their families more honestly. I am not asking for brand names in the RFQ; I am asking for the right fit between my safety concept and their safety PMIC architecture.

Recommended topics you might also need

• Safety Island / HSM
• Safety Monitor & Voter ICs
• Hold-Up & Safe-State Power
• PCIe Switch / Retimer

FAQs: Safety PMIC for ADAS Compute

These are the twelve questions I keep coming back to when I choose a safety PMIC for an ADAS compute ECU. Each answer is short enough to reuse in RFQs, internal reviews or search results, and together they capture how I think about rails, sequencing, watchdogs, diagnostics and safety documentation around the PMIC.

Why / When

Rails and sequencing

Watchdog and fault handling

Diagnostics and RFQ