IP cores and SoC bus fabric

6.3.10 · Hardware › Interconnects, Buses & SoC

Overview

Modern System-on-Chip (SoC) designs mein multiple pre-designed functional blocks hote hain jinhein IP (Intellectual Property) cores kehte hain, jo ek bus fabric ke through connected hote hain. Yeh architectural approach complex systems ki rapid development enable karta hai — verified components ko reuse karke, har cheez scratch se design karne ki jagah.

IP Cores: Pre-Designed Functional Blocks

Types of IP Cores

1. Soft IP Cores

• Synthesizable RTL (Register Transfer Level) code (Verilog/VHDL) ke roop mein deliver kiye jaate hain
• Technology-independent: alag-alag process nodes ke liye synthesize kiye ja sakte hain
• Sabse flexible, lekin full synthesis aur verification chahiye
• Example: Ek UART controller Verilog source ke roop mein deliver kiya gaya

WHY soft? Kyunki yeh clay ki tarah "soft" hai — tum ise synthesis ke dauran reshape kar sakte ho apni specific technology aur timing constraints ke liye.

2. Firm IP Cores

• Netlist (gate-level representation) ke roop mein deliver kiye jaate hain
• Partially optimized lekin phir bhi kuch technology mapping allow karta hai
• Flexibility aur optimization ke beech middle ground
• Example: Ek encryption engine ka gate-level netlist

3. Hard IP Cores

• Physical layout (GDSII files with placed transistors) ke roop mein deliver kiye jaate hain
• Specific process technology ke liye optimized
• Best performance aur area, lekin zero flexibility
• Example: Ek DDR4 PHY (Physical Layer) with analog components

SoC Bus Fabric: The Interconnection Network

Simple Bus Kyun Nahi Use Karte?

Simple bus ki problems:

1. Single master limitation: Ek waqt mein sirf ek IP communicate kar sakta hai
2. No parallelism: CPU ka memory read karna GPU ko different memory access karne se rokta hai
3. No QoS: Ek low-priority DMA time-critical video processing ko stall kar sakta hai
4. Poor scalability: IPs add karne se performance linearly degrade hoti hai

Bus fabric solution: Ek switching infrastructure provide karta hai jisme:

• Multiple concurrent paths
• Priority aur QoS arbitration
• Bandwidth allocation
• Address decoding aur routing

Bus Fabric Architecture - From First Principles

Chalte hain derive karte hain ki modern fabrics woh architectures kyun use karti hain jo karti hain.

Starting point: Hamare paas $N$ master IPs (CPU, DMA, GPU) aur $M$ slave IPs (RAM, peripherals) hain.

Requirement 1: Masters ko addresses ke through slaves access karne chahiye. → Humein address decoding chahiye transactions ko sahi slaves tak route karne ke liye.

Requirement 2: Multiple masters ek saath alag-alag slaves chahiye sakte hain. → Humein parallel data paths (crossbar switches) chahiye.

Requirement 3: Multiple masters ek SAATH WALI slave chahiye sakte hain. → Humein arbitration logic chahiye har slave port pe.

Derivation: $N$ masters mein se har ek ko $M$ slaves mein se har ek tak potential path chahiye → $N\times M$ connection points (switches). Har slave $N$ sabhi masters se simultaneously requests receive kar sakta hai → ek arbiter per slave chahiye winner choose karne ke liye.

Example: 4 masters, 8 slaves

• Switches: $4\times 8=32$ crosspoints
• Arbiters: 8
• Complexity: $O(N\times M)$

Isliye large SoCs hierarchical fabrics use karti hain — flat crossbars ~10-20 ports se aage scale nahi hote.

Common Bus Fabric Standards

1. AMBA (Advanced Microcontroller Bus Architecture) by ARM

AXI Channel Structure (from first principles):

Separate channels kyun? Ek transaction mein, address phase aur data phase ki timing alag hoti hai. Inhe separate karke, hum pipeline kar sakte hain: transaction 2 ka address issue karo jabki transaction 1 ka data abhi bhi transfer ho raha hai.

AXI mein 5 independent channels hain:

