Exercises — RISC-V custom extensions for accelerators

Char reserved custom opcodes hain: custom-0 = 0001011, custom-1 = 0101011, custom-2 = 1011011, custom-3 = 1111011. Answer: (b) 0001011 = custom-0. Baaki standard hain: 0110011 OP hai (register ALU / R-type), 0000011 LOAD hai, 1100011 BRANCH hai. Inhe kabhi mat chhuo — custom code ka pura point yahi hai ki woh wahan rehta hai jahan standard software kabhi emit nahi karta.

rd field (destination register), 5 bits wide, inst[11:7] occupy karta hai (upar ki table dekhein). Yeh data destination choose karta hai, operation nahi. Operation-selecting fields hain funct3 (inst[14:12]) aur funct7 (inst[31:25]).

Operation funct3 (3 bits) aur funct7 (7 bits) se choose hota hai. Register fields data pick karte hain, operation nahi, isliye unhe count nahi karte. $N_{\text{per slot}}=2^3\times 2^7=8\times 128=2^{10}=1024.$ Answer: 1024 distinct ops per slot.

$N_{\text{total}}=4\times 1024=4096.$ Answer: 4096.

MMIO: $300\times 10^6=3\times 10^8$ cycles. Custom instruction: $4\times 10^6=4\times 10^6$ cycles. Ratio $=\frac{3\times 10^8}{4\times 10^6}=75$. Answer: MMIO $3\times 10^8$ cycles spend karta hai, custom $4\times 10^6$; custom instruction overhead mein $75\times$ sasta hai. Yahi parent note ka "coupling tightness is the whole point" claim hai, numeric banaya gaya.

Amdahl's Law: agar runtime ka fraction $p$, factor $s$ se accelerate ho, toh total speedup hai $S=\frac{1}{(1-p)+\frac{p}{s}}.$ Ideal ($s\to \infty$): $S_{\max }=\frac{1}{1-p}=\frac{1}{1-0.4}=\frac{1}{0.6}\approx 1.67\times .$ Realistic ($s=5$): $S=\frac{1}{0.6+0.4/5}=\frac{1}{0.6+0.08}=\frac{1}{0.68}\approx 1.47\times .$ Answer: zyada se zyada $1.67\times$; realistically $\approx 1.47\times$. Sabak yeh hai: 40% kernel ki infinite acceleration bhi $1.67\times$ nahi todi ja sakti. Isliye pehle profile karo — ek chhoti-fraction kernel ko accelerate karna silicon ki barbaadi hai.

(A) → tightly-coupled. Operands registers mein fit hote hain, latency tiny hai, aur yeh constantly invoke hoti hai, isliye per-invocation dispatch overhead near-zero hona chahiye. rs1, rs2 ko ek naye functional unit par route karo, rd wapas likhao jaise koi bhi ALU op. (B) → loosely-coupled (RoCC). 4 MB registers mein fit nahi hota; unit ko apna memory/DMA port chahiye aur yeh hazaaron cycles chalta hai. Ek command dispatch karo, CPU ko continue karne do, baad mein result collect karo. Data volume vs latency tradeoff decide karta hai: chhota+chhota → tight, bada+streaming → loose.

Har field fill karo (figure table ke bit ranges use karke):

• funct7 = 0000000 → inst[31:25]
• rs2 = x7 = 00111 → inst[24:20]
• rs1 = x6 = 00110 → inst[19:15]
• funct3 = 000 → inst[14:12]
• rd = x5 = 00101 → inst[11:7]
• opcode = custom-0 = 0001011 → inst[6:0]

MSB→LSB concatenate karo (spaces sirf fields alag karte hain, word ka part nahi hain): 0000000 00111 00110 000 00101 0001011 Ek 32-bit word mein: 00000000011100110000010100001011. Ab in 32 bits ko baayein se 4-4 ke nibbles mein regroup karo: 0000 0000 0111 0011 0000 0101 0000 1011 = 0 0 7 3 0 5 0 B = 0x0073050B. Answer: 0x0073050B.

Place value se sanity check. Har field contribute karta hai (uski value) apne starting bit par left shift hokar: $\text{opcode}=11$ at bit 0, $\text{rd}=5$ at bit 7 gives $5\cdot 128=640$, $\text{funct3}=0$, $\text{rs1}=6$ at bit 15 gives $6\cdot 32768=196608$, $\text{rs2}=7$ at bit 20 gives $7\cdot 1048576=7340032$, $\text{funct7}=0$. Sum $=11+640+196608+7340032=7537291$, aur $7537291=\text{0x0073050B}$. ✓

