RISC-V custom extensions for accelerators: Worked examples

6.5.11 · D3 · Hardware › Advanced & Emerging Architectures › RISC-V custom extensions for accelerators

The scenario matrix

Is topic ke har problem ka ek case class hota hai. Neeche ke worked examples har cell ke saath tagged hain, aur milke poora grid cover karte hain.

#	Case class	Kya cheez tricky hai	Covered by
A	Encoding budget — normal	field widths se ops count karo	Ex 1
B	Encoding — degenerate / zero	ek slot, zero free bits, "kitne bacha"	Ex 2
C	Bit-assembling a real instruction	funct7/rs2/rs1/funct3/rd/opcode ko 32 bits mein pack karo	Ex 3
D	Speedup — normal (Amdahl)	fraction accelerated < 1	Ex 4
E	Speedup — limiting case	fraction → 1, ya infinite hardware speed	Ex 5
F	Coupling choice — small data	tight vs loose decision	Ex 6
G	Coupling choice — large streaming data	RoCC / DMA regime	Ex 6
H	Real-world word problem	crypto/AI kernel, pehle profile karo	Ex 7
I	Exam twist / trap	"unimplemented op" behaviour, saturating result ka sign	Ex 8
J	Boundary of the opcode space	saare 4 slots use ho gaye, khatam ho raha hai	Ex 9

Dekho ki grid counting, bit-packing, performance, architecture choice, aur traps sab span karti hai. Ab hum har cell cover karte hain.

Case A — Encoding budget, the normal count

Worked example

Ex 1 (cell A). Ek custom opcode slot mein kitne distinct custom R-type operations reh sakte hain, aur chaaronon slots mein milake kitne?

Forecast: ek power of two guess karo, phir ×4…

R-type layout yaad karo: sirf wahi fields jo decide karti hain ki kaun si operation chalegi (kaunsa data nahi) woh hain funct3 (3 bits) aur funct7 (7 bits).

Step 1. Operation-selecting bits count karo: $3 + 7 = 10$ bits. Ye step kyun? Register fields rs1/rs2/rd operands choose karte hain, op nahi, isliye woh distinct instructions ki sankhya multiply nahi karte. Sirf funct fields karte hain.

Step 2. Har bit possibilities ko double karta hai, isliye ek slot mein $N_{slot} = 2^{10} = 1024 ops.$ Kyun? $n$ independent binary choices $2^{n}$ combinations dete hain — fundamental counting law.

Step 3. 4 reserved slots hain (custom-0…3): $N_{total} = 4 \times 1024 = 4096.$ Kyun? Opcode field khud kaun sa slot pick karta hai, aur chaar choices disjoint hain, isliye hum add karte hain (equivalently slot count ko 4 se multiply karte hain).

Verify: $2^{10} = 1024$ ✓, $4 \cdot 1024 = 4096$ ✓. Sanity: poora opcode 7 bits ka hai (inst[6:0]), jo $2^{7} = 128$ opcodes total deta hai; sirf 4 custom hain, jo "4 slots" se match karta hai ✓. Units: sirf count, koi dimensions nahi — correct.

Case B — Degenerate / zero free bits

Worked example

Ex 2 (cell B). Tumhari team ne custom-0 mein funct7 = 0000000 ke saath saare aath funct3 values use kar liye. Koi claim karta hai "is slot mein abhi bhi $1024 - 8 = 1016$ ops bacha hai." Sahi hai ya galat, aur real number kya hai?

Forecast: kya ye 1016 hai, ya kuch aur…

Step 1. Slot mein total ops $= 1024$ (Ex 1 se). Ye step kyun? Ceiling chahiye pehle, phir jo use ho gaya usse subtract karenge.

Step 2. Used ops: ek funct7 value saare 8 funct3 values ke saath paired $= 1 \times 8 = 8$ . Kyun? funct7 fix karke funct3 sweep karne se exactly 8 encodings milte hain.

Step 3. Remaining $= 1024 - 8 = 1016$ . Kyun? Remaining encodings sirf used set ka complement hain — subtraction valid hai kyunki har $(funct7, funct3)$ pair ek distinct instruction hai.

