You receive a short DCPeripheral brief and need to prepare a review before anyone writes more RTL. A useful AI task is extracting obligations and questions. A dangerous task is asking for a complete specification from a few sentences: the answer may quietly choose a bus protocol, reset cancellation rule, or latency. Those choices affect the driver, scoreboard, assertions, and software interface. The assistant should expose each missing decision so the responsible engineer can resolve it.
SYNTHETIC specification excerpt, revision A:
S1: Rising clk with rst_n=0 clears config_q to 0 and empties the queue.
Reset has priority over ordinary updates.
S2: Outside reset, cfg_write applies an accepted internal 8-bit write.
Otherwise the configuration register holds its value.
S3: The request FIFO has four entries.
S4: Queue acceptance, response latency, and reset cancellation are TBD.Give the assistant this excerpt and request one row per obligation: ID, source sentence, trigger, observable result, and proposed verification. Require a separate open-question list. An atomic requirement has one behavior you can inspect; putting reset, queue ordering, and latency in the same sentence makes failures difficult to classify. Keep the source revision attached because a later clarification can change a requirement without changing the assistant's wording.
PROMPT:
Using only revision A, draft requirements for DCPeripheral.
Separate explicit facts from proposed derived requirements and unknowns.
For each row name the evidence and a future check. Do not invent a bus.
Return questions for S4; do not resolve them yourself.ID and source | Checkable obligation | Proposed check |
|---|---|---|
R1 / S1 | A rising edge sampling rst_n=0 clears config_q | Drive nonzero config, sample reset at an edge, inspect post-update state |
R2 / S1 | That edge also empties the queue | Start occupied, apply reset, inspect occupancy after update |
R3 / S2 | Accepted cfg_write loads the supplied eight bits outside reset | Use 0xA5 and compare the post-update register |
R4 / S2 | No write outside reset preserves config_q | Observe two idle edges after a write |
R5 / S3 | Queue storage accommodates four accepted requests | Inspect representation and propose a four-entry boundary scenario |
This synthetic answer is useful because its rows can be challenged individually. R5 still needs acceptance semantics before an executable end-to-end test is possible. A four-entry capacity says how much storage exists; it does not say whether a request presented while full is stalled, rejected, or accepted alongside a dequeue. Likewise, eight-bit data does not imply eight-bit addresses or byte-enable support. Keep these questions visible rather than hiding them in a testbench default.
Add a row for a clock edge that samples reset low and cfg_write high together. Then identify two questions required before checking a read response. Write the row so a reviewer can distinguish the reset value from the written value without knowing any external protocol. Do not add a requirement that reset assertion between edges immediately changes state.
R6 / S1: a rising edge sampling rst_n=0 must clear config_q to 0 even if cfg_write=1; propose a conflicting 0xA5 write as the check. Ask when a read is accepted and when its response is observable. Pending-response treatment across reset remains another explicit question.
The table is a review draft, not approval of the specification or evidence that the RTL complies. Keep proposed tests in a planned state until results exist. A requirements owner must settle ambiguities, and each resolution should update the source revision and dependent artifacts. For requirement-writing guidance see NASA Systems Engineering Handbook, Revision 2 (2016), Appendix C; the project-specific rows here are original synthetic examples.