IP cores and SoC bus fabric

Overview

Modern System-on-Chip (SoC) designs integrate multiple pre-designed functional blocks called IP (Intellectual Property) cores connected through a bus fabric. This architectural approach enables rapid development of complex systems by reusing verified components rather than designing everything from scratch.

IP Cores: Pre-Designed Functional Blocks

Types of IP Cores

1. Soft IP Cores

• Delivered as synthesizable RTL (Register Transfer Level) code (Verilog/VHDL)
• Technology-independent: can be synthesized for different process nodes
• Most flexible but requires full synthesis and verification
• Example: A UART controller delivered as Verilog source

WHY soft? Because it's "soft" like clay—you can reshape it during synthesis to fit your specific technology and timing constraints.

2. Firm IP Cores

• Delivered as netlist (gate-level representation)
• Partially optimized but still allows some technology mapping
• Middle ground between flexibility and optimization
• Example: A gate-level netlist of an encryption engine

3. Hard IP Cores

• Delivered as physical layout (GDSII files with placed transistors)
• Optimized for specific process technology
• Best performance and area but zero flexibility
• Example: A DDR4 PHY (Physical Layer) with analog components

SoC Bus Fabric: The Interconnection Network

Why Not Just Use a Simple Bus?

Simple bus problems:

1. Single master limitation: Only one IP can communicate at a time
2. No paralelism: A CPU reading memory blocks GPU from accessing different memory
3. No QoS: A low-priority DMA can stall time-critical video processing
4. Poor scalability: Adding IPs degrades performance linearly

Bus fabric solution: Provides a switching infrastructure with:

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

Bus Fabric Architecture - From First Principles

Let's derive why modern fabrics use the architectures they do.

Starting point: We have $N$ master IPs (CPU, DMA, GPU) and $M$ slave IPs (RAM, peripherals).

Requirement 1: Masters must access slaves through addresses. → We need address decoding to route transactions to correct slaves.

Requirement 2: Multiple masters may want different slaves simultaneously. → We need parallel data paths (crossbar switches).

Requirement 3: Multiple masters may want the SAME slave simultaneously. → We need arbitration logic at each slave port.

Derivation: Each of $N$ masters needs a potential path to each of $M$ slaves → $N \times M$ connection points (switches). Each slave can receive requests from all $N$ masters simultaneously → need1 arbiter per slave to choose winner.

Example: 4 masters, 8 slaves

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

This is why large SoCs use hierarchical fabrics—flat crossbars don't scale beyond ~10-20 ports.

Common Bus Fabric Standards

1. AMBA (Advanced Microcontroller Bus Architecture) by ARM

AXI Channel Structure (from first principles):

Why separate channels? In a transaction, address phase and data phase have different timing. By separating them, we can pipeline: issue address for transaction 2while data for transaction 1 is still transfering.

AXI has 5 independent channels:

1. Write Address (AW): Master → Slave, carries address + control for writes
2. Write Data (W): Master → Slave, carries write data
3. Write Response (B): Slave → Master, acknowledges write completion
4. Read Address (AR): Master → Slave, carries address + control for reads
5. Read Data (R): Slave → Master, returns read data + response

Step 1 - Write Address Phase:

• Master drives: AWADDR = 0x1000, AWLEN = 3 (4 beats of 4bytes), AWSIZE = 2 (4 bytes per beat)
• Master asserts AWVALID
• Slave asserts AWREADY when ready
• Why separate from data? Slave can accept the address and prepare while master is still gathering data.

Step 2 - Write Data Phase (can overlap with Step 1!):

• Master drives: WDATA = [data0, data1, data2, data3] over 4 clock cycles
• Master asserts WVALID, slave asserts WREADY for each beat
• Last beat has WLAST = 1
• Why burst? Transfering 4 words with 1 address is4× more efficient than 4 separate transactions.

Step 3 - Write Response:

• Slave drives: BRESP = 0b00 (OKAY)
• Slave asserts BVALID, master asserts BREADY
• Why needed? Master knows the write actually completed and didn't error.

Paralelism: While this write proceeds, the same master can issue a read address on AR channel!

2. AHB (AMBA High-performance Bus)

• Single channel (address + data multiplexed)
• Simpler than AXI, lower performance
• Used for lower-bandwidth peripherals
• Pipelined address/data (2-stage pipeline)

3. APB (Advanced Peripheral Bus)

• Non-pipelined
• Minimal complexity for low-speed peripherals
• 2-cycle protocol: SETUP → ACCESS
• Used for GPIO, timers, UARTs where speed isn't critical

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}$

But AXI can have multiple transactions in-flight: With 4 outstanding transactions: $\text{Effective} \approx 4 \times 350 = 1400 \text{ MB/s}$

Why these differences?

• APB pays 2-cycle overhead per transfer (no pipelining)
• AHB pipelines address/data (amortizes overhead)
• AXI amortizes overhead across bursts AND paralelizes multiple transactions

