Answer each question out loud before opening it. If you miss more than three in the checkpoint, revisit the lessons linked at the end.
Whatever decides whether an observed behaviour is correct: a rule, an assertion, a reference model, a table. Without one, a test only shows the design did something.
Sentence by sentence into numbered rules stating trigger, definitions in signals, obligation, timing and exceptions; each rule then maps to an assertion or a model prediction, plus coverage.
As abstract as the specification: predict results and per-flow order, not cycles, so it allows every legal implementation and is simpler than the design.
Generate both from one machine-readable source such as IP-XACT or SystemRDL and check with a table-driven checker.
File it with an owner, get a written answer from the specification owner, check the strictest reasonable reading meanwhile, and never let the RTL answer it.
A per-requirement chain from rule to checks to coverage to results, generated from rule IDs in the checks and coverage.
Yes: a check stricter than the spec fails legal designs, buries real failures and makes the testbench the specification.
Task. A specification says: "The DMA engine copies a descriptor's buffer to its destination and raises an interrupt when done. Errors are reported in STATUS." Turn it into numbered rules, list the questions you would file, and say which rules become assertions and which become reference-model predictions.
Rules (after answers): R1 every byte of the source buffer appears at the destination, in order; R2 the interrupt rises within a bound after the last write completes and only if enabled; R3 an error (bus error, bad alignment, zero length) sets a specific STATUS code and stops that descriptor; R4 the interrupt is level or pulse, cleared by a defined write. Questions: overlapping buffers? zero-length descriptors? what if a new descriptor arrives while busy? which errors exist and are they sticky? interrupt per descriptor or per chain? does an error raise the interrupt? Checks: R1 is a reference-model prediction (memory contents compared after the copy); R2 and R4 are assertions on signals with a latency bound; R3 is a table of error conditions and codes driven by error-injection tests. Each rule gets coverage: lengths at the limits, every error code, interrupt enabled and disabled.
With no oracle, nothing could have reported an error; the test only shows the design did something.
Trigger, definitions in signals, obligation, timing, exceptions (and consequences).
R13b.
Only order within a flow is promised; the interleaving at an output is the arbiter's choice.
0xF4 for the ASCII string "123456789" (CRC-8/SMBUS).
CTRL read 0x37 after reset instead of 0x3F, and a read of 0x40 answered without pslverr.
Hardware-updated values such as counters, timing between a write and its effect, and history-dependent behaviour.
Usually "what if two events happen in the same cycle?", along with reset, limits and errors.
The check may never have been exercised in the situation it guards.
It forbids every legal latency except 7 (1 to 6 and 8 to 10); assert the bound.