1. Write Address (AW): Master → Slave, writes ke liye address + control carry karta hai
2. Write Data (W): Master → Slave, write data carry karta hai
3. Write Response (B): Slave → Master, write completion acknowledge karta hai
4. Read Address (AR): Master → Slave, reads ke liye address + control carry karta hai
5. Read Data (R): Slave → Master, read data + response return karta hai

Step 1 - Write Address Phase:

• Master drive karta hai: AWADDR = 0x1000, AWLEN = 3 (4 beats of 4 bytes), AWSIZE = 2 (4 bytes per beat)
• Master AWVALID assert karta hai
• Slave AWREADY assert karta hai jab ready ho
• Data se separate kyun? Slave address accept karke prepare kar sakta hai jabki master abhi data gather kar raha hai.

Step 2 - Write Data Phase (Step 1 ke saath overlap ho sakta hai!):

• Master drive karta hai: WDATA = [data0, data1, data2, data3] 4 clock cycles mein
• Master WVALID assert karta hai, slave har beat ke liye WREADY assert karta hai
• Last beat mein WLAST = 1 hota hai
• Burst kyun? 1 address ke saath 4 words transfer karna 4 separate transactions se 4× zyada efficient hai.

Step 3 - Write Response:

• Slave drive karta hai: BRESP = 0b00 (OKAY)
• Slave BVALID assert karta hai, master BREADY assert karta hai
• Kyun zaroori hai? Master ko pata chalta hai ki write actually complete hua aur koi error nahi aayi.

Parallelism: Jabki yeh write proceed kar raha hai, wohi master AR channel pe read address issue kar sakta hai!

2. AHB (AMBA High-performance Bus)

• Single channel (address + data multiplexed)
• AXI se simpler, kam performance
• Lower-bandwidth peripherals ke liye use hota hai
• Pipelined address/data (2-stage pipeline)

3. APB (Advanced Peripheral Bus)

• Non-pipelined
• Low-speed peripherals ke liye minimal complexity
• 2-cycle protocol: SETUP → ACCESS
• GPIO, timers, UARTs ke liye use hota hai jahan speed critical nahi

APB (2 cycles/transfer): $\text{Throughput}=\frac{32\text{ bits}}{2\text{ cycles}}\times 100\text{ MHz}=1.6\text{ Gb/s}=200\text{ MB/s}$

AHB (1 cycle/transfer with pipelining): $\text{Throughput}=\frac{32\text{ bits}}{1\text{ cycle}}\times 100\text{ MHz}=3.2\text{ Gb/s}=400\text{ MB/s}$

AXI (multiple outstanding, burst length 16): $\text{Throughput}\approx \frac{32\text{ bits}\times 16}{16+2\text{ (overhead cycles)}}\times 100\text{ MHz}\approx 2.8\text{ Gb/s}=350\text{ MB/s}$

Lekin AXI mein multiple transactions in-flight ho sakte hain: 4 outstanding transactions ke saath: $\text{Effective}\approx 4\times 350=1400\text{ MB/s}$

Yeh differences kyun?

• APB har transfer pe 2-cycle overhead pay karta hai (no pipelining)
• AHB address/data pipeline karta hai (overhead amortize hoti hai)
• AXI overhead ko bursts mein amortize karta hai AUR multiple transactions parallelize karta hai

SoC Fabric Topology

1. Single Shared Bus

[Master1] ──┐
[Master2] ──┼─── BUS ───┬─── [Slave1]
[Master3] ──┘           ├─── [Slave2]
                └─── [Slave3]

• Sabse simple, lowest cost
• Ek waqt mein sirf 1 transaction
• Simple microcontrollers mein use hota hai

2. Multi-layer AHB / Crossbar

[M1] ──┬────┬───────┬── [S1]
[M2] ──┼─X─────┼─X─────┼─── [S2]
[M3] ──┴────┴───────┴── [S3]
  (X = switch/arbiter at each intersection)

• $N\times M$ switches
• Full parallelism: M1→S1 concurrent with M2→S2
• Mid-range SoCs mein use hota hai

3. Hierarchical Network-on-Chip (NoC)

       ┌─ Router ─ [CPU Cluster]
       │
Router─┼─ Router ─ [GPU]
       │
       └─ Router ─ [Memory Controller]

