6.5.11
Ek CPU ka instruction set ek contract hota hai hardware aur software ke beech. RISC-V pehla
mainstream ISA hai jo legally aur technically tumhe khali opcode space deta hai taaki tum apni
khud ki instructions add kar sako jo tumhara apna accelerator chalaye — kisi vendor se
permission maange bina aur existing software ko toде bina. Tum contract ko extend kar rahe ho, rewrite nahi .
Definition Custom extensionEk custom extension instructions ka ek set hota hai jo tum RISC-V base ISA ke reserved/custom opcode
space use karke define karte ho, jisse CPU single instructions issue kar sakta hai jo ek
specialized hardware unit (ek accelerator) ko pipeline ke saath tightly couple karke trigger kare.
HUM ISKA KYU CHAHTE HAIN (80/20 core):
General-purpose CPUs narrow workloads ke liye flexible toh hain par slow hain (crypto, AI dot-products, DSP).
Ek dedicated ASIC fast toh hota hai par rigid hota hai.
Ek custom instruction sweet spot hai: CPU ka fetch/decode/registers/memory reuse karo, lekin
silicon mein ek hot operation add karo. Tum area sirf un 20% ops ke liye pay karte ho jo 80% runtime cause karte hain.
Intuition Alag chip / MMIO device kyun nahi?Memory-mapped I/O ke zariye off-CPU device se baat karna saikdon cycles kharchta hai (address
setup, bus, polling/interrupts). Ek custom instruction pipeline ke andar rehta hai: operands seedhe
registers se aate hain, result seedha wapas jaata hai — kuch cycles ki latency. Coupling ka tightness
hi poora point hai.
RISC-V opcodes ek 32-bit instruction ke low 7 bits hote hain (inst[6:0]). Spec non-standard use ke liye
chaar major opcodes reserve karta hai:
Tum inhe typically standard R-type format ki tarah shape karte ho taaki existing hardware datapaths (do
source registers, ek destination) reuse ho sakein:
7 funct7 5 rs2 5 rs1 3 funct3 5 rd 7 opcode
Register file mein pehle se two read ports aur one write port hain. Agar tumhari instruction
rs1, rs2 padhti hai aur rd likhti hai, toh decode/hazard/forwarding logic mein bahut kam badlaav hoga — tum bas
operands ko ek naye functional unit pe route karte ho. funct3/funct7 10 free bits hain = ek opcode slot mein 2 10
First principles se derivation. Ek R-type instruction mein ye variable fields hain jo select
karte hain kaun sa operation chalega (operands nahi): funct3 (3 bits) aur funct7 (7 bits). Register
fields rs1/rs2/rd data choose karte hain, operation nahi. Toh:
N ops per slot = 2 funct3 bits × 2 funct7 bits = 2 3 × 2 7 = 2 10 = 1024 4 custom slots (custom-0..3) ke saath:
N total = 4 × 1024 = 4096 distinct R-type custom instructions.
Worked example Dot-product accelerator ke liye fused multiply-accumulate design karnaGoal: ek instruction mac rd, rs1, rs2 jo r d ← r d + r s 1 ⋅ r s 2
Opcode custom-0 = 0001011 chuno. Kyun? Ye guaranteed collision-free hai.
funct3 = 000, funct7 = 0000000 chuno. Kyun? Ye "MAC" identify karne wala ek arbitrary free code hai.Datapath: rs1*rs2 multiply karo, purana rd add karo. rd kyun padhte hain?rd
source bhi hai aur destination bhi — ye ek design choice hai jo tum microarchitecture mein encode karte ho,
standard R-type semantics mein nahi.
Software: ise assembler .insn r directive ya compiler intrinsic se emit karo. Kyun?
Taaki high-level code (c = mac(a,b,c);) ek single instruction pe map ho.
Worked example Throughput gain compute karna (the "kyun bother" number)Maano length n mac = 3, lekin mac
internally ek issue mein 4-wide vector bhi process karta hai.
Baseline: 4 n
Accelerated: elements 4 per mac process hote hain, toh ≈ ( 2 + 1 ) ⋅ n /4 = 0.75 n Ye step kyun? Hum compute work ko us SIMD width se divide karte hain jo accelerator ek
instruction ke andar chhupa leta hai. Speedup = 4 n /0.75 n ≈ 5.3 × Ye realistic kyun hai? Real gains ek issue slot ke peeche bahut saare μops chhupane se aate hain, opcode se nahi.
Definition Tightly-coupled vs loosely-coupled
Tightly-coupled : unit pipeline ke andar hota hai, register file se operands milte hain, result
kisi bhi ALU op ki tarah write back hota hai. Sabse kam latency, chhota data.Loosely-coupled (e.g. RoCC – Rocket Custom Coprocessor) : custom instruction ek coprocessor ko ek
command dispatch karta hai jo independently memory/DMA access kar sakta hai aur bahut saare cycles tak chal sakta hai;
CPU continue kar sakta hai aur baad mein result collect kar sakta hai. Bade streaming data ke liye best.
Intuition Kaun sa choose karein?Agar operands registers mein fit hote hain aur op chhota hai → tightly-coupled. Agar tumhe poora
buffer (matrix, image, packet) crunch karna hai → loosely-coupled coprocessor apne memory port ke saath. Data
volume vs latency ka tradeoff decide karta hai.
Common mistake "Custom instructions binary compatibility tod dete hain, isliye RISC-V fragmented hai."Ye sahi kyun lagta hai: naye opcodes add karna lagta hai jaise ISA change ho raha hai, jo aksar
portability todta hai.
Fix: custom instructions reserved space mein rehti hain jo standard software kabhi emit nahi karta, aur
jo code inhe use karta hai woh tumhare specific core ke liye compile hota hai. Ek standard binary ab bhi unchanged chalti hai.
Fragmentation ek toolchain concern hai (har core ko apne intrinsics chahiye), correctness break nahi.
Ek CPU jo tumhara op implement nahi karta woh simply usp par trap karta hai — tumhe kabhi silently galat results nahi milte.
Common mistake "Zyada custom instructions = zyada speed."Ye sahi kyun lagta hai: hardware software se tez hota hai, isliye kuch bhi hardwire karna help karna chahiye.
Fix: benefit = (op ki frequency) × (cycles saved) − (area, verification, aur
Amdahl-limited returns). Rarely-use hone wale op ko accelerate karna silicon waste karta hai. Pehle profile karo (80/20
rule) aur sirf hot kernel ko harden karo.
Common mistake "Accelerator ko kisi bhi peripheral ki tarah memory bus pe lagao — same baat hai."Ye sahi kyun lagta hai: MMIO hardware add karne ka standard tarika hai.
Fix: MMIO har invocation pe saikdon cycles ka round-trip kharchta hai, fine-grained ops ke liye gains khatam kar deta hai. Custom instruction ke zariye tight coupling woh overhead hata deti hai. MMIO sirf coarse, infrequent, large-data offload ke liye use karo.
Recall Reveal karne se pehle answer kar sakte ho?
Chaar reserved custom opcodes ke naam batao aur ye safe kyun hain.
R-type custom instruction ke liye natural template kyun hai.
Derive karo ki ek opcode slot mein kitne custom R-type ops fit hote hain.
Tightly-coupled unit ki jagah loosely-coupled coprocessor kab choose karte ho?
Steel-man: "zyada custom instructions = zyada speed" galat kyun hai.
Recall Feynman: ek 12-saal ke bachche ko samjhaoEk chef (CPU) ki imagine karo jo koi bhi recipe follow kar sakta hai par dheere dheere. RISC-V cookbook mein kuch blank recipe
cards chhod deta hai. Tumhe allowance hai ki tum apni super-recipe ek blank card pe likho — jaise
"ek saath 100 sandwiches banao" — aur kitchen mein ek special machine banao jo exactly wahi kare.
Ab jab chef woh card padhta hai, ek word machine trigger karta hai aur lunch ek pal mein ready ho jaata hai.
Normal cookbook use karne wale doosre chefs confuse nahi hote, kyunki woh kabhi tumhare blank cards nahi padhte.
Mnemonic Design flow yaad rakho"Profile, Pick, Pack, Plumb, Prove" — Profile karo hot kernel, Pick karo custom opcode,
Pack karo R-type funct fields mein, Plumb karo operands apne unit tak (tight ya RoCC), Prove karo
toolchain mein intrinsics + tests ke saath.
RISC-V instruction mein kaun se opcode bits identify karte hain? Low 7 bits, inst[6:0].
RISC-V custom/non-standard use ke liye kaun se chaar opcodes reserve karta hai? custom-0 0001011, custom-1 0101011, custom-2 1011011, custom-3 1111011.
Custom instructions future standards se collide kyun nahi karti? Spec guarantee karta hai ki ratified extensions kabhi reserved custom opcode space use nahi karengi.
Custom instruction ke liye R-type natural format kyun hai? Register file pehle se do read ports (rs1,rs2) aur ek write port (rd) provide karta hai, isliye decode/forwarding reuse hota hai; funct3+funct7 free operation-select bits dete hain.
Ek opcode slot mein kitne distinct R-type custom ops fit hote hain? 2^3 (funct3) × 2^7 (funct7) = 1024.
Chaaon custom slots mein total kitne? 4 × 1024 = 4096.
Tightly-coupled vs loosely-coupled accelerator — key difference? Tight pipeline mein hota hai (register operands, low latency); loose (e.g. RoCC) apne memory/DMA ke saath coprocessor hai bade streaming data ke liye.
Accelerator ko MMIO se kyun nahi attach karte? MMIO round-trips saikdon cycles kharchte hain, fine-grained ops ke liye gains destroy kar dete hain; custom instructions woh overhead avoid karte hain.
Steel-man fix: "zyada custom instructions = zyada speed"? Benefit = op-frequency × cycles-saved − area/verification cost; sirf profiled hot kernel (80/20) ko harden karo, warna silicon waste hota hai.
Agar koi core tumhari custom instruction ke bina usse execute kare toh kya hota hai? Woh trap karta hai (illegal instruction) — koi silent wrong result nahi, isliye standard binaries safe rehti hain.
Tightly coupled accelerator
Register file 2 read 1 write
Encoding budget 2^10 sub-ops
Hundreds of cycles latency