Worked examples — IP cores and SoC bus fabric

6.3.10 · D3 · Hardware › Interconnects, Buses & SoC › IP cores and SoC bus fabric

Ye page parent topic ka "har case pe prove karo" companion hai. Parent ne bataya tha kya hain AXI channels, crossbars, aur APB/AHB/AXI throughput. Yahan hum har tarah ke numeric question grind karte hain jo ye topic throw kar sakta hai — chote easy wale, degenerate wale (ek master, zero outstanding transactions), limiting wale (infinite burst length), ek real-world word problem, aur ek exam-style twist jo ek trap chhupaata hai.

Koi bhi formula aane se pehle hum use plain words mein rebuild karte hain, taaki koi bhi symbol aisa na ho jisse tum mila nahi ho.

---

The scenario matrix

Bus fabric throughput aur crossbar sizing ke har question ko in case classes mein se kisi ek mein daala ja sakta hai. Isse ek checklist samjho: agar tum har row se ek example answer kar sako, toh exam pe kuch bhi surprise nahi kar sakta.

#	Case class	Tricky kya hai	Covered by
A	Simple throughput (fixed cycles/transfer)	bas numbers plug karo	Ex 1
B	Burst amortization (overhead N beats pe spread hota hai)	"+overhead" term	Ex 2
C	Degenerate input — burst length = 1	overhead dominate karta hai, formula phir bhi kaam karna chahiye	Ex 3
D	Limiting input — burst length → ∞	throughput ek ceiling ke paas pahunchta hai	Ex 4
E	Parallelism (multiple outstanding transactions)	multiply karo, lekin asli bottleneck dekho	Ex 5
F	Crossbar sizing (switches/arbiters ginana)	$N\times M$ growth, degenerate $N=1$	Ex 6
G	Real-world word problem — bandwidth budget meet karna	MB/s ↔ bits translate karo, protocol chuno	Ex 7
H	Exam twist — trap: bus width vs. clock vs. efficiency sab ek saath change hote hain	bits aur bytes mix mat karo	Ex 8

Do tools jo hum har jagah reuse karte hain:

---

Ex 1 — Case A: plain APB transfer

Forecast: padhne se pehle guess karo — kya ye 1-cycle bus se aage jayega ya peeche? (Peeche rehna chahiye, kyunki 2 cycles 1 se slow hai.)

Steps

1. $W=32$ bits, cycles-per-transfer $=2$, $f_{\text{clk}}=100\times 10^6$ Hz identify karo. Ye step kyun? Tool 1 ko exactly ye teen numbers chahiye; pehle naam lene se mix-up nahi hota.

2. Tool 1 apply karo: $\frac{32\text{bits}}{2\text{cycles}}\times 100\times 10^6\text{Hz}=16\times 100\times 10^6=1.6\times 10^9\text{bits/s}.$ Ye step kyun? Ye units convert karne se pehle raw bit-rate hai.

3. Bits → bytes convert karo (8 se divide karo): $\frac{1.6\times 10^9}{8}=200\times 10^6\text{bytes/s}=200\text{MB/s}.$ Ye step kyun? MB/s woh unit hai jo question ne maangi thi.

Verify: Sanity — 2 cycles 1-cycle bus ki aadhi speed hai, aur 1-cycle 32-bit 100 MHz bus $400$ MB/s hai. 400 ka aadha 200 hai ✓. Parent note ke APB figure se match karta hai.

---

Ex 2 — Case B: AHB burst, overhead amortized

Forecast: 200 MB/s se zyada (APB se better) lekin ideal 400 MB/s se kam — kyunki 2 waste hue cycles 8 useful cycles mein chhupi hain.

Steps

1. $W=32$, $L=8$, $c=2$ ko Tool 2 mein plug karo. Ye step kyun? Yahi "useful cycles vs total cycles" ka idea hai. $\text{Throughput}=\frac{32\times 8}{8+2}\times 100\times 10^6=\frac{256}{10}\times 100\times 10^6=2.56\times 10^9\text{bits/s}.$

2. Bytes mein convert karo: $2.56\times 10^9/8=320\times 10^6=320\text{MB/s}$. Ye step kyun? Answer MB/s mein maanga gaya tha.

Verify: Efficiency $=L/(L+c)=8/10=80\%$. Aur ideal $400$ MB/s ka $80\%$ $=320$ MB/s ✓.

---