• Packet-switched network
• Hundreds of IPs tak scale karta hai
• High-end SoCs mein use hota hai (smartphone APs, server chips)

Bus Fabric:

• High-speed crossbar CPU↔GPU↔Memory ke liye
• High-bandwidth paths ke liye AXI
• Mid-speed peripherals ke liye AHB
• Low-speed config registers ke liye APB
• Hierarchical: multiple crossbars interconnected

Yeh architecture kyun?

• CPU ko memory mein low-latency chahiye → direct crossbar path
• GPU ko high bandwidth chahiye → wide AXI interface
• DSP camera data process karta hai → ISP ko dedicated path
• USB config registers rarely access hote hain → sasta APB power bachata hai

Quality of Service (QoS) in Bus Fabrics

QoS Implementation - First Principles

Problem: Video decoder ko 100 MB/s sustained chahiye ya frames drop honge. Background file copy 300 MB/s burst use karta hai. Hum kaise guarantee karein ki video stall nahi hoga?

Solution components:

1. Priority Levels

• Har master ko ek priority assign karo (jaise 0-15)
• Slave ke arbiter mein hamesha highest priority ka pending request serve hota hai
• Video: priority 10, file copy: priority 2

Pure priority ki problem: Starvation — agar priority 10 constantly request kare to priority 2 kabhi serve nahi hogi.

2. Bandwidth Regulation

• Har master ko ek bandwidth allocation assign karo (jaise slave bandwidth ka 40%)
• Token bucket algorithm use karo: master tokens accumulate karta hai, transactions pe kharach karta hai
• Tokens khatam hone pe, master block ho jaata hai chahe high priority ho

Token Bucket Derivation:

• Maano master ko average bandwidth $B_{\text{avg}}$ (bytes/sec) chahiye
• Token bucket rate $r=B_{\text{avg}}$ tokens/sec se bharta hai
• Bucket capacity $b$ (tokens) bursts allow karta hai
• Size $s$ bytes ke har transaction mein $s$ tokens consume hote hain
• Agar bucket khaali ho, transaction tab tak block hota hai jab tak tokens available na hon

Example: Video decoder ko 100 MB/s average chahiye, 0.1 sec ke liye 150 MB/s burst kar sakta hai.

• Token rate: $r=100\text{ MB/s}$
• Bucket capacity: $b=(150-100)\times 0.1=5\text{ MB}$ of burst credit
• Video 5 MB tokens accumulate karta hai, 0.1 sec ke liye 150 MB/s burst kar sakta hai, phir 100 MB/s pe throttle hota hai

3. Latency Guarantees

• Har transaction ki age track karo (issue ke baad ka time)
• Agar age threshold exceed kare, priority boost karo → age-based escalation
• Low-priority masters ki starvation rokta hai QoS maintain karte hue

QoS Configuration:

• Video Priority 15, bandwidth = 100 MB/s guaranteed, age threshold = 10 ms
• CPU: Priority 12, bandwidth = 50 MB/s guaranteed, age threshold = 1 ms
• DMA: Priority 5, bandwidth = remaining (opportunistic), age threshold = 100 ms

Scenario: Teeno ek saath memory controller access karte hain.

1. Arbiter dekhta hai Video (P=15), CPU (P=12), DMA (P=5) → Video wins
2. Video apna 100 MB/s token allocation exhaust karta hai → blocks
3. CPU (P=12) ab highest → CPU serve hota hai
4. CPU apna 50 MB/s allocation exhaust karta hai → blocks
5. DMA remaining bandwidth opportunistically leta hai
6. 1 ms baad, CPU ka token bucket refill hota hai → CPU phir issue kar sakta hai
7. Agar Video transaction 10 ms wait kare, age escalation token limits override karta hai → Video immediately serve hota hai

Result: Video aur CPU guaranteed service lete hain, DMA remaining bandwidth ke saath "best effort" leta hai.

Address Decoding in Bus Fabrics

Memory Map Example (32-bit addresses):

0x000_0000 - 0x0FFF_FFFF : ROM (256 MB)
0x1000_0000 - 0x1FFF_FFFF : RAM (256 MB)
0x2000_0000 - 0x2000_0FFF : GPIO (4 KB)
0x2000_1000 - 0x2000_1FFF : UART (4 KB)
0x3000_0000 - 0x3FF_FFFF : PCIe (256 MB)