SoC Fabric Topology

1. Single Shared Bus

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

• Simplest, lowest cost
• Only1 transaction at a time
• Used in simple microcontrollers

2. Multi-layer AHB / Crossbar

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

• $N \times M$ switches
• Full paralelism: M1→S1 concurrent with M2→S2
• Used in mid-range SoCs

3. Hierarchical Network-on-Chip (NoC)

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

• Packet-switched network
• Scales to hundreds of IPs
• Used in high-end SoCs (smartphone APs, server chips)

Bus Fabric:

• High-speed crossbar for CPU↔GPU↔Memory
• AXI for high-bandwidth paths
• AHB for mid-speed peripherals
• APB for low-speed config registers
• Hierarchical: multiple crossbars interconnected

Why this architecture?

• CPU needs low-latency to memory → direct crossbar path
• GPU needs high bandwidth → wide AXI interface
• DSP processes camera data → dedicated path to ISP
• USB config registers rarely accessed → cheap APB saves power

Quality of Service (QoS) in Bus Fabrics

QoS Implementation - First Principles

Problem: Video decoder needs 100MB/s sustained or frames drop. Background file copy uses 300 MB/s burst. How do we guarantee video doesn't stall?

Solution components:

1. Priority Levels

• Assign each master a priority (e.g., 0-15)
• Arbiter at slave always serves highest priority pending request
• Video: priority 10, file copy: priority 2

Problem with pure priority: Starvation—priority 2 may never get served if priority 10 constantly requests.

2. Bandwidth Regulation

• Assign each master a bandwidth allocation (e.g., 40% of slave bandwidth)
• Use token bucket algorithm: master accumulates tokens, spends them on transactions
• When out of tokens, master blocks even if high priority

Token Bucket Derivation:

• Let master require average bandwidth $B_{\text{avg}}$ (bytes/sec)
• Token bucket fills at rate $r = B_{\text{avg}}$ tokens/sec
• Bucket capacity $b$ (tokens) allows bursts
• Each transaction of size $s$ bytes consumes $s$ tokens
• If bucket empty, transaction blocks until tokens available

Example: Video decoder needs 100 MB/s average, can burst to 150 MB/s for 0.1 sec.

• Token rate: $r = 100 \text{ MB/s}$
• Bucket capacity: $b = (150 - 100) \times 0.1 = 5 \text{ MB}$ of burst credit
• Video accumulates 5 MB tokens, can burst at 150 MB/s for 0.1 sec, then throttles to 100 MB/s

3. Latency Guarantees

• Track each transaction's age (time since issue)
• If age exceds threshold, boost priority → age-based escalation
• Prevents starvation while maintaining QoS

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: All three simultaneously access memory controller.

1. Arbiter sees Video (P=15), CPU (P=12), DMA (P=5) → Video wins
2. Video exhausts 100 MB/s token allocation → blocks
3. CPU (P=12) now highest → serves CPU
4. CPU exhausts 50 MB/s allocation → blocks
5. DMA gets remaining bandwidth opportunistically
6. After 1 ms, CPU's token bucket refills → CPU can issue again
7. If Video transaction waits 10 ms, age escalation overides token limits → Video served immediately

Result: Video and CPU get guaranteed service, DMA gets "best effort" with remaining bandwidth.

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):

For each slave $i$, define:

• Base address $B_i$
• Size $S_i$ (must be power of 2 for simple decoding)
• Address mask $M_i = \sim(S_i - 1)$ (inverted size-1)

Transaction address $A$ targets slave $i$ if: $(A \land M_i) = B_i$$

Why this works?

• Power-of-2 sizes mean all low bits within a region vary, high bits are constant
• Masking zeros out variable low bits
• Comparison checks if high bits match base

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

• Mask: $M = \sim(\text{0x1000} - 1) = \sim\text{0x0FFF} = \text{0xFFFF\_F000}$
• Address 0x2000_1234:
  • $\text{0x2000\_1234} \land \text{0xFFFF\_F000} = \text{0x2000\_1000}$ ✓ matches base
• Address 0x2000_0FF (in GPIO):
  • $\text{0x2000\_0FFF} \land \text{0xFFFF\_F000} = \text{0x2000\_000}$ ✗ doesn't match

Why it feels right: The cache overlaps RAM, so accesses to that region hit cache first.

The problem: The address decoder now has two slaves matching the same address range. When a master accesses 0x1000_0040, which slave responds? Both assert chip select → bus conflict, potentially damaging hardware or causing metastability.

The fix: Either:

1. Non-overlapping regions: Cache is0x0F00_0000-0x0F00_FFFF (separate region), cache controller internally redirects to RAM
2. Hierarchical decoding: Cache has higher priority decoder that catches0x1000_0000-0x1000_FF BEFORE the RAM decoder sees it
3. True cache: Don't memory-map the cache; make it a transparent cache on the RAM's slave port

