Question bank — RISC-V custom extensions for accelerators

False — custom ops live in reserved opcode space that the standard toolchain never emits, so an ordinary standard binary is untouched and still runs correctly.

False — an unimplemented opcode raises an illegal-instruction trap; you get a clean fault, never a silent wrong answer, so correctness is preserved.

True — the spec permanently reserves custom-0..custom-3 for non-standard use, so standard extensions are forbidden from claiming them.

False — R-type is the natural template because the register file already has two read ports and one write port, but you can shape a custom opcode into other formats; R-type just minimises datapath changes.

False — net benefit = frequency × cycles-saved − (area + verification + Amdahl-limited ceiling); hardening a rarely-used op wastes silicon and buys almost nothing.

False — MMIO adds hundreds of cycles of bus round-trip per invocation regardless of the unit's speed, while a tightly-coupled unit gets operands straight from registers in a few cycles.

False — funct3/funct7 select which operation runs; the register fields rs1, rs2, rd select the data.

True — a loosely-coupled coprocessor has its own memory/DMA port, so it can stream a whole buffer while the CPU continues other work.

True — operands arrive from registers and results go straight back inside the pipeline, eliminating the address-setup / bus / polling latency an off-CPU device would impose.

The error is ignoring Amdahl's Law — speeding up a tiny fraction of runtime yields near-zero total gain; profile first and only harden the hot 20% (Amdahl's Law).

The error is calling it standard: R-type normally reads only rs1/rs2. Making rd also a source (read-modify-write) is a microarchitectural design choice you encode yourself, not default semantics.

The error is adding instead of multiplying — each slot independently holds $2^{10}$ ops, giving $4\times 2^{10}=4096$, not $4+1024$.

The error is choosing MMIO for a fine-grained op; the per-call bus overhead dwarfs the compute, killing the speedup. MMIO fits only coarse, infrequent, large-data offload.

The error is misplaced worry — reserved custom space cannot overlap standard opcodes by definition; the real concern is toolchain support, not opcode collision.

The error is crediting the opcode itself; real gains come from hiding many μops (e.g. a SIMD-wide computation) behind one issue slot — the encoding is just the trigger.

So you extend the hardware/software contract without breaking it — existing software still runs, and you add your ops legally without a vendor's permission.

Because most useful accelerator ops take two operands and produce one result, which maps exactly onto the two read ports and one write port — so hazard/forwarding/decode logic barely changes.

Because each call needs address setup, a bus transaction, and polling or interrupt handling — all of which a register-to-register custom instruction skips entirely.

The operands (a whole matrix) don't fit in a couple of registers and the op runs for many cycles, so you want an independent memory port and overlap with the CPU — the data-volume-over-latency tradeoff favours RoCC.

Because standard compilers never emit reserved opcodes on their own; the intrinsic is how high-level code like c = mac(a,b,c) gets mapped to your single instruction.

Because each custom core needs its own intrinsics/support to use the ops, but any core lacking them either never emits them (standard binary) or traps cleanly — the program never silently misbehaves.

Because rs1/rs2/rd name which data, not which operation; only funct3/funct7 distinguish operations, so only their bits size the op count.

It raises an illegal-instruction trap; the OS/handler can then emulate it in software or terminate cleanly — never a corrupt result.

No — it's legal in the spec (the space is theirs to define) but their binaries are mutually incompatible; the collision is a toolchain/agreement problem, not an ISA rule break.

Yes — that's exactly the win: one issue slot can drive a SIMD-wide or multi-cycle computation, hiding many μops, as long as the microarchitecture implements that behaviour.

Yes — if the op is rare its area/verification cost buys nothing and can hurt clock frequency or complicate the pipeline, so overall throughput or design efficiency can drop.

You must either add a read port (extra hardware), make one operand implicit (like rd in a MAC accumulate), or dispatch via a coprocessor interface — plain R-type alone cannot supply three sources.

For coarse, infrequent, large-data offload where the per-call bus overhead is negligible compared to the work done — there the independent device model wins (Memory-mapped I/O).