123 Main Street, New York, NY 10001

HW/SW Co-Optimized DVFS PMIC: Dynamic Voltage and Frequency Scaling for Modern SoCs


HW/SW Co-Optimized DVFS PMIC — Why it matters

HW/SW co-optimized DVFS PMIC aligns voltage and frequency in real time to balance performance and energy. Fixed-voltage rails often over-margin power and struggle with fast workload transitions.

With DVFS, the software governor updates voltage setpoints while the PMIC enforces slew rate and settling time, then reports power good and telemetry for safe decisions. This closes the loop across CPU/SoC, interface, and multi-rail power.

CPU/SoC governor sends DVS/VID commands to the PMIC. PMIC adjusts rails with controlled slew and reports PG/telemetry back. DVFS Closed Loop CPU / SoC Governor · P-states · PLL DVFS PMIC DVS/VID · Slew · Telemetry PMBus / I²C / VID PG / Telemetry Coordinated rails (slew & settling) VDD_CPU · VDD_CORE · VDD_GPU
DVFS closed loop: software governor issues DVS/VID updates; PMIC enforces slew/settling and reports PG/telemetry.

Architecture — Control Plane + Power Plane

A DVFS-capable PMIC combines a control plane—VID/DVS logic, DAC, slew engine, sequencer, PG/fault and telemetry—with a power plane of multi-rail bucks and LDOs.

  • Multi-rail power stage: Bucks for core rails; LDOs for noise-sensitive domains.
  • Reference & DVS/VID: Programmable DAC, VID step (mV/step), VOUT limits and trim accuracy.
  • Slew & timing: Up/down slew (mV/µs), settling time windows, PG delay alignment.
  • Interfaces: PMBus/I²C/SPI for software control; VID/GPIO for hardware table/trigger.
  • Sequencing & dependencies: Enforce VDD_CPU → VDD_CORE → VDD_GPU and coordinated fault handling.
  • Telemetry/diagnostics: Voltage/current/temperature and fault bits for validation and AVS.
Blocks for CPU/governor, interface bus, PMIC control plane modules, and a triple-rail power plane with sequencing and feedback. CPU / SoC Governor / P-states PMBus / I²C / SPI / VID PMIC Control Plane VID / DVS Logic Tables, limits Reference DAC mV/step, accuracy Slew Engine dv/dt up/down Sequencer VDD_CPU → CORE → GPU PG / Fault Threshold & delay Telemetry V/I/T & status Power Plane — Triple Rails Buck: VDD_CPU LDO (PLL / Ref) Buck: VDD_CORE LDO (Aux) Buck: VDD_GPU LDO (Aux) Slew/Settling per rail PG delay alignment Fault linkage Telemetry / PG
Control plane (VID/DVS, DAC, slew, sequencer, PG/telemetry) coordinating a triple-rail power plane for DVFS.

Working Principle — Voltage & Frequency Coupling

In a HW/SW co-optimized DVFS PMIC, the software governor aligns frequency targets with safe voltage transitions. The governor issues DVS/VID commands, the PMIC slews VOUT under defined limits, and PG/telemetry confirm readiness before frequency changes.

Slew rate

Up/down mV/µs limits bound dv/dt and interact with loop bandwidth and phase margin; set per rail to avoid overshoot and EMI.

Settling time

Time to enter the voltage window (±ΔV). Dependent on ΔI step, compensation, and rail impedance.

VID step

mV per step defines step count N=ceil(ΔV/step); smaller steps reduce ringing but increase total ramp time.

Ripple & transients

Buck ripple and load transients (dip/overshoot) must remain within the regulator’s window during ramps.

Telemetry

Granularity and update rate of V/I/T/status drive AVS quality and governor confidence.

Four time tracks: VID command, VOUT ramp with slew and settling markers, PG assertion window, Fclk change, and periodic telemetry samples. Command (VID/DVS) VOUT (slew & settling) PG (ready window) Fclk Telemetry VID steps Slew (mV/µs) Settling window ±ΔV PG asserted Frequency change Telemetry rate & granularity
Timing view: VID command sequence → VOUT slew and settling → PG assertion → frequency change, with periodic telemetry samples.

HW/SW Coordination Rules — Interfaces, Logic & Constraints

Coordination marries interface control (VID, PMBus/SMBus, GPIO) with governor logic and hardware limits. The rules below turn DVFS into a safe, repeatable sequence across multi-rail power domains.

1) Command priority

PMBus/SMBus typically overrides VID/GPIO. Enforce write-protect, timeouts, and safe fallback states.

