AXI - AMBA on-chip protocols — Hinglish notes

6.3.7 · Hardware › Interconnects, Buses & SoC

AXI Kis Problem Ko Solve Karta Hai?

Scalability crisis: Purane buses (jaise APB, simple AMBA) the:

Single-threaded: Ek waqt mein sirf ek hi transaction
Blocking: Ek slow peripheral sabko rook deta tha
No pipelining: Data phase shuru hone se pehle address phase complete hona zaroori tha

Ye kyun matter karta hai: Ek modern smartphone SoC mein ~100 Gbps internal data movement hoti hai. CPU cache miss ko ek slow UART ke khatam hone ka intezaar nahi karna chahiye. Hume overlapping transactions, out-of-order completion, aur quality-of-service chahiye.

AMBA Family Hierarchy

Isse ek sheher ke transportation ki tarah socho:

AXI = Highway system (fast, complex, multiple lanes)
AHB = Main roads (medium speed, simpler)
APB = Residential streets (slow, minimal overhead)

AXI Core Architecture: Paanch Independent Channels

Paanch channels:

\text{Write:} \quad &\text{AW (Write Address)} \rightarrow \text{W (Write Data)} \rightarrow \text{B (Write Response)} \\ \text{Read:} \quad &\text{AR (Read Address)} \rightarrow \text{R (Read Data + Response)} \end{aligned}$$ **Requirements se derivation:** 1. **Address aur data alag kyun?** - Master address bhejta hai (burst length, size, type ke saath) - Jab slave prepare kar raha hota hai, master *doosre* transaction ka data bhej sakta hai - **Result**: Address bandwidth ≠ data bandwidth (addresses chhote hote hain!) 2. **Write response channel alag kyun?** - Slave ko memory/register mein write commit karne mein waqt lagta hai - Response data buffering complete hone ke *baad* aata hai - Master purane responses receive karne se pehle nayi requests issue kar sakta hai 3. **Read data + response combine kyun?** - Read data *hi* response hai (success/fail data ke saath aata hai) - Combine karne se ek channel bachta hai (6 ki jagah 5) > [!example] Channel Independence in Action > **Scenario**: CPU DRAM (slow) se read kar raha hai aur cache (fast) mein write kar raha hai simultaneously. **Timeline (cycles):** ``` Cycle AR Channel AW Channel R Channel W Channel B Channel 0 CPU→DRAM addr CPU→Cache addr - - - 1 - - - CPU→Cache data - 2 - - Cache→CPU (ack) 15 - - DRAM→CPU data - - ``` **Ye step kyun?** - Cycle 0: Dono addresses parallel mein issue hue (alag channels pe!) - Cycle 1-2: Cache write jaldi complete ho gaya (writes buffered hote hain) - Cycle 15: DRAM read finally return hua (slow access) - **Key insight**: Cache write ne DRAM read ka intezaar nahi kiya kyunki channels independent hain ## Handshake Protocol: VALID aur READY > [!formula] AXI Handshake Rule > Har channel ek **two-way handshake** use karta hai: > $$ > \text{Transfer occurs} \iff (\text{VALID} = 1) \land (\text{READY} = 1) \land (\text{rising edge of ACLK}) > $$ **Dono signals kyun chahiye uski derivation:** Sirf VALID ho toh imagine karo: ``` Master asserts VALID → Slave must accept immediately Problem: What if slave is busy? We'd drop data! ``` Sirf READY ho toh imagine karo: ``` Slave asserts READY → Master must send immediately Problem: Master might not have data ready! We'd send garbage! ``` **Solution**: Dono ready hone par assert karo, coincidence pe transfer karo: ``` Cycle VALID READY Transfer? Why? 0 0 1 No Master not ready 1 1 0 No Slave not ready 2 1 1 YES Both ready! 3 0 1 No Master done ``` **Critical rule**: Ek baar VALID assert ho jaye, transfer complete hone tak *nahi* drop ho sakta (deadlock rokne ke liye). > [!example] Handshake Timing Scenarios **Case 1: Slave master se slower** ``` ___ ___ ___ ___ CLK |__| |___| |___| ________________ VALID |____________ (stays high) _____________ READY |_________ ^ Transfer at cycle 2 ``` **Case 2: Master slave se slower** ``` ___ ___ CLK |___| |___| ____________ VALID |______ ________________ READY |_______________ ^ Transfer at cycle 2 ``` **Ye design kyun?** Koi bhi party doosre ko block nahi karti. Koi central arbiter nahi chahiye. Kai masters/slaves tak scale karta hai. ## Burst Transactions: Addresses ko Pipeline Karna > [!formula] Burst Efficiency Calculation > Burst matlab ==ek single address command se multiple data transfers==. **Bursts ke bina (per-beat addressing):** $$\text{Overhead per transfer} = \frac{T_{\text{addr}} + T_{\text{data}}}{1 \text{ beat}} = T_{\text{addr}} + T_{\text{data}}$$ **N-beat burst ke saath:** $$\text{Overhead per transfer} = \frac{T_{\text{addr}} + N \cdot T_{\text{data}}}{N \text{ beats}} = \frac{T_{\text{addr}}}{N} + T_{\text{data}}$$ Jab $N \to \infty$, overhead $\to T_{\text{data}}$ (address cost amortized ho jaata hai). **Burst types ki derivation:** 1. **FIXED**: Address kabhi increment nahi hota - **Use case**: FIFO register (same address, multiple reads/writes) - Example: UART RX buffer se reading 2. **INCR**: Address transfer size ke hisaab se increment hota hai - **Use case**: Memory arrays (addresses 0x1000, 0x1004, 0x1008...) - Cache line fills ke liye sabse common 3. **WRAP**: Address boundary par wrap karta hai - **Use case**: Circular buffers, cache lines - Example: 4-beat wrap at 0x100 → 0x100, 0x104, 0x108, 0x10C, 0x100... > [!example] Burst Efficiency Comparison > **Task**: Address 0x1000 se 16 bytes transfer karo. **Method A: 4 alag single-beat transactions** ``` Cycle Action 0 Send address 0x1000 1 Receive data[0:3] 2 Send address 0x1004 3 Receive data[4:7] 4 Send address 0x1008 5 Receive data[8:11] 6 Send address 0x100C 7 Receive data[12:15] Total: 8 cycles, 4 address cycles ``` **Method B: 1 four-beat burst (INCR)** ``` Cycle Action 0 Send address 0x1000, length=4 1 Receive data[0:3] 2 Receive data[4:7] 3 Receive data[8:11] 4 Receive data[12:15] Total: 5 cycles, 1 address cycle ``` **Ye step kyun?** Slave internally address auto-increment karta hai. Bandwidth saved: $(8-5)/8 = 37.5\%$. ## Out-of-Order Completion: Transaction IDs > [!formula] ID-Based Ordering > Har transaction ek ==ID tag== carry karta hai (ARID read ke liye, AWID write ke liye). **IDs ke bina problem:** ``` Master issues: Read A (slow DRAM) → Read B (fast cache) Responses: Must wait for A before B can return Result: B blocked by A (head-of-line blocking) ``` **IDs ke saath solution:** ``` Master issues: Read A (ID=0, DRAM) → Read B (ID=1, cache) Responses: B returns first (ID=1), then A (ID=0) Result: No blocking! ``` **ID width ki derivation:**

