Architecture
Before RTL: define the contract of the hardware
A practical method for turning product requirements into interfaces, timing budgets, error behaviour and verifiable hardware contracts.
The first implementation is a set of decisions
A block diagram can look complete while leaving the most expensive questions unanswered. What happens when the consumer stops accepting data? Can software reconfigure the block while a transaction is active? Does reset discard work, preserve it or report an interrupted operation? When is a result valid, and who owns the buffer that contains it?
I approach architecture as a set of contracts that makes those answers explicit. RTL expresses the decisions in hardware, but it should not be the first place where the decisions exist. A short, testable specification creates a common reference for design, verification, firmware and integration.
The starting point is the application requirement. “Low latency” is an intention. “The result is available within a defined number of clock cycles after an accepted request, under stated backpressure conditions” can be analysed and verified. The conditions matter as much as the number.
Describe behaviour at the boundary
| Contract | Questions to resolve | Useful evidence |
|---|---|---|
| Function | Inputs, outputs, numeric range and exceptional cases? | Reference model and examples |
| Transfer | Acceptance, ordering, backpressure and buffer ownership? | Timing diagrams and assertions |
| Control | Reset, configuration, start, stop and recovery? | State and register descriptions |
| Performance | Latency, throughput and sustained load? | Budget with explicit assumptions |
| Integration | Clocks, resets, power states and software obligations? | Interface checklist and system tests |
On an AXI ready/valid channel, acceptance occurs when both signals are asserted at the sampling edge. The producer must preserve a pending transfer until it is accepted. A design that changes its payload while stalled can pass an always-ready test and fail immediately in a real system. The contract therefore belongs in the test plan as well as the interface description.
Memory-mapped control requires equal care. Define writable bits, reset values, byte-write behaviour, reserved addresses, error responses and side effects. Explain whether configuration takes effect immediately or at a safe transaction boundary. A register map is a software interface, not simply an address table.
Try the handshake
Four payloads, A to D, are ready to send. Change the receiver pattern and inspect the values sampled at each rising clock edge.
| Cycle | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|
| VALID | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 |
| READY | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| DATA | A | B | C | D | — | — | — | — |
| Accepted | A | B | C | D | — | — | — | — |
All four payloads are accepted by cycle 4. A transfer occurs only when VALID and READY are both 1.
Budget the complete path
A datapath may produce one result per cycle and still fail a system throughput requirement. Transfers, arbitration, memory access, buffering and software service can dominate the end-to-end behaviour. Separate initiation interval from latency: the first describes how often work can start; the second describes how long a particular item takes to finish.
Consider a streaming pipeline with several registered stages. Its no-stall latency can be counted precisely. Its worst-case latency cannot be bounded unless the environment also bounds stalls, arbitration delays and upstream arrival patterns. Calling the pipeline deterministic without those assumptions hides the actual contract.
Write a budget for each contributor and identify whether it is fixed, bounded or workload dependent. Then test the conditions that make the bound difficult: back-to-back requests, full queues, interrupt masking, simultaneous events and reset during activity. Architecture models should expose these interactions early, while changes remain inexpensive.
Review decisions that are difficult to reverse
Some choices deserve an early review because later changes propagate widely. Data width changes memory layout, software structures and verification models. Clock-domain partitioning changes reset and synchronisation requirements. A power-domain boundary introduces isolation, retention and sequencing concerns. An error-reporting decision affects both hardware observability and software recovery.
A useful architecture review asks participants to challenge assumptions with a concrete scenario. If an input stream never pauses, where can the system absorb a downstream stall? If a calculation saturates, is the saturation visible? If a timeout occurs, can software distinguish a stalled peripheral from a lost response?
I would finish the review with a decision record: the chosen option, alternatives, trade-off, owner and condition that would justify revisiting it. This avoids repeating the same debate and helps later engineers understand why the design looks the way it does.
The output is a compact package of requirements, boundary contracts, budgets, state behaviour and acceptance tests. It gives implementation teams freedom inside clear limits. It also gives verification a meaningful target and gives project leadership a better basis for estimating work than a list of module names alone.
Further reading
Silicon by Design
Explore the broader ideas that connect this article to the semiconductor industry and the practice of engineering.
Explore the fieldnotes