6.3.1 · D4 · HinglishInterconnects, Buses & SoC

ExercisesBus topologies and arbitration

2,259 words10 min read↑ Read in English

6.3.1 · D4 · Hardware › Interconnects, Buses & SoC › Bus topologies and arbitration

Ye problems L1 (sirf idea pehchano) se lekar L5 (sab kuch ek saath) tak graded hain. Pehle har ek problem khud try karo solution collapse karke, phir kholo. Yahan jo bhi symbol milenge wo sab parent note mein build kiye gaye hain — agar koi term naya lage, pehle woh note dobara padho.

Shuru karne se pehle, ek common picture. Neeche sab kuch teen numbers pe tika hai:

Figure — Bus topologies and arbitration

Upar ki figure mental model hai: ek single lane (shared bus), switches ki ek grid (crossbar), aur ek timeline jo slots mein kata hai (TDM). Ise dhyan mein rakho.


L1 — Recognition

Exercise 1.1 (L1)

Ek designer 4 peripherals ko ek common set of address+data+control wires se connect karta hai. Kisi bhi ek instant mein sirf ek hi peripheral transfer kar sakta hai. Is topology ka naam batao aur ek phrase mein bolo ki kyun sirf ek hi transfer ek waqt hoti hai.

Recall Solution

Topology: shared (parallel) bus. Kyun ek waqt mein ek: sab devices same physical wires se connected hain, isliye bus time-division multiplexing use karta hai — single wire ek moment mein sirf ek voltage pattern hold kar sakta hai, isliye exactly ek transaction use own karta hai.

Exercise 1.2 (L1)

Har phrase ko ek topology se match karo: (a) "switches ka matrix, simultaneous master–slave pairs", (b) "har device ka apna dedicated link ek switch tak", (c) "local buses jo bridges se ek tree mein jude hain".

Recall Solution
  • (a) Crossbar
  • (b) Point-to-point (jaise PCIe)
  • (c) Hierarchical / tree bus

L2 — Application

Exercise 2.1 (L2)

Ek shared bus ki total bandwidth hai. Heavy contention mein yeh masters mein evenly split ho jaati hai. Per-master bandwidth kya hogi?

Recall Solution

Even split ka matlab hai har master ko milta hai: Kyun divide karte hain? Wire time-shared hai; agar sab equally busy hain, toh har ek seconds own karta hai, isliye bytes bhi.

Exercise 2.2 (L2)

masters aur slaves ke saath ek crossbar banao. (a) Kitne switch points honge? (b) Maximum kitne concurrent transactions ho sakte hain?

Recall Solution

(a) Har master ko har slave tak path chahiye, isliye (b) Transactions chhoti side se zyada nahi ho sakti (ek slave ek time mein ek master serve karta hai, aur sirf slaves hain; isi tarah sirf masters hain):

Exercise 2.3 (L2)

Round-robin arbiter, masters, har transaction zyada se zyada leta hai. Ek master ko grant milne se pehle worst-case mein kitna wait karna pad sakta hai?

Recall Solution

Woh master jo abhi abhi apni turn chook gaya, usse baaki masters ka wait karna padega: kyun, kyun nahi? Master khud apni turn ka wait nahi karta — sirf unka wait karta hai jo circle mein usse aage hain.


L3 — Analysis

Exercise 3.1 (L3)

Fixed-priority arbiter jismein masters ka order hai (highest pehle). Har transaction ka hai. Pathological worst case mein, lowest priority master kitna wait kar sakta hai, aur yeh kaunsa phenomenon illustrate karta hai?

Recall Solution

ke paas higher-priority masters hain. Worst case mein woh ek ke baad ek queue karte hain: Lekin agar higher masters baar baar request karte rahen, toh yeh hamesha repeat hota rahega → true worst case unbounded hai. Yeh starvation hai: ek low-priority master ko indefinitely deny kiya ja sakta hai. sirf higher-priority traffic ke ek "round" ki delay hai; koi guaranteed ceiling nahi hai.

Exercise 3.2 (L3)

Ek system ke liye do arbiters compare karo jismein ek audio DMA hai (har mein ek sample chahiye, har baar ka ek transaction) aur ek CPU hai jo bus ko continuously hammer karta hai.

  • Arbiter A: fixed priority, CPU highest.
  • Arbiter B: round-robin, , .

Kaun sa arbiter guarantee karta hai ki audio DMA apna deadline meet kare? Numerically justify karo.

Recall Solution

Arbiter A (fixed, CPU high): CPU kabhi yield nahi karta jab tak woh request karta rahta hai → audio DMA unboundedly wait kar sakta hai. ka deadline guaranteed nahi. Result: audible glitches.

