You join a project on Monday. By Friday you must sign off a block that connects to DCBus, an in-house bus whose whole specification is the page below. Nobody who wrote it is still on the team. Reading it with the course's checklist takes about an hour and tells you what it promises, what it leaves to you, and which questions it never answered.
Can you read an unfamiliar specification and find both its answers and its gaps?
DCBus v1: an on-chip register and memory bus. One manager, one subordinate, clock clk.
Signals
Manager to subordinate: req, addr[31:0], we, wdata[31:0], wstrb[3:0], id[1:0]
Subordinate to manager: gnt, rvalid, rdata[31:0], rid[1:0], err
R1 To request, the manager raises req with addr, we, wdata, wstrb and id, and
holds them unchanged until a cycle in which req and gnt are both high.
R2 gnt may depend on req in the same cycle.
R3 Every request receives exactly one response: rvalid high for one cycle with
rid equal to the request's id. For writes, rdata is undefined.
R4 Responses with the same id return in request order; responses with
different ids may return in any order.
R5 A manager has at most 4 requests outstanding.
R6 The manager accepts a response in any cycle rvalid is high.
R7 err high with rvalid means the request failed.
R8 While rst_n is low, req and rvalid are low.
R9 addr is 32-bit aligned; wstrb selects the bytes written.Before reading further, answer the five constraint questions and the fifteen questions for DCBus, and list every question the specification does not answer.
Question | DCBus's answer | Rule |
|---|---|---|
C1 to C5 | On-chip; one manager, one subordinate; one team (in-house) | Header |
1 Timing | Common clock | Header |
2 Framing | One request per req/gnt handshake; one response per rvalid pulse | R1, R3 |
3 Handshake | req/gnt on requests (like valid/ready); none on responses | R1, R2, R6 |
4 Flow control | gnt back-pressure on requests; responses cannot be back-pressured, so the manager must always have room for them | R2, R6 |
5 Transactions | Single 32-bit reads and writes with byte strobes | R9 |
6 Concurrency | Up to 4 outstanding, identified by id | R4, R5 |
7 Ordering | In order per id; any order across ids | R4 |
8 Sharing | None: point-to-point | Header |
9 Deadlock | Responses never wait (R6), so requests cannot block responses | R6 |
10 Errors | err flag on the response; no detection, no retry | R7 |
11 Bring-up | Reset values only | R8 |
12 Power | Not addressed | — |
13 Coherence | Not addressed | — |
14 Security | Not addressed: no protection attributes | — |
15 Verification | Not addressed by the specification | — |
Whether req may wait for gnt. If both sides waited for each other, nothing would move; the rule "req must not depend on gnt" (as AXI's A1) is missing.
Unspecified. The manager would wait for ever for up to four responses (lesson 11.1); the specification needs a rule, or the system a timeout.
No. R3 is a liveness promise with no bound (lesson 15.2); a manager has no defined way to detect a lost response.
Unspecified, and using the same id would not fix it. R4 orders only responses: with the same id, the write's response returns before the read's, but nothing says the write was performed before the read sampled memory, so the read could return stale data with its response perfectly in order. Nor does R3 say what a write response means, so even waiting for it before issuing the read is not guaranteed by this text. Two rules are missing: what a write response promises about visibility (lesson 7.4), and whether a later access to the same address is ordered after an earlier write (lesson 7.8). Ask for both before designing a manager that depends on them.
Space to accept up to four responses at any time (R5), since it can never refuse one; this sizing requirement should be stated.
Unspecified: R7 does not say whether any bytes were written.
Unspecified: R7 has one error flag with no distinction between decode errors and target errors (lesson 10.7).
All twenty answered, with "not addressed" where true.
Each answer cites the rule it comes from, or says it is inferred.
At least five gaps found, each with its consequence and a proposed rule.
The checklist turns a specification into answers, rule by rule, in about an hour.
The most valuable output is the list of questions it does not answer.
Every gap needs a consequence, a proposed rule and an assertion.