2) Order & dependencies

Use voltage-first policy for VDD_CPU → VDD_CORE → VDD_GPU. Only raise frequency when PG=1 and telemetry is in-window.

3) Slew & step policy

Split ΔV into N=ceil(ΔV/VID_step). Per-step delay ≥ max(ADC_update, loop_settle/safety) to avoid ringing.

4) Multi-rail coordination

Stagger ramps by 50–200 µs to cap inrush and envelope EMI. Evaluate readiness by the slowest rail’s PG.

5) Load transient & compensation

Select L/C/ESR and control mode for worst-case ΔI. Bound slew below the loop’s stability limit (phase margin).

6) AVS accuracy

Budget DAC error, reference drift, sampling quantization, and path loss. Add hysteresis or sliding averages to telemetry.

Top: Governor/DVFS Table. Left: interfaces (VID/PMBus/GPIO) into an Arbiter→Sequencer→Slew Engine→PG/Telemetry chain; Right: triple rails. Footer: constraints (L, C, loop, AVS). Governor / DVFS Table P-states · QoS targets · Safety fallback Interfaces VID Pins · tables PMBus / SMBus Cmd + Telemetry GPIO Trigger Fast handshakes Sequencing I/O Interlocks Arbiter Priority & locks Sequencer Rail order & deps Slew Engine dv/dt limits PG / Telemetry Ready & status Power Plane — Triple Rails VDD_CPU VDD_CORE VDD_GPU Aux LDO Stagger ramps · PG by slowest rail Constraints Inductor L · Output C/ESR · Loop compensation (BW/PM) · AVS accuracy (DAC/ref/sense) · EMI envelope
Interfaces feed an arbiter and sequencer; slew engine enforces dv/dt; PG/telemetry confirm readiness for multi-rail DVFS.

Validation & Debug — Waveforms, Logs, and Telemetry

DVFS PMIC validation focuses on VOUT transients, PG timing, and PMBus/I²C command integrity, aligned with telemetry evidence. The goal is to prove safe voltage readiness before any frequency change.

What to measure

  • VOUT ramp: slew, settling, overshoot/undershoot, ripple.
  • PG assertion/deassertion: thresholds, delay, jitter.
  • Fclk change: switch instant and lock time.
  • PMBus/I²C sequence + status; telemetry (V/I/T/fault).

How to capture

  • Scope trigger at first VID step or PG rising edge.
  • Bus log with timestamps aligned to scope.
  • Telemetry dump at fixed intervals through the ramp.
  • Record worst-case ΔI load steps and ambient.

Acceptance criteria

  • Slew ≤ rail limit; settling ≤ Tsettle,max into ±ΔV window.
  • Over/undershoot within %Vout budget; PG jitter < spec.
  • Fclk changes only when PG=1 and telemetry in-window.
  • No command timeouts/NAKs; no telemetry dropouts.

Troubleshooting

  • Overshoot → lower slew, adjust COMP/L, add ESR.
  • Slow settling → increase slew or split VID steps.
  • PG chatter → add hysteresis, improve layout/grounding.
  • Freq switch fail → enforce voltage-first policy.
Timing overlay with VOUT ramp (slew/settling markers), PG ready window, Fclk change after PG, VID steps on top, and telemetry sample points aligned. VID / PMBus VID steps VOUT Slew (mV/µs) Settling window ±ΔV PG PG asserted Fclk Frequency change after PG Telemetry Aligned sampling window & rate
Validation timing: VOUT ramp and settling within window, PG asserted before Fclk switch; bus steps and telemetry aligned.

Applications — Where DVFS PMIC Delivers Value

DVFS PMICs cut energy while preserving QoS across heterogeneous platforms. Each scenario below highlights the why, the how (voltage–frequency–timing), and a sample series for orientation.

Mobile SoC (Application Processor)

Highly dynamic workloads (camera, gaming, idle) benefit from margin removal via DVFS. Multi-rail coordination (CPU/Core/GPU) with voltage-first and PG-proven readiness.

Sample series TI TPS65917 / TPS65218 · NXP PF8100 (i.MX8) · ST STPMIC1 (STM32MP1)

Automotive ECU/MCU (ASIL-B~D)

Domain controllers require deterministic timing and diagnostics. Conservative slew, PG interlocks, and telemetry logging support safety goals and thermal budgets.

Sample series Renesas ISL91211A / ISL91302A · onsemi NCV multi-rail PMIC · TI TPS65919-Q1

FPGA / AI SoC

