Every flop in NanoSoC moves on one of three clocks and leaves reset in a strict order, and both facts are owned in the same place: the reset, clock and power controller. The 24 MHz crystal feeds the slow peripherals directly and a phase-locked loop that multiplies it to 768 MHz, from which two dividers derive the 192 MHz CPU clock and the 96 MHz system clock. Three resets fan out from the same controller, one per domain, peripheral reset first, then the fabric reset, the CPU reset last. This section teaches that tree as the integrator owns it: which source feeds which domain and why, how clocks are gated without glitches, where the ten crossings sit and what carries each one, what stays awake when everything else sleeps and what wakes it, and the exact release sequence in cycles. For the block-level circuit view see Clock Architecture and Reset Is a System Contract; for crossing circuits and signoff see the CDC & RDC course. This section is the top-level integration view those courses plug into.
Topic | What it covers | After it you can... |
|---|---|---|
Crystal, PLL multiply and divide, lock time, wrapper and lock handshake on NanoSoC | Derive every NanoSoC frequency from 24 MHz and say what holds the chip until lock. | |
Integer dividers, clock muxes, the glitch-free switching sequence and its failure modes | Read a switching sequence and explain why a plain mux is forbidden on a live clock. | |
ICG cells, enable timing, hierarchical gating, enable ownership, the DMA gated-clock failure | Own every clock enable on NanoSoC and gate a block without hanging its bus. | |
Choosing domains, the 8:4:1 ratios, phase-related versus asynchronous signoff, the domain table | Justify three domains and say which pairs signoff treats as asynchronous and why. | |
The ten NanoSoC crossings, a mechanism per crossing, the review checklist | Inventory every crossing and defend its mechanism at review. | |
What stays awake, the wake policy, and a labelled extension: what a watchdog would change in the reset tree, RST_CAUSE and the interrupt map | Write the wake policy for sleep and say what adding a watchdog to NanoSoC would change. | |
POR, pad, software and wake resets, per-domain nets, the NanoSoC reset tree | Trace any reset from its source to every flop it reaches. | |
Release order and timing, async assert with sync release, recovery and removal, the CPU-early failure | Quote the NanoSoC release order in cycles and prove release is synchronous per domain. |
Suggested order: top to bottom. Sources first, because every frequency and every lock wait derives from the crystal and the PLL; then dividers and gating, which are the two ways clocks are shaped and stopped; then domain planning and crossings, which decide where synchronisers and FIFOs must sit; then the always-on domain and wake policy, which constrain what may sleep; then resets and release order, which close the boot sequence. Readers chasing a specific failure can start at its topic: a lock-up at frequency change at the muxes, a start-up hang at release order, a missed wake at the always-on topic.
Because neither is safe without the other: resets must release only after their clocks are stable and locked, and clocks must not be gated or switched while a reset sequence depends on them. One controller owns the order.