The subtle degenerate check: agar instead unhone saare 128 funct7 values ek single funct3=000 ke saath use kiye hote, toh $128 \times 1 = 128$ used hote, $1024 - 128 = 896$ bachta. Aur fully degenerate case — saare 1024 used — 0 bachta hai, matlab slot exhaust ho gaya aur tumhe custom-1 par jaana hoga.

Verify: $1024 - 8 = 1016$ ✓, $1024 - 128 = 896$ ✓, $1024 - 1024 = 0$ ✓. Toh claim "1016" stated usage ke liye sahi hai, lekin dhyan raho ye poori tarah depend karta hai kaun sa field sweep hua — ek common trap.

Case C — Bit-assembling a real instruction

Worked example

Ex 3 (cell C). mac x5, x6, x7 (matlab $x 5 \leftarrow x 5 + x 6 \cdot x 7$ ) ko ek 32-bit R-type word ke roop mein encode karo using opcode = custom-0 = 0001011, funct3 = 000, funct7 = 0000000. Hex do.

Forecast: fields left-to-right likho, phir convert karo…

Neeche diya field diagram dekho. Ye poora 32-bit word dikhata hai jo chhe R-type boxes mein split hai, bit 31 bilkul left par aur bit 0 bilkul right par. Har coloured box apne field name, bit-width, aur us mein daali jaane wali binary value ke saath labelled hai: blue funct7 box (bits 31–25), orange rs2 = x7 box (bits 24–20), green rs1 = x6 box (bits 19–15), gray funct3 box (bits 14–12), red rd = x5 box (bits 11–7), aur blue opcode box (bits 6–0). Neeche caption yaad dilata hai ki kaun se boxes operation select karte hain (funct7 + funct3) versus kaun se data (rs1, rs2, rd).

Step 1. Register numbers ko 5-bit binary mein convert karo: $x 5 \to 00101$ , $x 6 \to 00110$ , $x 7 \to 00111$ . Ye step kyun? Har register field exactly 5 bits ka hota hai ( $2^{5} = 32$ registers), isliye hum 5 tak pad karte hain.

Step 2. Fields ko R-type order funct7 | rs2 | rs1 | funct3 | rd | opcode mein lay karo. Yahan $r s 1 = x 6$ , $r s 2 = x 7$ , $r d = x 5$ : $70000000 r s 2 = x 7 00111 r s 1 = x 6 00110 f 3 000 r d = x 5 00101 o p co d e 0001011$ Kyun? Hardware decoder in bit-positions ko fixed location se padhta hai; order galat karo toh galat register read hoga.

Step 3. 32 bits mein concatenate karo aur nibbles (4 bits each) mein group karo: $00000000011100110000001010001011$ Ab har nibble ko ek hex digit ki tarah padho ( $0000 \to 0$ , $0111 \to 7$ , $0011 \to 3$ , $0010 \to 2$ , $1000 \to 8$ , $1011 \to B$ ): $= 0x0073028B .$ Nibbles kyun? Char bits per hex digit — standard binary→hex conversion.

Verify: Low 7 bits hain 0001011 = custom-0 ✓. Wapas padhte hain: opcode 0001011, rd=00101=5, funct3=000, rs1=00110=6, rs2=00111=7, funct7=0000000 ✓. VERIFY mein hum confirm karte hain ki integer 0x0073028B ke barabar hai.

Case D — Speedup, the normal Amdahl regime

Worked example

Ex 4 (cell D). Ek program apna 60% time ek dot-product kernel mein spend karta hai. Tum use ek custom instruction mein harden karte ho jo us kernel ko 8× faster chalata hai. Amdahl's Law se, overall speedup kya hai?

Forecast: NOT 8×… 2× aur 3× ke beech guess karo…

Step 0 — numbers ko naam do. Maano $f = 0.60$ kernel mein runtime ka fraction hai, aur $s$ us kernel ka local speedup hai — yahan $s = 8$ (kernel 8× faster chalta hai). Ye step kyun? Formula mein aane se pehle har symbol define karna zaroori hai; $s$ sirf shorthand hai "accelerated part kitni baar faster chalta hai" ke liye.

Step 1. Runtime ko accelerated fraction $f = 0.60$ aur untouched fraction $1 - f = 0.40$ mein split karo. Ye step kyun? Sirf hot part speed up hota hai; baaki ek fixed floor hai — yahi Amdahl ka poora point hai.