\text{Max concurrent transactions} = 2^{W_{\text{ID}}}

Typical: 4-bit ID \to 16 outstanding transactions per master. **Reordering constraint**: *Same* ID wale transactions in order complete hone chahiye (data dependency). > [!example] Out-of-Order Read Scenario > **Setup**: Master teen reads issue karta hai: > - ID=5, address 0x8000 (DRAM, 100 cycles) > - ID=3, address 0x2000 (SRAM, 10 cycles) > - ID=5, address 0x8100 (DRAM, 100 cycles) **Completion order:** ``` Cycle Event Why? 10 R channel: ID=3, data from 0x2000 (Fast SRAM) 100 R channel: ID=5, data from 0x8000 (DRAM #1) 110 R channel: ID=5, data from 0x8100 (DRAM #2, waits for #1!) ``` **Ye step kyun?** - Cycle 10: ID=3 pehle complete hota hai (alag ID, koi dependency nahi) - Cycle 110: Doosra ID=5 pehle wale ID=5 ka intezaar karta hai (same ID = ordered) **Critical insight**: Same-ID ordering memory consistency preserve karta hai (jaise write pointer write data se pehle). ## Write Response Channel: Ye Kyun Exist Karta Hai > [!intuition] Write Completion Problem > **Naive thought**: "Bas data bhejo, maano ki likh gaya." **Ye kyun toot jaata hai:** - Write buffering: Slave data accept karta hai lekin memory mein commit nahi kiya hota - Error handling: Galat address pe write ko failure report karna hota hai - Synchronization: Software ko jaanna chahiye ki write kab *globally visible* hai **AXI solution**: Alag B channel ke saath: - BID: Kaun sa write transaction complete hua - BRESP: Success (OKAY), bus error (SLVERR), decode error (DECERR) **Response timing ki derivation:**

