“The DMA should be fast and handle backpressure.”
“Fast” has no unit, traffic model, measurement boundary, or correctness clause. The team cannot tell whether peak issue rate, accepted bytes, or completion rate is intended.
Product intent to buildable machine
Specification to Microarchitecture
Follow one realistic DMA subsystem from an ambiguous product request to measurable requirements, executable interface contracts, a block architecture, and an evidence-ready handoff.
Learn to expose missing assumptions early, budget throughput and buffering with units, choose structures deliberately, and preserve bidirectional traceability through RTL and verification.
Updated July 20266 connected chaptersInteractive labs + worked examples
One requirement · six owned contracts
Turn a throughput promise into a block-level proof plan.
Select a blueprint node to inspect its role, contract, failure mode, and evidence.- Channels
- 4
- Fabric
- 256 bit
- Clock
- 500 MHz
- Sustained
- 12 GB/s
Measurable requirement anatomy
Write the proof boundary into the requirement.
A useful requirement names who acts, under which traffic and operating conditions, what is measured, where it is measured, and what happens when the contract cannot be met.
R-DMA-012 · performance
The DMA subsystem shall sustain at least 12 GB/s of accepted payload across four continuously active channels, using legal 16-beat transfers on a 256-bit, 500 MHz downstream interface, while preserving per-channel ordering and propagating backpressure without data loss.
- Actor
- Complete DMA subsystem, not one channel in isolation
- Stimulus envelope
- Four active channels, legal aligned transfers, stated mix
- Measured outcome
- Accepted payload bytes per elapsed second
- Observation boundary
- Downstream VALID and READY acceptance events
- Correctness invariant
- No loss, duplication, or per-channel reordering
- Verification method
- Analysis plus constrained traffic tests and scoreboards
Rate + envelope + acceptance + invariant
The rewritten requirement creates testable conditions and exposes missing decisions: allowed latency, downstream service guarantee, error policy, reset behavior, and implementation margin.
Nonfunctional contract gate
The datapath is not buildable until its operating envelope is.
These worked-example targets show the review depth expected before architecture freeze; project values must come from the real product and signoff plan.
| Requirement | Concrete contract | Architecture consequence | Required evidence |
|---|---|---|---|
| NFR-CLKClock + reset | clk_dma is a defined 500 MHz generated clock. Every asynchronous crossing is classified, and reset deasserts locally only after its clock is stable. | Generated-clock constraints, CDC structures, reset synchronizers, and domain_ready gating are part of the block interface. | STA clock coverage · CDC/RDC · reset-sequence assertions |
| NFR-PWRPower | Illustrative active power is capped at 120 mW for the named workload and PVT view; idle admission stops before clocks gate. | Activity assumptions, clock-gating eligibility, wake latency, isolation, and retained state are budgeted before freeze. | Power analysis · gate checks · power-aware sleep/wake tests |
| NFR-DFTDFT | Sequential state is scan-visible unless waived; SRAMs have an MBIST path; test controls can override functional clock gates and resets safely. | Test muxing, scan modes, macro wrappers, and at-speed capture clocks are architectural ports, not late netlist patches. | Scan/MBIST rules · test-mode STA · coverage report |
| NFR-SECSecurity | Every descriptor is checked against its programmed privilege and address window before any fabric transaction is issued. | Unauthorized work creates no downstream side effect and retires with precise, auditable status. | Negative-access tests · formal range proof · audit-status coverage |
| NFR-SAFESafety + reliability | Descriptor and response state detect corruption; a bounded timeout converts a lost response into one fail-stop completion. | Parity/ECC choice, timeout ownership, first-error capture, recovery, and diagnostic observability are explicit. | Fault injection · timeout/liveness assertions · diagnostic coverage |
| NFR-PHYPhysical feasibility | The 500 MHz path budget, memory ports, block-boundary registers, macro placement, and congestion margin close in an early floorplan. | Pipeline cuts and replicated state are chosen while architecture can still change, with PPA ownership attached. | Early synthesis · floorplan/congestion · MMMC timing · power estimate |
Scenario before block diagram
Trace the failure before choosing the machinery.
A scenario is an executable statement of intent. It reveals temporal assumptions, state ownership, and failure behavior that a noun-only block list will miss.
Design questionCan all channels remain active while the shared path sustains the system target?
Four legal descriptors become eligible.
Arrival synchrony creates the worst arbitration instant.One burst from each channel enters the issue window.
A fixed-priority policy can satisfy aggregate rate while starving C3.Accepted beats average 0.75 per cycle.
Counting VALID without READY overstates delivered bandwidth.Per-channel completions become visible in legal order.
Global order is unnecessary; per-channel precision is mandatory.Measure accepted bytes, not issued requests. Fair service and 75% average fabric utilization must coexist without one channel carrying all of the progress.
Partition by ownership
Place state where one block can make it precise.
Partitioning is not drawing boxes around functions. It assigns every mutation, wait, retry, and completion to one owner while controlling shared critical paths.
CH0descriptorepochprogress
CH1descriptorepochprogress
CH2descriptorepochprogress
CH3descriptorepochprogress
eligibilityScheduler + credit gate→Burst formation→Response ledger
256-bit downstream boundaryacceptance · ordering · error · backpressure
| State | Allocate | Mutate | Retire | Observable evidence |
|---|---|---|---|---|
| Descriptor context | Channel front | Channel front | Channel front | accepted / active / completed counters |
| Fabric credit | Response ledger | Issue + response | Response ledger | outstanding high-water mark |
| Burst progress | Burst engine | Burst engine | Response ledger | channel, descriptor, burst, beat identity |
| First error | Response ledger | write-once until retire | Channel front | cause, address, bytes committed, epoch |
Interface and state contracts
Define acceptance, lifetime, and cancellation together.
Signal direction is not an interface contract. Every boundary also needs a sampling event, stability rule, ownership transfer, ordering scope, error semantics, and reset behavior.
Descriptor request
- Accept
- req_valid && req_ready
- Stable while blocked
- address, length, channel, flags
- Transfer
- caller → channel front
- Reject
- alignment, range, or disabled channel
Fabric beat
- Accept
- valid && ready at the fabric edge
- Stable while blocked
- payload, byte enables, ID, LAST
- Order
- as defined for the selected ID and channel
- Capacity
- one credit per accepted outstanding unit
Channel completion
- Emit
- after every accepted burst reaches terminal state
- Report
- status, bytes committed, first error
- Reuse
- only after completion acceptance
- Reset
- drain, cancel, or reject by declared epoch
Conservation invariantaccepted descriptors = completed descriptors + active descriptors
Refine the same conservation equation for bursts, beats, credits, and response IDs. After quiescence, every active count must reach zero.
Budgets before optimism
Connect bandwidth, latency, buffering, and PPA.
Peak width times frequency is only a ceiling. A credible microarchitecture closes sustained service, outstanding work, burst granularity, arbitration, and implementation margin together.
Bytes / beat32 B256 ÷ 8
Raw peak16 GB/s32 B × 500 MHz
Payload service efficiency87.5%14 GB/s accepted payload ÷ raw peak
Required utilization75%12 ÷ 16
Arrival rate0.75 beat/cycletarget ÷ raw beat bandwidth
Fixed-latency window60 beatsarrival rate × round-trip cycles
Minimum whole bursts4ceil(60 ÷ 16)
Zero-service stall backlog60 beats1,920 B if the source cannot be backpressured for 80 cycles
The rate assumptions are physically consistent.
Sustained payload service is below the raw peak and above the target. The latency window sizes accepted in-flight context; the stall backlog separately assumes zero service while an upstream source continues and cannot be backpressured.
Illustrative normalized estimates
Compare architecture hypotheses, not colors.
more throughputmore implementation cost
Evidence before RTL
Hand off decisions, not just diagrams.
A microarchitecture is ready when downstream teams can implement, verify, constrain, program, and review it without recovering hidden intent from meetings.
Handoff completeness0 / 6
Implementable structure
Block boundaries, state machines, widths, pipeline stages, interface contracts, reset values, and illegal-state behavior.
Observable proof plan
Requirement IDs, scenarios, reference behavior, assertions, coverage, error injection, counters, and closure criteria.
Stable software contract
Register semantics, ownership, completion, error recovery, reset/quiesce, interrupt behavior, and performance counters.
Physical feasibility
Clock and power domains, memories, multicycle intent, floorplan pressure, target corners, activity assumptions, and PPA budgets.
Reasoning checkpoints
Questions worth answering without notes.
Each answer states the mechanism first, then the consequence.01What makes a hardware requirement verifiable?+
It names an observable subject, a measurable behavior or limit, the operating conditions, and an unambiguous pass condition. “High performance” is an aspiration; “sustain 12 GB/s for legal 256-byte bursts at 500 MHz while honoring downstream backpressure” can be designed, constrained, and tested.
02How do you know whether to add buffering or improve service rate?+
Buffering absorbs finite bursts and latency variation, but it cannot repair a sustained arrival rate that exceeds sustained service rate. First compare long-term rates, then size finite storage from the maximum permitted burst and response-latency envelope with explicit backpressure assumptions.
03What belongs in a microarchitecture handoff?+
Include requirements traceability, block and clock/reset/power boundaries, interface contracts, state ownership, ordering and error rules, cycle-level scenarios, performance and storage calculations, configuration and status behavior, observability hooks, unresolved risks, and a verification strategy for every important invariant.
Keep practicing
Move from recognition to explanation.
These links open the existing practice bank without publishing protected solutions on this guide.Build traceable verification itemsTurn specification statements into measurable evidence.→Control a credited linkDefine ownership, return credits, and bounded outstanding work.→Size a FIFO under unstable rateSeparate finite burst absorption from sustained overload.→Schedule credited clients fairlyBalance arbitration policy, throughput, and starvation bounds.→Budget an SoC from a workloadTranslate traffic, latency, and power intent into measurable architecture budgets.→Trade sharing against throughputDecide when a shared engine meets the service contract and when parallel hardware is required.→
Continue the system
Connect the adjacent layer.
Logic to reliable timingDigital DesignConnect logic behavior to its physical timing contract, then choose safe structures for paths that cross cycles, clocks, and module boundaries.Open guide →Safe boundaries across time and voltageClock, Reset, CDC and PowerOperate a dual-clock, power-gated sensor subsystem from cold reset through configuration, streaming, quiesce, sleep, wake, and recovery while every crossing preserves meaning.Open guide →RTL intent to signoff marginSynthesis and Timing ClosureAutopsy one failing register-to-register path as it moves from elaborated RTL to a mapped netlist, placed design, clock tree, extracted route, and signoff corner.Open guide →