Step 2. New time (old time = 1), $s = 8$ use karke: $T_{new} = (1 - f) + \frac{f}{s} = 0.40 + \frac{0.60}{8} = 0.40 + 0.075 = 0.475.$ Sirf $f$ ko $s$ se kyun divide kiya? Accelerator accelerated part ko uski speedup $s = 8$ se shrink karta hai; serial part unchanged rehta hai.

Step 3. Overall speedup: $S = \frac{1}{T _{new}} = \frac{1}{0.475} \approx 2.105.$ Reciprocal kyun? Speedup = old-time ÷ new-time, aur old-time $= 1$ .

Neeche diya figure ye concrete banata hai. Top bar baseline runtime hai (gray serial part $0.40$ + orange kernel $0.60 = 1.0$ ). Bottom bar acceleration ke baad hai: wahi gray $0.40$ serial part, lekin kernel tiny green sliver $0.60/8 = 0.075$ mein shrink ho gaya hai, isliye poora bar sirf $0.475$ lamba hai. Red dashed line $0.40$ par serial floor mark karti hai — chahe green sliver kitna bhi shrink ho jaaye, bottom bar kabhi us line se left end nahi ho sakta, isliye speedup $1/0.40 = 2.5 \times$ par cap hai.

Verify: $0.40 + 0.075 = 0.475$ ✓, $1/0.475 \approx 2.105$ ✓. Sanity: infinite kernel speed bhi at most $1/0.40 = 2.5 \times$ deta hai (serial ceiling), aur $2.105 < 2.5$ ✓. 8× local speed barely 2× global bani — exactly woh "zyada speed hamesha zyada speed nahi" wala lesson.

Case E — Limiting cases of speedup

Worked example

Ex 5 (cell E). Usi kernel fraction $f = 0.60$ ke liye, absolute maximum overall speedup nikalo, aur alag se woh speedup nikalo agar $f \to 1$ (almost saara time kernel mein) fixed local speedup $s = 8$ ke saath.

Forecast: ceiling kya hai jab hardware infinitely fast ho?

Step 1 (infinite hardware, $s \to \infty$ ). $\frac{f}{s} \to 0$ , isliye $S_{m a x} = \frac{1}{( 1 - f )} = \frac{1}{0.40} = 2.5.$ Ye step kyun? $s$ ko infinity bhejna best case hai — ye serial ceiling expose karta hai jise tum chahe kitna achha accelerator lo, beat nahi kar sakte.

Step 2 ( $f \to 1$ , $s = 8$ ). Ab $1 - f \to 0$ : $T_{new} \to 0 + \frac{1}{8} = 0.125, S = \frac{1}{0.125} = 8.$ Kyun? Jab sab kuch accelerated hota hai, global speedup local speedup $s$ ke barabar hota hai — serial floor gaayab ho jaata hai.

Verify: $1/0.40 = 2.5$ ✓ aur $1/0.125 = 8$ ✓. Do limits reality ko bracket karte hain: finite $f < 1$ aur finite $s$ ke liye true speedup hamesha $s$ aur $1/ (1 - f)$ dono se strictly neeche hoga. Ex 4 ka answer $2.105 < min (8, 2.5)$ ✓ — consistent.

Case F & G — Choosing the coupling

Worked example

Ex 6 (cells F & G). Har workload ke liye decide karo tightly-coupled (in-pipeline, register operands) vs loosely-coupled (RoCC coprocessor with its own memory port). (a) Ek register par ek single 64-bit population-count. (b) Memory mein ek 4 KiB network packet buffer ko AES-encrypt karna.

Forecast: kaun se ko apna memory port chahiye?

Step 1 — (a) data volume. Operand = ek 64-bit register value, result = ek register. Ye step kyun? Deciding axis hai data volume vs invocation latency (parent ka rule).

Step 2 — (a) decision. Registers mein fit ho jaata hai, one-shot, latency-sensitive → tightly-coupled. Kyun? Register read/write ports reuse karne se few-cycle result milta hai near-zero plumbing ke saath, jabki dispatch overhead itne tiny op par dominate kar deta.

Step 3 — (b) data volume. 4 KiB = 4096 bytes AES ke kaafi rounds ke through stream hone chahiye. Kyun? Tum poora packet register file mein nahi rakh sakte (sirf ~32 registers wide hain).