Ex 3 — Case C: degenerate burst, $L=1$

Forecast: ye APB-jaisi numbers ki taraf collapse karna chahiye, kyunki sirf 1 useful word ke saath 2 overhead cycles dominate karte hain.

Steps

1. $L=1$ ko Tool 2 mein daalo. Kyun? Degenerate case formula ko break nahi karna chahiye — ise honestly plug karo. $\text{Throughput}=\frac{32\times 1}{1+2}\times 100\times 10^6=\frac{32}{3}\times 100\times 10^6\approx 1.067\times 10^9\text{bits/s}.$

2. Convert karo: $1.067\times 10^9/8\approx 133.3\text{MB/s}$.

Verify: Efficiency $=1/3\approx 33.3\%$. Ye APB ke 200 MB/s se bura hai — samajh aata hai: ek un-batched single word zyaatar cycles setup pe waste karta hai, isliye lone accesses ke liye bursting bekar hai. Yahi reason hai ki bursts exist karte hain.

---

Ex 4 — Case D: limiting behaviour, $L\to \infty$

Forecast: ideal 400 MB/s ke paas pahunchna chahiye lekin kabhi exceed nahi karna — fixed 2 cycles negligible ho jaate hain jab lakhon beats pe spread ho jaate hain.

Figure dikhata hai efficiency $L/(L+c)$ kaise 1 ki taraf badhti hai jab $L$ barhta hai:

Steps

1. $L\to \infty$ ke saath Tool 2 ka limit lo. Limit kyun? "Jab $L$ bahut bada ho jaata hai" bilkul wahi sawaal hai jiska limit jawab deta hai — ye wo value batata hai jiske paas curve creep karta hai lekin kabhi cross nahi karta. ${\lim }_{L\to \infty }\frac{WL}{L+c}=W\cdot {\lim }_{L\to \infty }\frac{L}{L+c}=W\cdot 1=W.$ (Upar aur neeche $L$ se divide karo: $\frac{1}{1+c/L}\to \frac{1}{1+0}=1$.)

2. Toh throughput $\to W\times f_{\text{clk}}=32\times 100\times 10^6=3.2\times 10^9$ bits/s $=400\text{MB/s}$.

Verify: Figure mein red curve dekho: ye dashed ceiling ki taraf flatten hoti hai aur kabhi touch nahi karti — bilkul wahi jo limit describe karta hai. Overhead amortized to zero ho jaata hai.

---

Ex 5 — Case E: AXI parallelism (multiple outstanding)

Forecast: roughly ek single burst ka 4× — lekin sirf tab agar slave aur wires actually carry kar sakein.

Steps

1. Single-burst throughput (Tool 2): $\frac{32\times 16}{16+2}\times 100\times 10^6=\frac{512}{18}\times 100\times 10^6\approx 2.844\times 10^9\text{bits/s}\approx 355.6\text{MB/s}.$ Ye step kyun? Multiply karne se pehle humein per-transaction number chahiye.

2. 4 outstanding transactions se multiply karo: $4\times 355.6\approx 1422\text{MB/s}.$ Ye step kyun? Outstanding transactions time mein overlap karte hain, isliye unke throughputs add hote hain — ek limit tak.

Verify: $355.6\times 4=1422$ MB/s ✓ (parent ke ≈1400 MB/s estimate se match karta hai).

---

Ex 6 — Case F: crossbar sizing (aur degenerate $N=1$)

Forecast: (a) switches $N\times M$ ke saath badhte hain toh 32 expect karo; arbiters aur comparators ek-per-slave = 8 each. (b) ek master ke saath arbitrate karne ko kuch nahi.

Crossbar grid — har red dot ek switch hai:

Steps

1. Switches $=N\times M=4\times 8=32$. Kyun? Har master ko har slave tak possible path chahiye; wo ek crosspoint per (master, slave) pair hai — red dots gino.

2. Arbiters $=M=8$. Kyun? Har slave ko ek saath kai masters request kar sakte hain; ek referee per slave winner choose karta hai.

3. Address comparators $=M=8$. Kyun? Har slave ek address range own karta hai; ek comparator decide karta hai "kya ye address mera hai?"