Burst traffic and standby transitions need fast yet stable ramps. DVFS tables encode power–latency trade-offs; slew kept under loop-stability and EMI constraints.

Sample series Renesas ISL91302A · Microchip MCP16502 · NXP PF5020 / PF8100

Industrial Edge / IoT

Periodic wake/report/sleep cycles pair DVFS with deep-sleep policies. Drop frequency first, then voltage; use telemetry to refine adaptive profiles.

Sample series TI LP87524 · ST STPMIC1 family · Microchip MCP16502

Four-quadrant map with key reasons to use DVFS PMIC in each domain and a sample series line. Mobile SoC • Remove voltage margin for dynamic loads • Multi-rail coordination (CPU/Core/GPU) • PG-proven readiness Sample: TPS65917 / PF8100 / STPMIC1 Automotive ECU/MCU • Deterministic timing and diagnostics • Conservative slew, interlocks • Telemetry logging for ASIL goals Sample: ISL91211A / ISL91302A / TPS65919-Q1 FPGA / AI SoC • Fast but stable ramps for bursts • Power–latency DVFS table • EMI/stability bounded slew Sample: ISL91302A / MCP16502 / PF5020 Industrial Edge / IoT • Wake/report/sleep duty cycling • Drop f first, then V • Telemetry-driven adaptive policy Sample: LP87524 / STPMIC1 / MCP16502
Application quadrants: Mobile SoC, Automotive ECU, FPGA/AI SoC, Industrial Edge/IoT—reasons and sample series.

IC Selection — DVFS-Friendly PMICs by Interface & Feature

For DVFS PMIC selection, start with the control interface (PMBus/SMBus, VID, or I²C/GPIO) and rail requirements, then verify slew/settling windows, PG timing, and telemetry to support your governor.

Ribbon diagram showing the selection flow: Interface → Rails/Current → Slew/Settling → PG window → Telemetry. IC Selection Flow Interface → Rails/Current → Slew & Settling → PG window → Telemetry Interface PMBus / VID / I²C Rails Count · I< t >max Slew/Settling mV/µs · µs/ms PG Window Threshold · Delay Telemetry V/I/T · Status
Selection ribbon: pick the control interface first, then validate rails, slew/settling, PG, and telemetry for your DVFS governor.

TI

DVFS-ready
Example Series
TPS65987D, LP87524
Interface
I²C / GPIO
Key Feature
Multi-rail DVS + Telemetry

Use note — General-purpose SoC power; multi-rail coordination and readback for governor validation.

ST

Platform-aligned
Example Series
STPMIC1
Interface
I²C
Key Feature
STM32MP1 power rails

Use note — Tight pairing with STM32MP1 ecosystems for faster bring-up and reference DVFS tables.

NXP

PMBus
Example Series
PF8100
Interface
PMBus
Key Feature
6-rail SoC DVFS

Use note — PMBus commands + telemetry ease log alignment and sequencing across multiple rails.

Renesas

Fine-slew
Example Series
ISL91211A
Interface
I²C
Key Feature
Slew Rate Control

Use note — Suitable where transient behavior is critical; per-rail slew tuning for stability/EMI.

onsemi

VID
Example Series
NCP6925
Interface
VID
Key Feature
Multi-phase DVS

Use note — Hardware VID suits fast, deterministic steps; multi-phase for higher current domains.

Microchip

Adaptive
Example Series
MIC28512
Interface
PMBus
Key Feature
Adaptive VOUT

Use note — Programmable VOUT behavior supports AVS experiments and telemetry-driven refinement.

Melexis

Automotive
Example Series
MLX81117
Interface
SMBus
Key Feature
Automotive low-power domain

Use note — Fits body/lighting low-power domains; SMBus integration and diagnostics for vehicle platforms.

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

FAQs — Practical Answers for DVFS PMIC Designs

Each question targets an engineering decision point: interface choice, timing safety, stability, telemetry, and validation. Open items to see concise, actionable guidance.

Stylized ribbon showing VID steps, VOUT slew, PG window, and telemetry dots as a visual cue for DVFS FAQs. VID / PMBus VOUT PG & Telemetry
What fundamentally differentiates a DVFS PMIC from a fixed-voltage PMIC?

A DVFS PMIC supports programmable voltage targets and controlled ramps tied to frequency policies. It exposes interfaces (PMBus/SMBus, I²C, or VID), enforces slew/settling limits, and returns PG/telemetry for closed-loop safety. Fixed regulators rely on static margins, wasting energy and complicating timing during workload transitions.

When do I need AVS (Adaptive Voltage Scaling) rather than a static DVFS table?