Step 4 — (b) decision. Large streaming buffer → loosely-coupled RoCC with DMA: CPU ek dispatch issue karta hai, coprocessor independently memory walk karta hai jabki CPU continue karta hai. Kyun? 4 KiB register-file operands se feed karne mein hazaaron load/store instructions lagenge — exactly woh overhead jo memory-side coprocessor remove karta hai.

Verify: Memory-mapped I/O se cross-check karo: MMIO per invocation hundreds of cycles add karta hai, isliye (a) ke tiny op ke liye MMIO worst hai; (b) ke single coarse offload ke liye RoCC ka per-invocation cost 4096 bytes par amortize hota hai → acceptable. Decisions "coarse & large → loose, fine & small → tight" heuristic se consistent hain ✓.

Case H — Real-world word problem (profile first)

Worked example

Ex 7 (cell H). Ek image filter 500 M instructions per frame chalta hai. Profiling dikhata hai ki ek 3×3 convolution kernel un instructions ka 35% hai aur uske har instruction ko ek custom op se replace kiya ja sakta hai jo kaam 1/6 cycles mein karta hai. Baaki sab untouched hai. (i) Tum kaisa overall speedup expect karte ho? (ii) Kya ek alag routine accelerate karna jo sirf 2% runtime hai worth hai silicon ke liye?

Forecast: guess karo (i) 1.4× ke paas, aur (ii) clearly no…

Step 1. $f = 0.35$ identify karo, local speedup $s = 6$ . Ye step kyun? Design karne se pehle profile karna hi "Profile" hai "Profile, Pick, Pack, Plumb, Prove" mein — tum sirf measured hot kernel ko harden karte ho.

Step 2. Amdahl apply karo: $T_{new} = 0.65 + \frac{0.35}{6} = 0.65 + 0.0583 \overline{3} = 0.70833 \overline{3},$ $S = \frac{1}{0.70833 3} \approx 1.4118.$ Kyun? Same law Ex 4 jaisa — un-accelerated 65% floor set karta hai.

Step 3 — (ii). 2% routine: best possible overall speedup hai $S_{m a x} = \frac{1}{1 - 0.02} = \frac{1}{0.98} \approx 1.0204,$ matlab at most 2% faster chahe infinite hardware ho. Kyun? Amdahl se, fraction $f$ accelerate karne ka upper bound $1/ (1 - f)$ hai. 2% fraction kabhi verification + silicon area nahi repay kar sakta.

Verify: $0.65 + 0.35/6 = 0.708 \overline{3}$ ✓, reciprocal $\approx 1.4118$ ✓, $1/0.98 \approx 1.0204$ ✓. Conclusion: convolution accelerate karo (≈1.41× real gain); 2% routine skip karo (≤1.02× ceiling) — textbook 80/20 decision.

Case I — Exam trap: unimplemented op & saturating sign

Worked example

Ex 8 (cell I). Do-part trap. (a) Tumhare custom mac ke saath compile hua binary ek standard RISC-V core par chalta hai jisme woh nahi hai. Kya hota hai — galat answer, ya kuch aur? (b) Tumhara mac saturating signed 8-bit accumulation use karta hai. $r d \leftarrow r d + r s 1 \cdot r s 2$ compute karo $r d = 100$ , $r s 1 = 20$ , $r s 2 = 3$ ke liye signed 8-bit saturation (range $- 128 \dots 127$ ) ke under.

Forecast: (a) silently corrupt NAHI karta; (b) negative par wrap karta hai, ya clamp?

Step 1 — (a). Core opcode 0001011 decode karta hai, find karta hai ki unimplemented hai, aur ek illegal-instruction trap raise karta hai. Kyun? Reserved custom encodings guaranteed hain ki standard op ke saath alias nahi karenge, isliye core kabhi silently kuch galat execute nahi karta — woh fault karta hai, aur software handle kar sakta hai. Ye parent note ka "custom instructions compatibility tod dete hain" myth kill karta hai.

Step 2 — (b) raw arithmetic. $r s 1 \cdot r s 2 = 20 \times 3 = 60$ ; phir $r d + 60 = 100 + 60 = 160$ . Ye step kyun? Pehle true math karo, phir saturation rule apply karo.

