AMBA AXI tutorials & labs.
The most complete AMBA AXI curriculum — from the five-channel architecture and VALID/READY handshake through bursts, outstanding transactions, AXI4-Lite, AXI4-Stream, interconnect, RTL design, verification, debugging, and interview mastery.
Tutorials
Learn AMBA AXI from beginner to advanced through structured tutorials.
Labs
Practice AMBA AXI using progressively challenging hands-on labs.
What AMBA AXI is
AXI is the high-performance interface of Arm's AMBA family, and the interconnect language of most modern SoCs. Its defining feature is that a transaction is split across five independent channels — read address, read data, write address, write data and write response — each with its own VALID/READY handshake. Because the channels are independent, a master can issue a new address while data for an earlier transfer is still moving, and a slave can return responses out of order when transactions carry different IDs. That concurrency is what lets a CPU, a DMA engine and a display controller share one memory subsystem without serialising behind each other.
Why it exists
Earlier buses tied address and data together, so every transfer paid the full latency of the slowest participant. As SoCs added masters and memory latency grew relative to clock speed, that model wasted most of the available bandwidth. AXI decouples the phases so the interconnect can keep many transactions in flight at once. The performance of a modern SoC is largely decided by how well its AXI traffic is shaped — burst lengths, outstanding transaction limits and ID allocation matter more than raw clock frequency.
The part engineers get wrong
The independence that makes AXI fast is also what makes it hard to debug. Two rules carry most of the difficulty. First, VALID must never wait for READY — a master that holds VALID low until it sees READY will deadlock against a slave doing the same thing, and the bus simply stops with no error. Second, ordering is only guaranteed between transactions sharing an ID; different IDs may complete in any order, so a testbench that assumes return order will fail intermittently against a perfectly legal interconnect.
Before you start
- Synchronous digital design and clocked interfaces
- The idea of a ready/valid handshake between two blocks
- Helpful but not required: familiarity with a simpler bus such as APB or AHB
What you will be able to do
- Read an AXI transaction from a waveform and identify which channel is stalling
- Apply the VALID/READY dependency rules and explain why the reverse deadlocks
- Calculate burst addresses for INCR and WRAP, including the 4KB boundary constraint
- Reason about ID-based ordering and when responses may legally interleave
- Size outstanding transactions against latency to keep a link busy
- Write and check an AXI-Lite slave, and build assertions for the handshake rules
The learning path
- Mental modelWhy a transaction is split across independent channels
- The five channelsAW, W, B, AR, R and what each one carries
- VALID/READYThe handshake, its dependency rules, and backpressure
- Transactions and burstsAxLEN, AxSIZE, AxBURST and address generation
- ResponsesOKAY, EXOKAY, SLVERR, DECERR and where they surface
- IDs and orderingWhat ordering AXI guarantees, and what it deliberately does not
- Outstanding transactionsKeeping the link busy across memory latency
- InterconnectCrossbars, arbitration and width or clock conversion
- Performance and verificationThroughput analysis, protocol checkers and coverage
Core concepts
New to AMBA AXI? Work through the curriculum in order — each lesson assumes the one before it, and the sequence is what turns the roadmap above into working knowledge.
Already working with it? Use the core-concept links above to jump straight to the topic you need; each one opens the lesson that covers it in most depth.
Where this leads
Standards: Arm AMBA AXI specification — The normative protocol definition; this track teaches the reasoning behind it in original language