T_{\text{response}} \geq T_{\text{last data}} + T_{\text{commit}}

Slave data jaldi buffer kar sakta hai lekin response actual memory write hone ka intezaar karta hai. > [!example] Write Response Timing > **Scenario**: CPU buffering ke saath DRAM controller mein write karta hai. ``` Cycle AW Channel W Channel B Channel Memory State 0 CPU→addr - - - 1 - CPU→data[0] - Buffered 2 - CPU→data[1] - Buffered 3 - CPU→data[2], LAST - Buffered 4 - - - Writing to DRAM... 10 - - - Writing to DRAM... 15 - - Ctrl→CPU (OKAY) Committed! ``` **Ye step kyun?** - Cycles 1-3: Data controller ke buffer mein accept ho gaya (fast) - Cycles 4-14: Controller DRAM ke liye arbitrate karta hai, write perform karta hai (slow) - Cycle 15: Response tabhi bheja gaya jab DRAM ne write acknowledge kiya **B channel ke bina**, CPU ko pata nahi chalta ki write succeed hua ya read back karna kab safe hai. ## Quality of Service (QoS): Priority Encoding > [!formula] QoS Signal Encoding > Har address channel ==AxQOS[3:0]== carry karta hai, ek 4-bit priority: > $$ > \text{Priority}: 0 \text{ (lowest)} \to 15 \text{ (highest)} > $$ **QoS kyun chahiye:** Ek SoC imagine karo jisme: - CPU (low latency chahiye) - GPU (high bandwidth chahiye) - DMA (background tasks) **Problem**: Simple round-robin GPU ko equal priority deta hai → CPU starve ho jaata hai. **Solution**: QoS levels assign karo: ``` CPU → QoS = 12 (time-critical) GPU → QoS = 6 (bandwidth, not latency) DMA → QoS = 2 (best-effort) ``` Interconnect arbitrate karta hai: CPU ko pehle mauka milta hai, GPU ko bandwidth milti hai jab CPU idle ho, DMA gaps fill karta hai. **Arbiter logic ki derivation:**

\text{Grant master } i \text{ if: } \text{QoS}i = \max(\text{QoS}{\text{ready}}) \land \text{VALID}_i = 1