Address Decoder Logic (from scratch):

Har slave $i$ ke liye define karo:

• Base address $B_i$
• Size $S_i$ (simple decoding ke liye power of 2 honi chahiye)
• Address mask $M_i=\sim (S_i-1)$ (inverted size-1)

Transaction address $A$ slave $i$ ko target karta hai agar: $(A\wedge M_i)=B_i$

Yeh kyun kaam karta hai?

• Power-of-2 sizes matlab region ke andar saare low bits vary karte hain, high bits constant hain
• Masking variable low bits ko zero kar deta hai
• Comparison check karta hai ki high bits base se match karti hain ya nahi

Example: UART base 0x2000_1000 pe, size 4KB (0x1000)

• Mask: $M=\sim (\text{0x1000}-1)=\sim \text{0x0FFF}=\text{0xFFFF\_F000}$
• Address 0x2000_1234:
  • $\text{0x2000\_1234}\wedge \text{0xFFFF\_F000}=\text{0x2000\_1000}$ ✓ base se match karta hai
• Address 0x2000_0FFF (GPIO mein):
  • $\text{0x2000\_0FFF}\wedge \text{0xFFFF\_F000}=\text{0x2000\_0000}$ ✗ match nahi karta

Kyun sahi lagta hai: Cache RAM ko overlap karta hai, isliye us region ke accesses pehle cache hit karte hain.

Problem: Address decoder mein ab do slaves hain jo same address range match karte hain. Jab master 0x1000_0040 access kare, kaunsa slave respond karta hai? Dono chip select assert karte hain → bus conflict, jo hardware ko damage kar sakta hai ya metastability cause kar sakta hai.

Fix: Ya to:

1. Non-overlapping regions: Cache 0x0F00_0000-0x0F00_FFFF pe hai (separate region), cache controller internally RAM pe redirect karta hai
2. Hierarchical decoding: Cache ka higher priority decoder 0x1000_0000-0x1000_FFFF ko catch karta hai PEHLE RAM decoder dekhe
3. True cache: Cache ko memory-map mat karo; isse RAM ke slave port pe transparent cache banao

Modern SoCs option 3 use karti hain — caches transparent hoti hain, separately addressed nahi.

SoC Integration Flow

Step 1: IP Selection

• CPU core choose karo (ARM Cortex-A75, RISC-V, custom)
• Peripherals choose karo (USB, Ethernet, etc.)
• Vendors se IP license karo (ARM, Synopsys, Cadence)

Step 2: Bus Fabric Design

• Har IP ke liye bandwidth requirements determine karo
• Bus protocols choose karo (high-speed ke liye AXI, low-speed ke liye APB)
• Fabric topology design karo (crossbar, hierarchical, NoC)
• QoS policies configure karo

Step 3: Address Map Definition

• Har slave ko non-overlapping address ranges assign karo
• Future expansion ke liye space reserve karo
• Memory map specification mein document karo

Step 4: RTL Integration

• Top-level RTL mein IP cores instantiate karo
• Appropriate adapters use karke fabric se connect karo
• Jahaan zaroori ho wahan clock domain crossing (CDC) logic add karo
• Reset distribution logic add karo

Step 5: Verification

• Functional simulation (testbenches)
• Protocols ki formal verification
• FPGA pe emulation
• Silicon bring-up

Solution: Clock domain boundary pe Asynchronous FIFO:

CPU (2 GHz) → [Async FIFO] → Peripheral (100 MHz)

FIFO kyun?

• Write side CPU clock se clocked hai
• Read side peripheral clock se clocked hai
• Dual-port RAM with Gray-code pointers metastability prevent karte hain
• Clock rate differences absorb karne ke liye buffering provide karta hai

FIFO Size Karna (from first principles):