4. Degenerate $N=1$: switches $=1\times 8=8$, lekin arbiters $=M=8$ structurally exist karte hain, phir bhi har ek ke paas sirf ek requester hai → wo actually kabhi arbitrate nahi karte. Ye note kyun karo? Exam claim kar sakta hai "jab $N=1$ ho toh arbiters drop kar sakte hain." Structurally wo ek-per-slave hain; logically wo pass-through mein degenerate ho jaate hain. Dono baat kaho.

Verify: Complexity $O(N\times M)$ hai: $N$ ko double karke 8 karo toh $8\times 8=64$ switches milte hain — exactly double. Har dimension mein linear ✓.

---

Ex 7 — Case G: real-world word problem

Forecast: 4K60 famously "kuch GB/s" hai. Ek 64-bit 200 MHz link peak pe $\approx 1.6$ GB/s hai — ye close hoga, isliye carefully compute karo.

Steps

1. Bytes per frame: $3840\times 2160\times 3=24,883,200$ bytes. Kyun? Per frame total data = width × height × bytes-per-pixel.

2. Required bandwidth: $\times 60$ frames/s: $24,883,200\times 60=1,492,992,000\text{bytes/s}\approx 1493\text{MB/s}.$ Kyun? Har second 60 frames, toh per-frame ko 60 se multiply karo.

3. Link peak: $W=64$ bits at $200\times 10^6$ Hz: $64\times 200\times 10^6=12.8\times 10^9\text{bits/s}=1600\text{MB/s}.$

4. $90\%$ pe usable: $1600\times 0.9=1440\text{MB/s}$. Kyun? Real fabrics kabhi peak nahi pahunchte; efficiency factor overhead cycles account karta hai.

5. Compare karo: chahiye $\approx 1493$ MB/s, mile $1440$ MB/s. Link enough NAHI hai — $\approx 53$ MB/s se short hai.

Verify: $1493>1440$ ✓, toh answer "no" sahi hai. Fix options: 128-bit tak widen karo, clock badhao, ya compression add karo. Units check: bytes/s vs bytes/s throughout ✓.

---

Ex 8 — Case H: exam twist (sab kuch ek saath change hota hai)

Forecast: eyeball mat karo — numbers engineered hain close rehne ke liye.

Steps

1. Bus X: $16\times 250\times 10^6=4.0\times 10^9$ bits/s $=500\text{MB/s}$. Kyun? Tool 1 mein 1 cycle/transfer ke saath sirf $W\times f_{\text{clk}}$ reh jaata hai.

2. Bus Y: $32\times 100\times 10^6=3.2\times 10^9$ bits/s $=400\text{MB/s}$.

3. Compare karo: Bus X jeet jaata hai, $500>400$ MB/s. Surprise kyun? Width aur clock dono product ke roop mein matter karte hain. Narrow bus ke zyada clock ne compensate kar liya. Kabhi assume mat karo "wider = faster".

Verify: $16\times 250=4000$ aur $32\times 100=3200$; ratio $4000/3200=1.25$, toh Bus X $25\%$ faster hai ✓. Bytes mein: $500$ vs $400$ ✓.

---

Recall

Recall

$L=1$ ka burst AHB ko APB se slow kyun bana deta hai? Ek useful word aur 2 overhead cycles ke saath, efficiency $1/3$ hai; bursting tabhi payoff karta hai jab kai words ek address phase share karein. ::: Overhead ek single-word transfer mein dominate karta hai.

Recall Jab burst length

$L\to \infty$ ho, toh $\frac{WL}{L+c}{f}_{\text{clk}}$ kaun sa throughput approach karta hai aur kyun? Ye $W{f}_{\text{clk}}$ — ceiling — approach karta hai — kyunki fixed $c$ cycles amortized to zero ho jaate hain. ::: Peak width×clock rate.

Recall Ek single 32-bit channel pe, 4 outstanding AXI transactions 4× bandwidth kyun nahi de sakte?

Wire abhi bhi sirf $W{f}_{\text{clk}}$ bits/s carry karta hai; outstanding transactions latency hide karte hain, wire capacity add nahi karte. Real 4× ke liye multiple physical channels chahiye. ::: Channel abhi bhi physical bottleneck hai.

Recall

$N$ masters aur $M$ slaves wale full crossbar mein: kitne switches, arbiters, comparators? $N\times M$ switches, $M$ arbiters, $M$ comparators. ::: NM, M, M.

See also: Interconnect Topologies · DMA · Memory-Mapped I/O · DRAM Controllers · PCIe · Cache Coherence Protocols · Power Management