Every CDC setup, whatever the tool calls its files, asks the same questions: which clocks, how they relate, which resets, and which signals are quasi-static. Writing the answers down before touching the tool turns setup from archaeology into transcription, and the document outlives every tool version.
Section | Contents |
|---|---|
Clock list | Every clock net, its source, its frequency or period range, and whether it is always on |
Relationships | For each clock pair that exchanges signals: synchronous, related, mesochronous, plesiochronous, or asynchronous |
Resets | Per domain: each reset, asynchronous or synchronous, what it reaches, and the release order across domains |
Quasi-static signals | Each rarely-changing crosser, its enforcement mechanism, and what stops mid-transfer changes |
Exceptions | Anything deliberately untreated, with the justification that the waiver review will check |
An illustrative two-clock block (a processor bus clock and a slower peripheral clock) needs only a few lines, and those lines already answer most setup questions:
Item | Entry |
|---|---|
Clocks | cpu_clk 100 MHz always on (oscillator); periph_clk 25 MHz always on (same generator, divide-by-4, known phase) |
Relationship | Related, fixed ratio 4:1; crossings use two-flop synchronisers for control and a handshake for data |
Resets | Both domains share an asynchronous-assert reset; periph releases after cpu (ordered release); each synchroniser flop takes the receiving domain's reset (or is explicitly unreset by policy), and both flops release together |
Quasi-static | periph_mode[1:0]: shadow register plus synchronised apply pulse; source holds the value until the acknowledge returns |
Exceptions | None: every crossing has a scheme |
Write nets, frequencies, and relationships, never tool commands or message names. The intent says "cpu_clk and periph_clk are related 4:1"; the tool setup translates that into whatever declarations the flow needs. When the tool reports an undeclared clock or an unexpected relationship, the intent is the referee: either the design changed and the intent is updated, or the setup is wrong and the tool input is fixed. Reviews work the same way: the reviewer reads five tables, not five hundred report lines, and samples the reports against them.
// snippet
// Clock intent for the illustrative cpu/periph block, in plain words.
// A reviewer checks each line against the design and the tool setup.
// clocks: cpu_clk 100 MHz (source: oscillator), periph_clk 25 MHz
// (source: same generator, divide-by-4, known phase)
// relationship: related, fixed ratio 4:1
// resets: shared async-assert reset; periph releases after cpu
// quasi-static: periph_mode[1:0] via shadow register + synchronised apply
// exceptions: noneThe intent governs pending investigation: either the design changed (update the intent and re-justify the schemes) or the setup is wrong (fix the declaration). What must not happen is shrugging and signing off with the two disagreeing.
Because an omitted crossing is invisible: no reviewer can distinguish "considered safe" from "never noticed". A listed exception carries its justification into waiver review; an omission carries nothing.