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
      • One Timeline from POR to First Fetch
      • Crystal, PLL and Waiting for Lock
      • Where Boot Time Really Goes
    • Supply Sequencing and PMIC
    • Thermal and Power Envelope
    • DVFS Integration
  • 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

←Cold-Start Power-Up Sequence
  1. Topics
  2. SoC Design
  3. Power Architecture
  4. Cold-Start Power-Up Sequence
  5. Crystal, PLL and Waiting for Lock
On this page

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

    Crystal, PLL and Waiting for Lock

    The two longest waits in the timeline: oscillator start-up, PLL lock, and what to do when lock never comes.

    Why it matters

    The crystal wait and the PLL lock together cost 53.5 µs of the 53.948 µs hardware boot: 99 percent of the timeline is waiting for analogue physics with a digital counter. Get either wait wrong and the chip releases resets into garbage clocks; make them needlessly long and every cold boot pays for it. The crystal wait is a cold-boot cost only: a wake from SLEEP does not wait for the crystal again, because the crystal never stopped, and pays only the 256-clock PLL relock, 10.667 µs. This lesson prices both waits and the failure that follows a skipped one.

    The core idea

    The 24 MHz crystal runs while the supply is on and bypasses the PLL, so the peripheral domain, the reset controller and the wake logic breathe before anything else. The 1024-cycle oscillator counter, 42.667 µs, covers the crystal start-up; the PLL then multiplies 24 MHz by 32 to 768 MHz, inside its 600 to 1200 MHz teaching range, and divides by 4 and 8 to the 192 and 96 MHz domains. The 4-cycle start-up plus 256-cycle lock counter costs 10.833 µs, and clocks and resets wait on the lock signal, never on a hope. If the PLL never locks on a wake, the sequencer's relock timeout fires at 1024 peripheral clocks (four times the 256-clock nominal, 42.667 µs) and the machine stops in a safe state instead of waiting for ever. On a cold boot the same wait belongs to the reset controller, which simply keeps the resets asserted until lock is high. A dead crystal is different: it produces no clock at all, so no counter on the chip can time it out, because the sequencer and its counters run on that crystal. Catch it from outside: an external supervisor or a watchdog on a separate clock, or the board-level check that por_n is released but rst_per_n never is.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    # Crystal and PLL arithmetic, NanoSoC teaching values (NanoSoC clock table).
    XTAL = 24e6
    N, R = 32, 1
    VCO = XTAL * N / R
    assert VCO == 768e6
    assert 600e6 <= VCO <= 1200e6  # teaching VCO range
    clk_cpu, clk_sys, clk_per = VCO / 4, VCO / 8, XTAL
    assert (clk_cpu, clk_sys, clk_per) == (192e6, 96e6, 24e6)
    assert clk_cpu / clk_per == 8.0 and clk_sys / clk_per == 4.0
    osc_us = 1024 / XTAL * 1e6
    lock_us = 260 / XTAL * 1e6
    assert abs(osc_us - 42.6667) < 0.001, osc_us
    assert abs(lock_us - 10.8333) < 0.001, lock_us
    assert abs((osc_us + lock_us) / 53.9479 - 0.992) < 0.005
    print("PASS: VCO 768 MHz; cpu 192, sys 96, per 24 MHz; osc 42.667 us, lock 10.833 us")

    What the review looks for

    • The lock wait is qualified on the lock signal with the counter as a minimum, never the counter alone.

    • The peripheral clock's PLL bypass is drawn: wake and reset logic provably run with the PLL off.

    • The PLL-never-locks path is specified: timeout value and safe landing state; and the dead-crystal case is assigned to something that does not run on that crystal, an external supervisor or a separate-clock watchdog.

    Verify and debug

    Test lock three ways: nominal lock at 256 cycles, slow lock near the counter limit, and no lock at all. The first two must release resets; the third must time out with the interrupt set. On a board that never locks, check the reference first: an unloaded crystal pin or a wrong load capacitor fails identically to a dead PLL. Never shorten the lock counter to fix a slow board; fix the board.

    PLL not locked when released: reset or clock enable goes out before lock, or the bypass state disagrees with the select, and start-up fails at random. A well-known clock bug. The lock-qualified enable with margin is the fix; the sequencing simulation with a lock model is the check.

    If asked why the crystal bypasses the PLL, answer with SLEEP: the PLL is off in SLEEP, and the wake logic and the sequencer both run on the crystal. A chip whose always-on logic needs the PLL can never sleep.

    Check yourself The lock counter expires but lock is low, and the design releases resets anyway. What is the cheapest correct fix?

    Gate the release on lock high with the counter as a minimum wait, and add the timeout path that reports instead of releasing. Releasing on the counter alone turns every slow lock into a random start-up failure.

    Related topics

    • One Timeline from POR to First Fetch

    • Next: Where Boot Time Really Goes

    • RTL: PLL Lock and Reset Coordination

    Previous

    125 / 289

    Next: Where Boot Time Really Goes

    Up next

    Up nextWhere Boot Time Really Goes

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error