Modern SoCs use option 3—caches are transparent, not separately addressed.

SoC Integration Flow

Step 1: IP Selection

• Choose CPU core (ARM Cortex-A75, RISC-V, custom)
• Choose peripherals (USB, Ethernet, etc.)
• License IP from vendors (ARM, Synopsys, Cadence)

Step 2: Bus Fabric Design

• Determine bandwidth requirements for each IP
• Choose bus protocols (AXI for high-speed, APB for low-speed)
• Design fabric topology (crossbar, hierarchical, NoC)
• Configure QoS policies

Step 3: Address Map Definition

• Assign non-overlapping address ranges to each slave
• Reserve space for future expansion
• Document in memory map specification

Step 4: RTL Integration

• Instantiate IP cores in top-level RTL
• Connect to fabric using appropriate adapters
• Add clock domain crossing (CDC) logic where needed
• Add reset distribution logic

Step 5: Verification

• Functional simulation (testbenches)
• Formal verification of protocols
• Emulation on FPGA
• Silicon bring-up

Solution: Asynchronous FIFO at clock domain boundary:

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

Why FIFO?

• Write side clocked by CPU clock
• Read side clocked by peripheral clock
• Dual-port RAM with Gray-code pointers prevents metastability
• Provides buffering to absorb clock rate differences

Sizing the FIFO (from first principles):

• CPU writes at 2 GHz, peripheral reads at 100 MHz
• Worst case: CPU bursts 64 words, peripheral can't keep up
• FIFO must buffer $64 \times \frac{2000}{100} = 1280$ words? No!
• Peripheral reads 1word per 10 ns, CPU writes 1 word per 0.5 ns
• During peripheral's read cycle (10 ns), CPU writes $\frac{10}{0.5} = 20$ words
• But peripheral also reads1 word, net: +19 words in FIFO
• For 64-word burst: $64 + 19 \times 63 = 1261$ words? Still no!

Correct analysis:

• CPU burst time: $64 \times 0.5 = 32$ ns
• During 32 ns, peripheral reads $\frac{32}{10} = 3.2 \approx 3$ words
• Net FIFO usage: $64 - 3 = 61$ words
• Add margin for read latency (say 5 cycles): $61 + 5 = 66$ words
• Round to power of 2: FIFO depth = 128 words

This is why FIFOs are designed with both clock frequency ratio AND burst patterns in mind.

Active Recall Practice

Now, all these buildings need roads to connect them so people and cars can travel between them. That's the bus fabric—it's the road network connecting all your Lego sets.

But here's the problem: if there's only one road and everyone tries to use it at once, there's a huge traffic jam! So we build multiple roads that go between different places at the same time. A fire truck rushing to an emergency gets the fast lane (high priority), while a delivery truck taking packages can use the slow lane (low priority).

The address decoder is like a GPS: when someone says "I want to go to the police station," it figures out which road leads there and sends them on the right path. Without the GPS, everyone would get lost!

Modern computer chips are like cities with thousands of buildings and roads, all working together to process your games, videos, and apps.

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

• Address Write, Write data, Back (response)
• Address Read, Read data
• Remember: "Writes need3 (AW, W, B), Reads need 2 (AR, R)"

Connections

• Interconnect Topologies - Bus fabric topologies (mesh, crossbar, NoC) stem from network topology theory
• Cache Coherence Protocols - Multi-core SoCs need coherent caches; bus fabric must supportnooping or directory protocols
• DRAM Controllers - Memory controllers are IP cores; bus fabric must match their bandwidth and timing requirements
• PCIe - PCIe controller is an IP core that bridges external PCIe bus to internal SoC fabric
• Power Management - SoC fabric includes clock/power gating logic to disable unused IPs
• DMA - DMA controllers are bus masters on the fabric; must support burst transfers efficiently
• Memory-Mapped I/O - Peripherals appear as slaves in the address space; fabric routes accesses to them

Flashcards

#flashcards/hardware

What is an IP core? :: A pre-designed, pre-verified block of logic functionality that can be integrated into a larger chip design, licensed with defined interfaces for reuse across SoC designs.

Describe the token bucket algorithm for bandwidth regulation :: A master accumulates tokens at rate (target bandwidth). Each transaction of size s consumes s tokens. When out of tokens, transactions block. Bucket capacity b allows controlled bursts above average rate.

Compare throughput of APB vs AH AXI protocols :: At 100 MHz, 32-bit: APB (2 cycles/xfer) = 200 MB/s, AHB (pipelined) = 400 MB/s, AXI (burst + multiple outstanding) ≈ 1400 MB/s with 4concurrent transactions due to amortized overhead.

What is the role of priority arbitration in bus fabrics? :: When multiple masters request the same slave, the arbiter selects the highest-priority pending request. Combined with age-based escalation to prevent starvation of low-priority masters.

Concept Map

Hinglish (regional understanding)

Hinglish (regional understanding)