A DMA engine and the memory controller it talks to are released from reset by different parts of the chip's power-up sequence. On most boards the memory controller comes out first. On one board revision, with a slower clock oscillator, the DMA engine comes out first, sends its first descriptor fetch into a memory controller still in reset, and waits for an answer that never comes. Nothing in either block is wrong. The order is.
When connected blocks leave reset at different times, what can go wrong, and how is start-up made safe?
The obvious answer is to release everything at once. On a real chip that is rarely possible: blocks sit in different clock and power domains, resets are synchronised separately into each domain (taking different numbers of cycles), and some blocks must wait for a PLL, a memory calibration or firmware. Release times differ by design. Start-up must be correct for every order the hardware can produce.
Order | What can go wrong | Typical symptom |
|---|---|---|
Requester out first | It sends requests into a target still in reset, which drops or ignores them | Requester hangs waiting for responses (lesson 11.1) |
Target out first | It drives its outputs (ready, responses, credits) to a requester still in reset, which may misinterpret them; or it starts with stale assumptions | Spurious transfers or credits counted before the requester is ready |
Reset asserted on one side mid-operation | State on the two sides disagrees | Lost requests, wrong credit counts |
Explicit readiness: the target signals that it is ready (a link-up indication, a credit initialisation, a ready bit), and the requester sends nothing until it sees it. Credit-based links get this for free: no credits, no requests (lesson 4.4).
Defined outputs in reset: every block drives safe, inactive values while in reset, so a partner that starts earlier sees "nothing happening" rather than garbage.
Synchronised reset release per domain: each domain's reset is released synchronously to its own clock, so no flop sees a reset edge too close to a clock edge (the CDC and RDC course covers reset-domain crossings).
Documented sequence: where order cannot be made irrelevant, the power-up sequence is specified and checked.
Protocol | Start-up rule |
|---|---|
PCI Express | No transactions until the link has trained to L0 and flow-control credits are initialised; the order in which the two devices leave reset does not matter. |
AXI | Valid signals are low during reset; a manager may start once both sides are out of reset, and many systems add a readiness signal or a fixed release order. |
DCLink | Capability negotiation (step 10) and credit initialisation (step 3) must complete before any packet is sent. |
The opening board (illustrative) exposed an order nobody had tested: with the slower oscillator, the memory controller's reset release lagged by a few microseconds. The fix was to hold the DMA engine until the memory controller asserted a calibration-done signal, an explicit readiness handshake, rather than relying on the usual order.
The sender has no credits until the receiver has come out of reset and granted them, so it cannot send anything early.
Different clock domains synchronise reset release separately, and some blocks wait for PLL lock, memory calibration or firmware.
Connected blocks often leave reset at different times; each order has its own failure.
Make start-up order-independent with explicit readiness, inactive outputs in reset, and synchronised release per domain.
Verify start-up with both orders and with random delays between releases.