Two engineers read the sentence "the DMA raises an interrupt when the job finishes" and build different things. One drives a one-cycle pulse; the other holds a level until software clears the status bit. Both match the sentence. Only the level survives the two-flop synchroniser in the interrupt controller, which needs the input held for at least two peripheral clocks, and the pulse version works in every simulation that runs one clock domain and loses an event once in a few thousand jobs on the chip. Sentences like this pass every review because each reader resolves them differently. Ambiguity hunting resolves each reading before tapeout, and it fits on one checklist.
Six questions expose nearly every ambiguity. How many: is the count exact, with units. How fast: is there a rate or deadline with a condition. Which one: are names unique, with no alias confusion. When: is the order and sampling point specified. What if empty, full or late: are the boundary and error cases named. Who proves it: is the check and its owner written down. Run each requirement through all six; any question without an answer is a defect in the specification, filed like any other bug.
Vague sentence | Question that catches it | Rewritten requirement |
|---|---|---|
Boot from SPI | Which one and how fast: which mode, rate, command and image size | After the pad reset has been low for more than 16 clk_per cycles and released, the ROM loads the second-stage image over SPI mode 0 at 6 Mb/s: a 4-byte command, then 8 KB, then jumps to it |
DMA interrupt is timely | How fast: deadline and condition | irq_dma to irq_cpu within 182.3 ns worst case, 135.4 ns best, per the latency budget |
Memory is sufficient | How many: bytes per use | 128 KB SRAM plus 16 KB ROM holds the 8 KB image, 4 KB cleared stack region and DMA buffers without overlap |
Sleep saves power | How many: milliwatts in which state | SLEEP draws at most 2 mW (illustrative cap); NanoSoC budgets 1.40 mW with SRAM0 retained |
Reset the chip cleanly | When: order, widths, sampling | Slaves and fabric first, CPU last; 16-cycle minimum assertion for a software reset; PLL locked before the system clock gates open |
Handle bus errors | What if: which response where | Holes H1, H2, H4 answer DECERR; H3 answers SLVERR; software never probes holes |
The rewritten interrupt requirement quotes a number, so it can be checked. The latency path is a two-flop synchroniser into the peripheral clock, one controller register, and a two-flop synchroniser into the CPU clock, plus one cycle of alignment margin at each end in the worst case:
irq_dma to irq_cpu, NanoSoC teaching values
best: 2 x 41.667 + 41.667 + 2 x 5.208 = 135.4 ns (26 cpu clocks)
worst: best + 41.667 + 5.208 = 182.3 ns (35 cpu clocks)
Inputs must be levels held at least 2 x 41.667 = 83.3 ns or the sync sees nothing.That arithmetic turns timely into a test: drive the source, time-stamp both edges across the ratio, and assert the bound over a sweep of alignments. A pulse shorter than 83.3 ns is allowed to be missed, which is itself a rewritten requirement: the source contract promises levels, not pulses.
Every requirement answers all six questions or carries a defect tag with an owner.
Every number carries its condition: clock rates, image sizes, alignment assumptions.
Boundary cases name the response, not just the behaviour: errors, holds, timeouts.
When silicon surprises software, check the six questions against the original sentence before the RTL: most surprises are readings nobody wrote down. Boot-load timing gets a dedicated check in the boot test: the first bytes received after the command are compared with the known image header, so a wrong mode, rate or early sampling shows up as a mismatch rather than a silent hang.
When and who: the release order with per-stage delays, and the owner of the proof. The rewrite is the six-step release chain with the 16-cycle hold, the CPU last, and the reset-order assertion in the sequence test.