Choose AVS when workload, silicon variation, or temperature drift cause meaningful margin spread. AVS uses telemetry feedback to trim voltage per part or condition, reducing V² losses without violating stability. Start with a safe DVFS table, then enable AVS within bounded windows and with rollback on out-of-range readings.

How should PMBus commands coordinate with the software governor?

Let the governor issue ordered PMBus writes (e.g., VOUT command, operation enable) and verify with readback before any frequency increase. Enforce write-protection, timeouts, and error counters. Align timestamps between PMBus logs and scope captures so PG assertion and settling windows are proven before clock changes occur.

What happens if the slew rate is configured too fast?

Excessive dv/dt can provoke overshoot, loop instability, and EMI peaks, especially with marginal compensation or low-ESR networks. Limit slew to the control loop’s stable region and the load’s di/dt tolerance. If overshoot appears, lower slew, add damping (ESR/RC), or retune compensation and inductor values.

What is the downside of configuring the slew rate too slow?

Slow ramps extend total switching latency, risking QoS dips and governor timeouts. Long exposure near thresholds can increase ripple-induced PG chatter. Use stepwise VID with minimum per-step delay tied to ADC update and loop settling; validate end-to-end “command-to-stable” time under worst-case load steps.

How do I choose PG thresholds and acceptable PG delay?

Define PG as voltage within a tolerance window plus hold time, with hysteresis to reject ripple. Delay must accommodate the slowest rail’s settling yet remain bounded for system responsiveness. Correlate PG timestamps with scope and telemetry; if chatter appears, widen hysteresis or reduce ripple at the sense node.

How are frequency changes related to PLL stability and sequencing?

Raising frequency increases current demand; voltage must be ready first. Enforce a voltage-first policy: VID/DVS, wait for PG and in-window telemetry, then change frequency, observing PLL lock time. On downshifts, lower frequency before reducing voltage. Never switch clocks while PG is uncertain or ramping.

What is the recommended strategy for multi-rail DVFS synchronization?

Coordinate rails using a sequencer and PG interlocks. Prefer staggered ramps (50–200 µs) to limit inrush and EMI envelope, while evaluating readiness by the slowest rail. Apply shared rollback rules: if any rail violates window or PG times out, revert to a safe P-state and log telemetry snapshots.

Which interface should I pick: VID pins or I²C/PMBus?

VID offers minimal latency and deterministic steps with coarse granularity; ideal for fast, fixed P-states and fallback. I²C/PMBus provides programmability, telemetry, and richer limits, suited for complex DVFS/AVS policies. Many designs combine both: VID for immediate action, PMBus for configuration and diagnostics.

How do I define “voltage ready” before increasing frequency?

Require PG=1, telemetry within voltage window for a defined hold time, and—optionally—recent ripple below a limit. Align evidence: PMBus/I²C readback, scope traces, and telemetry timestamps. Gate PLL or clock changes on this composite condition to prevent switching during transient or marginal states.

What should I prioritize during DVFS bring-up and debugging?

Instrument triggers on first VID step or PG rising edge, capture VOUT, PG, and Fclk on the scope, and log PMBus with timestamps. Dump telemetry at fixed intervals across ramps. Triage quickly: overshoot, slow settling, PG chatter, or sequence violations; adjust slew, compensation, hysteresis, or step spacing.

What commonly causes overshoot or undershoot, and how do I fix it?

Root causes include overly aggressive slew, under-damped loops, insufficient ESR, or layout inductance. Mitigate by reducing slew, adding damping (ESR/RC snubbers), retuning compensation, or increasing output capacitance at the load. Verify improvements by measuring transient response and comparing against the allowed voltage budget.

How do I select an appropriate VID step for each rail?

Balance total ΔV time versus ringing risk. Smaller steps improve stability and PG robustness but increase latency; larger steps reduce latency yet heighten overshoot. Choose step size by loop bandwidth, load di/dt, and telemetry resolution; validate with worst-case ΔI and command-to-stable measurements.

How should the system fall back to a safe P-state in the field?

Define rollback triggers: PG timeout, out-of-window telemetry, command errors, or PLL unlock. Switch to a conservative P-state (lower frequency, higher voltage), record fault counters and snapshots, and rate-limit retries. Provide a diagnostic flag so firmware can persist incident data for post-mortem tuning.

Need help choosing a DVFS-enabled PMIC?

Still unsure which DVFS-enabled PMIC suits your SoC rail architecture? Submit your BOM for a 48h cross-brand recommendation.