Arbiter B (round-robin): audio DMA ke liye worst wait hai Kyunki hai, deadline hamesha meet hoti hai bahut bade margin ke saath.

Conclusion: Round-robin (ya TDM slot) zaroori hai. Yahan "less important" master hi latency-critical ek hai — priority ≠ importance.


L4 — Synthesis

Exercise 4.1 (L4)

Ek SoC ko 6 masters ko 6 slaves se connect karna hai. Do candidate fabrics:

  • Shared bus: single link, , cost tap points.
  • Full crossbar: har link .

Compute karo (a) crossbar switch count, (b) crossbar aggregate bandwidth, (c) jab sab 6 masters alag alag slaves se baat karte hain toh shared bus ke mukable crossbar ka bandwidth speedup.

Recall Solution

(a) switches. (b) Aggregate . (c) Shared bus total deta hai; crossbar deta hai. Speedup Cost trade-off: Tumne switches pay kiye vs tap points ( hardware) aur bandwidth mila — yahi classic crossbar bargain hai, jab tak bahut bada na ho jaaye.

Exercise 4.2 (L4)

slots ki TDM schedule ek bus pe jiska raw bandwidth hai. Ek video engine ko slots assign kiye gaye hain. (a) Use kaunsi guaranteed bandwidth milegi? (b) Agar ek control CPU ko slot assign kiya jaaye, toh usse kya bandwidth milegi, aur woh key property kya hai jo TDM guarantee karta hai jo round-robin nahi karta?

Recall Solution

(a) . (b) CPU: . Key property: TDM har master ko ek fixed, pehle se pata hua slot deta hai → uska access time deterministic hai (exactly tab jab uska slot aata hai), aur slot ke dauran zero arbitration overhead hota hai. Round-robin ka grant depend karta hai ki aur kaun request kar raha hai, isliye timing sirf bounded hai, scheduled nahi.


L5 — Mastery

Exercise 5.1 (L5)

Ek smartphone SoC mein hai: 4 CPU cores, 1 GPU, 1 DMA engine, 1 camera ISP = 7 masters, aur 3 slaves: DRAM controller, ROM, peripheral block = 3 slaves.

Requirements:

  1. CPU↔DRAM aur GPU↔peripheral simultaneously aur zero interference ke saath run hone chahiye.
  2. Audio DMA (DMA engine ka part) ka bounded worst-case bus latency hona chahiye.
  3. Die area tight hai.

Interconnect design karo: topology choose karo, switch count do, aur har slave ke liye ek arbitration scheme choose karo, har choice ko teeno requirements ke against justify karo. Phir audio DMA ki worst-case latency compute karo agar DRAM ka arbiter round-robin hai un (zyada se zyada) 6 masters pe jo DRAM ko touch karte hain, ke saath.

Recall Solution

Topology — crossbar. Requirement 1 (simultaneous, non-interfering paths) independent point-to-point links per master–slave pair force karta hai → woh hi crossbar hai. Ek single shared bus CPU aur GPU ko serialize kar deta aur requirement 1 fail ho jaati.

Switch count: switches. Modest — requirement 3 ko full mesh se kahin zyada better satisfy karta hai; chhota slave count () ko low rakhta hai. Yahi reason hai ki real SoCs mein few slaves aur many masters hote hain.

Arbitration per slave (crossbar per slave arbitrate karta hai, kyunki contention tab hi hoti hai jab do masters same slave chahte hain):

  • DRAM controller: highest contention. Round-robin (ya weighted round-robin) use karo → bounded latency, requirement 2 satisfy karta hai audio DMA ke liye.
  • ROM: rarely contended, latency-tolerant → fixed priority theek hai aur sasta bhi.
  • Peripheral block: GPU↔peripheral path; agar sirf occasionally shared hai, toh fixed priority ya round-robin dono kaam karenge.

Audio DMA worst-case latency at DRAM: Maano 6 masters DRAM target kar sakte hain. Round-robin worst wait: Bounded → requirement 2 meet hua.

Summary table of reasoning:

  • Simultaneity → crossbar (shared bus nahi).
  • Bounded latency → hot slave pe round-robin (fixed priority nahi).
  • Area → chhota rakhne se switches, full mesh nahi.

Recall Quick self-check (pehle try karo phir reveal karo)

total aur equal masters wale shared bus mein per-master share ::: masters, slaves wale crossbar mein switch count ::: Crossbar max concurrent transactions ::: Round-robin worst-case wait ::: Fixed priority ka failure mode ::: starvation (unbounded low-priority wait) slots mein se slots ke liye TDM ki guaranteed bandwidth :::