Step 3 — (b) saturate. $160 > 127$ (signed 8-bit max), isliye 127 par clamp karo, NOT $160 - 256 = - 96$ par wrap karo. Kyun? Saturating arithmetic out-of-range results ko nearest representable value par clamp karta hai; ye deliberately ordinary two's-complement ke sign-flip wraparound se bachata hai — trap hai $- 96$ choose karna.

Verify: $20 \times 3 = 60$ ✓, $100 + 60 = 160$ ✓, clamp $(160, - 128, 127) = 127$ ✓, aur galat wrap answer $- 96$ hoga ✓ (dikhaya gaya hai taaki tum trap spot kar sako). Part (a): unimplemented ⇒ trap, kabhi silent corruption nahi ✓.

Case J — Boundary of the opcode space

Worked example

Ex 9 (cell J). Ek giant accelerator design ko 4100 distinct custom R-type operations chahiye. Kya 4 reserved custom slots kaafi hain? Agar nahi, toh kitna overflow hai, aur ek legitimate escape kya hai?

Forecast: 4096 vs 4100 — tum pehle se feel kar sakte ho: chaar slots thodi si short padenge. Overflow count guess karo, phir ek tarika jo opcode bits kharchе bina hazaaron aur ops de…

Step 1. Saare slots ki capacity $= 4 \times 1024 = 4096$ (Ex 1). Ye step kyun? Ye pure R-type custom encodings ki hard ceiling hai — tum ise R-type format ke andar cleverness se exceed nahi kar sakte.

Step 2. Overflow $= 4100 - 4096 = 4$ operations jo fit nahi ho sakti. Kyun? Jab har $(slot, funct7, funct3)$ triple use ho jaata hai, literally koi free R-type encoding nahi bachti; last 4 requested ops ke liye koi jagah nahi.

Step 3. Escape route: ek sub-op selector in an immediate field encode karo (ek alag instruction format use karo jo 12-bit immediate carry karta ho), ya ek RoCC command ke through dispatch karo jiska function code register mein pass hota hai — ek opcode trade karke thousands of coprocessor-side operations milti hain. Kyun? Tum scarce opcode bits per operation spend karna band karte ho aur instead operation ko data se select karte ho, jo effectively unlimited hai: ek single 12-bit immediate already $2^{12} = 4096$ sub-ops name karta hai ek opcode ke peechhe.

Verify: $4 \cdot 1024 = 4096 < 4100$ ✓, overflow $= 4$ ✓. Sanity: ek single 12-bit immediate akela hi $2^{12} = 4096$ sub-ops encode karta hai per instruction, jo 4-op shortfall se kaafi zyada hai ✓ — isliye escape more than sufficient hai.

Active recall

Recall Humne kaun se cells cover kiye, aur kya tum har family mein se ek reproduce kar sakte ho?

Counting (A/B/J): $2^{10}$ per slot, $4096$ total, used subtract karo, immediate se escape karo.
Bit-packing (C): funct7|rs2|rs1|funct3|rd|opcode → hex.
Performance (D/E/H): $T = (1 - f) + f / s$ , ceiling $1/ (1 - f)$ .
Architecture (F/G): data volume vs latency → tight ya RoCC.
Traps (I): unimplemented ⇒ trap; saturate clamps karta hai, wraps nahi.

Recall Quick self-tests

Ek custom slot ka encoding budget? ::: $2^{3} \times 2^{7} = 1024$ ops. Overall speedup agar $f = 0.6$ , $s = 8$ ? ::: $1/ (0.4 + 0.075) = 1/0.475 \approx 2.11 \times$ . Absolute ceiling jab $f = 0.6$ ? ::: $1/ (1 - 0.6) = 2.5 \times$ . $100 + 20 \cdot 3$ ka saturating signed-8? ::: clamp $(160) = 127$ , $- 96$ nahi. Standard core tumhara custom op mile? ::: illegal-instruction trap, kabhi silent wrong result nahi.

Connections

RISC-V base ISA (RV32I / RV64I)
R-type instruction format
Amdahl's Law
Rocket Chip and RoCC coprocessor interface
Memory-mapped I/O
Hardware accelerators vs general-purpose CPUs
Vector / SIMD extensions (RVV)
Domain-specific architectures
Instruction Set Architecture

Ek opcode slot mein kitne custom R-type ops fit hote hain?

2^{10} = 1024

mac x5,x6,x7 ka hex encoding (custom-0, funct3=000, funct7=0)?

0x0073028B.