Teen-source subtlety ke baare mein. Standard R-type semantics rs1, rs2 read karte hain aur sirf rd write karte hain — encoding exactly do source register addresses deta hai. Lekin mac ko ek third source chahiye: rd ki purani value. R-type encoding mein koi teesra source named nahi hota. Toh extension ise ek microarchitectural convention se resolve karta hai: aapka custom decode logic rd field ko dono — ek read address aur ek write address (same register ka read-modify-write) — treat karta hai, register file ka ek extra read rd ka add karke. Aap koi naya bit-field nahi bana rahe — aap existing rd field ko ek dusra meaning de rahe hain sirf apni unit ke andar. (Real designs mein alternatives: ek fixed accumulator register dedicate karo, ya ek RoCC unit mein accumulator internal state ke roop mein rakho taaki koi teesra register-file port na chahiye.)

Baseline: $4n$ instructions, kisi bhi $n$ ke liye valid. Accelerated, $n$ jo 4 ka multiple hai: $n/4$ full groups hain, har ek mein $2$ loads $+1$ mac $=3$ issues ka cost hai: $\text{issues}=3\cdot \frac{n}{4}=0.75n,\text{speedup}=\frac{4n}{0.75n}=\frac{4}{0.75}\approx 5.33\times .$ General $n$ (edge case). $n=4q+r$ likhein jahan quotient $q=\lfloor n/4\rfloor$ aur remainder $r=n\mathrm{mod}4\in \{0,1,2,3\}$ ho. $4q$ elements $q$ full mac groups mein chalte hain. Baaki bache $r$ elements 4-wide mac fill nahi kar sakte, isliye unhe ek scalar tail loop se baseline cost $4$ instructions each par finish karo: $\text{issues}(n)=3q+4r=3\lfloor \frac{n}{4}\rfloor +4(n\mathrm{mod}4).$

• Check $n=8$: $q=2,r=0\Rightarrow 6$ issues ($0.75\cdot 8$ se match karta hai).
• Check $n=10$: $q=2,r=2\Rightarrow 3\cdot 2+4\cdot 2=14$ issues; speedup $=40/14\approx 2.86\times$ — lower clean $5.33\times$ se, kyunki tail unaccelerated hai. Jaise $n\to \infty$, tail ki fixed cost negligible ho jaati hai aur speedup $5.33\times$ ke paas aata hai. Answer: clean case $\approx 5.3\times$; remainder hone par tail loop ratio ko neeche kheenchta hai, bilkul $n=10$ ke example mein dikhaaya gaya. Gain ek issue slot ke peeche 4 μops chhupane se aata hai (SIMD width), opcode se nahi. Vector / SIMD extensions (RVV) se compare karo, jisme runtime-set vector length is haath se likhe tail-loop ki problem hataa deti hai.

Amdahl: $S=\frac{1}{(1-p)+p/s}$. Candidate 1 ($p=0.30$, $s=8$): $S_1=\frac{1}{0.70+0.30/8}=\frac{1}{0.70+0.0375}=\frac{1}{0.7375}\approx 1.356\times .$ Candidate 2 ($p=0.05$, $s=20$): $S_2=\frac{1}{0.95+0.05/20}=\frac{1}{0.95+0.0025}=\frac{1}{0.9525}\approx 1.050\times .$ Whole-program: Candidate 1 deta hai $\approx 1.36\times$; Candidate 2 sirf $\approx 1.05\times$ deta hai, apne flashy $20\times$ kernel figure ke bawajood. Per engineer-month benefit: C1 khareeda $0.356$ speedup / 6 months $\approx 0.059$ per month; C2 khareeda $0.050$ / 1 month $=0.050$ per month. C1 dono — raw benefit aur cost efficiency — mein jeetta hai. Answer: pehle Candidate 1 banao. Deciding factor hai runtime ka fraction $\times$ aapne kitna cut kiya, unaccelerated remainder se cap hoke — kernel-only multiplier nahi. Yahi parent note ka "benefit = frequency × cycles saved − cost, Amdahl-limited" concrete bana hai. Same reasoning chip scale par dekhne ke liye Hardware accelerators vs general-purpose CPUs aur Domain-specific architectures dekhein.

Unka core custom-0 decode karta hai, uske liye koi functional unit nahi pata, aur illegal-instruction trap raise karta hai. Program ruk jaata hai (ya OS trap handle karta hai) — yeh silently koi alag operation execute nahi karta. Yahi safety guarantee hai: ek unimplemented custom op trap karta hai, kabhi galat result nahi deta. Standard binaries ki portability untouched rehti hai, kyunki standard software kabhi custom-0..3 emit nahi karta. Yahan fragmentation purely ek toolchain matter hai (har core ko apne intrinsics/assembler support chahiye), correctness break nahi — bilkul parent note mein steel-man ki tarah.