Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • The NanoSoC Tour
  • Reading Path
  • SoC Glossary10
  • SoC Metrics Reference
  • SoC Cheatsheet
  • What SoC Integration Is12
  • Architecture and Budgets21
  • Memory Maps and Address Decode26
  • Interconnect and Bus Fabrics26
  • Clock and Reset Architecture24
  • Power Architecture21
    • Power Domains and States
    • Isolation and Retention Integration
    • PMU and Power Sequencer
    • Cold-Start Power-Up Sequence
    • Supply Sequencing and PMIC
    • Thermal and Power Envelope
    • DVFS Integration
      • Raise V Then f, Lower f Then V
      • Clock Switching and Safe Operating Points
      • Failure Modes and Regulator Dependence
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
  • IP Integration and Handoff21
  • Top-Level Verification and Bring-up21
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←DVFS Integration
  1. Topics
  2. SoC Design
  3. Power Architecture
  4. DVFS Integration
  5. Failure Modes and Regulator Dependence
On this page

    Part 6 of 14, lesson 21 of 21Part 6 of 14/Power Architecture/Lesson 21 of 21All levels

    Failure Modes and Regulator Dependence

    Everything that goes wrong when voltage and frequency move: symptoms, guards, and what the regulator must promise.

    Why it matters

    DVFS concentrates every power and clock failure mode into one transition: the wrong order crashes timing, the wrong ratio breaks a crossing, a slow regulator voids the settle wait, and a test that only visits OPP0 covers none of it. This lesson collects the modes in one table with the guard for each, and writes down the regulator promises the whole scheme stands on.

    The core idea

    Four modes cover the space. Order inversion crashes paths at the new frequency on the old voltage; the guard is the controller of the first lesson. A crossing-ratio change breaks assumptions baked into synchroniser depths and FIFO sizes; the guard is re-verification at every ratio, because a crossing's latency, FIFO depth and synchroniser MTBF change with the two frequencies. The single shared rail adds a constraint to every mode: lowering the voltage lowers it for the always-on logic and the memories too, so their minimum-voltage limits bound the lowest operating point. A regulator slower than its illustrative model voids every settle wait; the guard is qualifying waits on voltage-good, with the slew rate owned by the regulator data, flagged illustrative here. And a skipped operating point in test leaves a gear that was never entered; the guard is a transition-coverage matrix over the OPP table demanding every pair in both directions under traffic. The script below computes, per operating point, how full the CPU-to-fabric asynchronous FIFO gets during a 16-beat burst and checks that it still fits.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    # Re-verifying a crossing per OPP: async FIFO fill for a 16-beat burst.
    # Source writes one beat per source clock; the destination starts reading after a
    # 2-destination-clock pointer synchroniser delay and reads one beat per clock.
    # OPP0 frequencies NanoSoC values; OPP1 and the depth illustrative.
    from fractions import Fraction as F
    BURST, DEPTH = 16, 12           # beats; illustrative FIFO depth
    def fill(f_src_mhz, f_dst_mhz):
        t_write_us = F(BURST) / f_src_mhz                  # time to push the burst
        latency_us = F(2) / f_dst_mhz                      # pointer synchroniser delay
        reads = max(0, int((t_write_us - latency_us) * f_dst_mhz))   # beats drained meanwhile
        return BURST - min(BURST, reads)
    OPPS = {"OPP0": (192, 96), "OPP1": (96, 64)}           # (cpu MHz, sys MHz)
    fills = {k: fill(*v) for k, v in OPPS.items()}
    assert fills == {"OPP0": 10, "OPP1": 8}, fills
    assert all(f <= DEPTH for f in fills.values())         # every shipped gear fits
    # A gear that is NOT re-verified: cpu 192 MHz into a 48 MHz fabric overflows.
    assert fill(192, 48) == 14 and fill(192, 48) > DEPTH
    print("PASS: burst fill 10 at OPP0, 8 at OPP1 fits depth 12; a 192:48 gear (fill 14) is caught")

    Failure

    Symptom

    Caught by

    Fix

    Order inversion

    Crash only when going faster

    Transition test both directions

    Raise V then f; lower f then V; gate on voltage-good

    Ratio-sensitive crossing

    FIFO overflow or stall at one gear; rare metastability only if the destination clock got faster

    Ratio-sweep CDC sims at every OPP

    Re-verify depths, latencies and synchroniser MTBF per ratio

    Slow regulator

    Settle wait expires early, crash follows

    Rail capture during transition

    Wait on voltage-good; own the slew number

    Untested gear

    Field failure at a rarely used point

    Transition-coverage matrix

    Every OPP pair both ways under traffic

    What the review looks for

    • The regulator promises are written as inputs with owners: slew rate, tolerance band and voltage-good timing, all illustrative here and all flagged.

    • The transition-coverage matrix is filled, not planned: every OPP pair both directions with traffic crossing every bridge.

    • The STA signoff covers every OPP corner, not just the top frequency; the low-voltage corners close timing explicitly.

    Verify and debug

    Run the transition matrix with randomised traffic and randomised regulator delay around the illustrative slew: every transition must complete with no corrupted transaction and no lost interrupt. If one gear fails while others pass, compare its ratio against the verified set before touching voltages; an unverified ratio is a CDC problem wearing a DVFS symptom. If all gears fail going up, capture the rail: the regulator is slower than its number, and the number, not the wait, is wrong.

    Synchronous assumption wrong: two clocks treated as synchronous that share no phase relation, at one ratio but not another. DVFS changes ratios, so a pair signed off as same-source at OPP0 must be re-declared asynchronous if the divider plan ever splits their roots; declare the relation per OPP, not per chip.

    If asked what the regulator must guarantee for DVFS, answer with three numbers: the slew rate the waits assume, the tolerance band that defines settled, and the voltage-good timing the controller gates on. Then say where those numbers come from: the regulator data, never the RTL.

    Check yourself All OPPs pass alone, but transitions under traffic corrupt data. Order is correct and the rail is clean. What remains?

    The crossings at the new ratios: FIFO depths and synchroniser allowances verified at OPP0 do not automatically hold at OPP1 ratios. Re-run the ratio-sweep CDC and traffic tests at the failing pair; the transition exposed a ratio hole, not a voltage hole.

    Related topics

    • Clock Switching and Safe Operating Points

    • Power Domains and States

    • CDC & RDC: Synchronizer Selection Guide

    Previous

    138 / 289

    Next: Interrupt Routing and Latency

    Up next

    Up nextInterrupt Routing and Latency

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Raise V Then f, Lower f Then V