• CPU 2 GHz pe likhta hai, peripheral 100 MHz pe padhta hai
• Worst case: CPU 64 words burst karta hai, peripheral keep up nahi kar sakta
• FIFO buffer karna chahiye $64\times \frac{2000}{100}=1280$ words? Nahi!
• Peripheral har 10 ns mein 1 word padhta hai, CPU har 0.5 ns mein 1 word likhta hai
• Peripheral ke read cycle (10 ns) ke dauran, CPU $\frac{10}{0.5}=20$ words likhta hai
• Lekin peripheral bhi 1 word padhta hai, net: FIFO mein +19 words
• 64-word burst ke liye: $64+19\times 63=1261$ words? Abhi bhi nahi!

Sahi analysis:

• CPU burst time: $64\times 0.5=32$ ns
• 32 ns ke dauran, peripheral $\frac{32}{10}=3.2\approx 3$ words padhta hai
• Net FIFO usage: $64-3=61$ words
• Read latency ke liye margin add karo (maano 5 cycles): $61+5=66$ words
• Power of 2 tak round karo: FIFO depth = 128 words

Isliye FIFOs dono clock frequency ratio AUR burst patterns ko dhyan mein rakh ke design ki jaati hain.

Active Recall Practice

Ab in sabhi buildings ko connect karne ke liye roads chahiye taaki log aur gaadiyaan unke beech travel kar sakein. Woh bus fabric hai — yeh road network hai jo tumhare saare Lego sets ko connect karta hai.

Lekin yahan problem hai: agar sirf ek road ho aur sab ek saath use karne ki koshish karein, to bada traffic jam ho jaata hai! Isliye hum multiple roads banate hain jo ek saath alag-alag jagah jaati hain. Ek fire truck emergency mein fast lane leta hai (high priority), jabki ek delivery truck packages le jaata hai slow lane se (low priority).

Address decoder ek GPS ki tarah hai: jab koi kehta hai "Main police station jaana chahta hoon," woh figure out karta hai kaunsi road wahan jaati hai aur unhe sahi path pe bhejta hai. GPS ke bina, sab kho jaate!

Modern computer chips hazaaron buildings aur roads wali cities ki tarah hain, sab milke tumhare games, videos, aur apps process karte hain.

AXI Channels: "AW-W-B, AR-R"

• Address Write, Write data, Back (response)
• Address Read, Read data
• Yaad rakho: "Writes ko 3 chahiye (AW, W, B), Reads ko 2 chahiye (AR, R)"

Connections

• Interconnect Topologies - Bus fabric topologies (mesh, crossbar, NoC) network topology theory se nikli hain
• Cache Coherence Protocols - Multi-core SoCs ko coherent caches chahiye; bus fabric ko snooping ya directory protocols support karne chahiye
• DRAM Controllers - Memory controllers IP cores hain; bus fabric ko unki bandwidth aur timing requirements match karni chahiye
• PCIe - PCIe controller ek IP core hai jo external PCIe bus ko internal SoC fabric se bridge karta hai
• Power Management - SoC fabric mein clock/power gating logic hoti hai unused IPs disable karne ke liye
• DMA - DMA controllers fabric pe bus masters hain; burst transfers efficiently support karne chahiye
• Memory-Mapped I/O - Peripherals address space mein slaves ki tarah appear hote hain; fabric unke accesses untak route karta hai

Flashcards

#flashcards/hardware

IP core kya hota hai? :: Ek pre-designed, pre-verified logic functionality ka block jo ek bade chip design mein integrate kiya ja sakta hai, defined interfaces ke saath license kiya gaya reuse ke liye alag-alag SoC designs mein.

Bandwidth regulation ke liye token bucket algorithm describe karo :: Ek master target bandwidth ki rate se tokens accumulate karta hai. Size s ka har transaction s tokens consume karta hai. Tokens khatam hone pe, transactions block ho jaate hain. Bucket capacity b average rate se upar controlled bursts allow karta hai.

APB vs AHB vs AXI protocols ka throughput compare karo :: 100 MHz, 32-bit pe: APB (2 cycles/xfer) = 200 MB/s, AHB (pipelined) = 400 MB/s, AXI (burst + multiple outstanding) ≈ 1400 MB/s 4 concurrent transactions ke saath amortized overhead ki wajah se.

Bus fabrics mein priority arbitration ka kya role hai? :: Jab multiple masters same slave request karte hain, arbiter highest-priority pending request select karta hai. Low-priority masters ki starvation rokne ke liye age-based escalation ke saath combine hota hai.

Concept Map