> [!example] QoS Arbitration Timeline > **Contention**: 3 masters ek saath same slave ko request karte hain. ``` Cycle Master A (QoS=15) Master B (QoS=8) Master C (QoS=4) Grant 0 VALID=1 VALID=1 A (highest QoS) 1 Transfer done Waiting Waiting B (next highest) 2 - Transfer done Waiting C (only one left) 3 VALID=1 (new req) - Transfer done A (QoS=15 wins) ``` **Ye step kyun?** QoS *throughput* guarantee nahi karta, high-priority masters ke liye *latency* guarantee karta hai. A ko max 2-cycle delay dikhe (B aur C mid-transfer mein ho sakte hain). ## Common Transaction Types > [!definition] AXI Transaction Categories **1. Read Transaction** ``` Master → Slave: AR channel (address, burst QoS) Slave → Master: R channel (data + response, per beat) ``` **2. Write Transaction** ``` Master → Slave: AW channel (address, burst, QoS) Master → Slave: W channel (data, per beat) Slave → Master: B channel (single response) ``` **3. Exclusive Access (atomics ke liye)** ``` Read-exclusive: AR with AxLOCK=1 → locks address Write-exclusive: AW with AxLOCK=1 → succeds only if lock held ``` `compare-and-swap`, `test-and-set` implement karne ke liye use hota hai. ## Strobe Signals: Partial Writes > [!formula] Write Strobe Encoding > Har W channel beat ==WSTRB[n-1:0]== carry karta hai, ek bit per byte: > $$ > \text{WSTRB}[i] = > \begin{cases} > 1 & \text{Write byte } i \\ > 0 & \text{Don't modify byte } i > \end{cases} > $$ **Kyun chahiye?** Aksar sirf ek word ka *hissa* hi write karna hota hai. **Example**: 32-bit bus, address 0x1002 par 16-bit value write karo: ``` Address: 0x1002 (aligned to 0x1000) Data: 0xXXXABCDXXX (only ABCD matters) WSTRB: 0b110 (write bytes 1 and 2 only) Memory before: [FF][FF][FF][FF] at 0x1000 Memory after: [FF][AB][CD][FF] at 0x1000 ``` **Derivation**: N-byte bus ke liye:

W_{\text{STRB width}} = \frac{W_{\text{data}}}{8}

64-bit bus \to 8 strobe bits. > [!mistake] Common AXI Protocol Violations **Mistake 1: Transfer complete hone se pehle VALID drop karna** ```verilog always @(posedge clk) if (some_condition) axi_valid <= 0; // WRONG! Violates spec ``` **Ye sahi kyun lagta hai**: "Maine mann badal liya, request cancel karo." **Ye galat kyun hai**: Slave pehle se processing shuru kar chuka hoga. VALID tab tak high rehni chahiye jab tak transfer na ho jaye. **Fix**: Ek baar assert ho jaye, VALID tab tak high rahe jab tak READY na dikh jaye: ```verilog always @(posedge clk) if (axi_valid && axi_ready) axi_valid <= 0; // OK now ``` **Mistake 2: Burst alignment ignore karna** ``` AWADDR = 0x1003 (unaligned) AWSIZE = 3 (8 bytes per beat) AWBURST = INCR ``` **Ye sahi kyun lagta hai**: "Bas 0x1003 se shuru karo, 8 se increment karo." **Ye galat kyun hai**: Misaligned accesses create hote hain (0x1003, 0x100B, 0x1013..). Kai slaves ye handle nahi kar sakte. **Fix**: Start address ko transfer size ke saath align karo:

\text{AWADDR}_{\text{aligned}} = \text{AWADDR} \land \neg(2^{\text{AWSIZE}} - 1)

AWSIZE=3 ke liye: $0x1003 \land \neg 7 = 0x1000$ (aligned). **Mistake 3: Fixed latency assume karna** ```c write_axi(addr, data); // Assume done in 1 cycle read_axi(addr); // Might read stale data! ``` **Ye sahi kyun lagta hai**: "Hardware deterministic hota hai, hai na?" **Ye galat kyun hai**: AXI explicitly *variable latency* hai. Buffering, arbitration, memory timing sab vary karte hain. **Fix**: Dependent read se pehle write response ka wait karo: ```c write_axi(addr, data); wait_for_bresp(); // Block until B channel responds read_axi(addr); // Now safe ``` ## AXI vs. Purane AMBA Protocols > [!formula] Performance Comparison | Feature | APB | AHB | AXI | |---------|-----|-----|-----| | Max Clock | Low (~50 MHz) | Medium (~200 MHz) | High (500+ MHz) | | Pipeline stages | 0 (combinational) | 1 (address/data separated) | Fully pipelined | | Outstanding transactions | 1 | 1 | $2^{\text{ID width}}$ | | Typical use | GPIO, UARTs | Mid-speed periph | Cache, memory, DMA | **AXI faster kyun hai:**

\text{Bandwidth}{\text{AXI}} = \text{Clock} \times \text{Width} \times \underbrace{\text{Pipeline depth}}{\text{APB/AHB = 1}}