CLOCK-RESET

CDC/RDC and Clock/Reset Architecture

Treat clocks, resets, and power transitions as named architectural interfaces with ownership and acknowledgement. The patterns are generic; synchronization depth and constraints require technology, MTBF, and flow-specific analysis.

Inputs

Clock/reset/power domain inventory and relationships
Crossing type: level, pulse, multi-bit data, request/response
Boot, clock-stop, wake, and fault-recovery sequence

Method

Maintain a domain map that names every clock source, gate, reset source, consumer, and crossing owner.
Choose the crossing primitive by information type: synchronize stable single-bit levels, use request/acknowledge for pulses, and use a coherent protocol or FIFO for multi-bit data.
Make reset assertion and release semantics explicit for every domain; arrange release with the consumer clock and verify recovery behavior.
Gate clocks only with a defined enable protocol and status/acknowledgement path; prove no transaction is stranded during stop or wake.
Run structural CDC/RDC analysis, then close each finding with intent, waiver rationale, or a simulation/formal scenario—not tool silence.

Deliverables

Versioned domain/crossing inventory
Reset-release and clock-gating sequence specification
Reviewed CDC/RDC findings and scenario evidence

Pitfalls

Synchronizing each bit of a bus independently and assuming a coherent word.
Deasserting an asynchronous reset without considering its destination clock or clock-off state.

Sources

OpenTitan Comportability ↗
OpenTitan · Peripheral Feature Details — Clocking

OpenTitan Reset Manager Theory of Operation ↗
OpenTitan · Reset Consistency Checks; POR Reset Tree

OpenTitan Clock Manager Theory of Operation ↗
OpenTitan · Reset Domains; Root Clock Gating and Interface with Power Manager