Question bank — RISC-V custom extensions for accelerators

False — custom ops reserved opcode space mein rehte hain jo standard toolchain kabhi emit nahi karta, isliye ek ordinary standard binary untouched rehti hai aur sahi se chalti hai.

False — ek unimplemented opcode ek illegal-instruction trap raise karta hai; tumhe ek clean fault milta hai, kabhi bhi silent wrong answer nahi, isliye correctness preserve hoti hai.

True — spec permanently custom-0..custom-3 ko non-standard use ke liye reserve karta hai, isliye standard extensions unhe claim karne se forbidden hain.

False — R-type natural template hai kyunki register file mein already do read ports aur ek write port hote hain, lekin tum ek custom opcode ko dusre formats mein shape kar sakte ho; R-type sirf datapath changes ko minimise karta hai.

False — net benefit = frequency × cycles-saved − (area + verification + Amdahl-limited ceiling); ek rarely-used op ko harden karna silicon waste karta hai aur almost kuch nahi deta.

False — MMIO har invocation par saikdon cycles ka bus round-trip add karta hai chahe unit ki speed kuch bhi ho, jabki ek tightly-coupled unit kuch cycles mein seedha registers se operands leta hai.

False — funct3/funct7 select karte hain ki kaun si operation chalegi; register fields rs1, rs2, rd data select karte hain.

True — ek loosely-coupled coprocessor ka apna memory/DMA port hota hai, isliye yeh ek pura buffer stream kar sakta hai jabki CPU dusra kaam karta rehta hai.

True — operands registers se aate hain aur results seedha pipeline ke andar jaate hain, woh address-setup / bus / polling latency eliminate karke jo ek off-CPU device impose karta.

Error yeh hai ki Amdahl's Law ko ignore kiya ja raha hai — runtime ke ek tiny fraction ko speed up karne se total gain almost zero hoti hai; pehle profile karo aur sirf hot 20% ko harden karo (Amdahl's Law).

Error yeh hai ki ise standard kehna galat hai: R-type normally sirf rs1/rs2 read karta hai. rd ko bhi source banana (read-modify-write) ek microarchitectural design choice hai jo tum khud encode karte ho, default semantics nahi hai.

Error hai add karna instead of multiply karna — har slot independently $2^{10}$ ops hold karta hai, isliye $4\times 2^{10}=4096$ milte hain, nahi $4+1024$.

Error yeh hai ki ek fine-grained op ke liye MMIO choose karna; per-call bus overhead compute se zyada ho jaata hai, speedup khatam kar deta hai. MMIO sirf coarse, infrequent, large-data offload ke liye fit hai.

Error hai misplaced worry — reserved custom space definition se standard opcodes ke saath overlap nahi kar sakta; asli concern toolchain support hai, opcode collision nahi.

Error yeh hai ki credit opcode ko de rahe ho; asli gains kaafi saare μops hide karne se aate hain (jaise ek SIMD-wide computation) ek single issue slot ke peeche — encoding sirf trigger hai.

Taaki tum hardware/software contract ko extend karo bina todey — existing software chalti rehti hai, aur tum apne ops legally add karte ho bina kisi vendor ki permission ke.

Kyunki zyaatar useful accelerator ops do operands lete hain aur ek result produce karte hain, jo exactly do read ports aur ek write port par map hota hai — isliye hazard/forwarding/decode logic almost change nahi hota.

Kyunki har call ko address setup, ek bus transaction, aur polling ya interrupt handling chahiye hoti hai — jo sab ek register-to-register custom instruction skip kar deta hai.

Operands (poori matrix) couple of registers mein fit nahi hote aur op kaafi cycles chalti hai, isliye tum ek independent memory port aur CPU ke saath overlap chahte ho — data-volume-over-latency tradeoff RoCC ke favor mein hai.

Kyunki standard compilers kabhi khud reserved opcodes emit nahi karte; intrinsic woh tarika hai jisse high-level code jaise c = mac(a,b,c) tumhari single instruction par map hota hai.

Kyunki har custom core ko ops use karne ke liye apne intrinsics/support chahiye hote hain, lekin unhe lacking koi bhi core ya to unhe emit nahi karta (standard binary) ya cleanly trap karta hai — program kabhi silently misbehave nahi karta.

Kyunki rs1/rs2/rd bataate hain ki kaunsa data, kaun si operation nahi; sirf funct3/funct7 operations ko distinguish karte hain, isliye sirf unke bits op count ko size karte hain.

Yeh ek illegal-instruction trap raise karta hai; OS/handler phir use software mein emulate kar sakta hai ya cleanly terminate kar sakta hai — kabhi corrupt result nahi.

Nahi — yeh spec mein legal hai (woh space unka define karne ke liye hai) lekin unki binaries mutually incompatible hain; collision ek toolchain/agreement problem hai, ISA rule break nahi.

Haan — yahi exactly fayda hai: ek issue slot ek SIMD-wide ya multi-cycle computation drive kar sakta hai, kaafi saare μops hide karke, jab tak microarchitecture woh behaviour implement kare.

Haan — agar op rare hai to uska area/verification cost kuch nahi deta aur clock frequency hurt kar sakta hai ya pipeline complicate kar sakta hai, isliye overall throughput ya design efficiency drop ho sakti hai.

Tumhe ya to ek read port add karna hoga (extra hardware), ek operand implicit banana hoga (jaise MAC accumulate mein rd), ya coprocessor interface se dispatch karna hoga — plain R-type akela teen sources supply nahi kar sakta.

Coarse, infrequent, large-data offload ke liye jahan per-call bus overhead kiye gaye kaam ke muqable mein negligible ho — wahan independent device model jeet jaata hai (Memory-mapped I/O).