Exercises — RISC-V custom extensions for accelerators

The four reserved custom opcodes are custom-0 = 0001011, custom-1 = 0101011, custom-2 = 1011011, custom-3 = 1111011. Answer: (b) 0001011 = custom-0. The others are standard: 0110011 is OP (register ALU / R-type), 0000011 is LOAD, 1100011 is BRANCH. You never touch those — the whole point is that custom code lives where standard software never emits.

The rd field (destination register), 5 bits wide, occupying inst[11:7] (see the table above). It chooses data destination, not operation. The operation-selecting fields are funct3 (inst[14:12]) and funct7 (inst[31:25]).

The operation is chosen by funct3 (3 bits) and funct7 (7 bits). Register fields pick data, not operation, so they don't count. $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 spends $3\times 10^8$ cycles, custom spends $4\times 10^6$; the custom instruction is $75\times$ cheaper in overhead. This is exactly the "coupling tightness is the whole point" claim from the parent note, made numeric.

Amdahl's Law: if fraction $p$ of runtime is accelerated by factor $s$, total speedup is $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: at most $1.67\times$; realistically $\approx 1.47\times$. The lesson: even infinite acceleration of a 40% kernel can't beat $1.67\times$. This is why you profile first — accelerating a small-fraction kernel is silicon wasted.

(A) → tightly-coupled. Operands fit in registers, latency is tiny, and it's invoked constantly, so per-invocation dispatch overhead must be near-zero. Route rs1,rs2 to a new functional unit, write rd back like any ALU op. (B) → loosely-coupled (RoCC). 4 MB does not fit in registers; the unit needs its own memory/DMA port and runs thousands of cycles. Dispatch a command, let the CPU continue, collect the result later. The data volume vs latency tradeoff decides it: small+short → tight, large+streaming → loose.

Fill each field (using the bit ranges from the figure table):

• 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]

Concatenate MSB→LSB (spaces just separate fields, they are not part of the word): 0000000 00111 00110 000 00101 0001011 As one 32-bit word: 00000000011100110000010100001011. Now regroup those 32 bits into nibbles of 4 (from the left): 0000 0000 0111 0011 0000 0101 0000 1011 = 0 0 7 3 0 5 0 B = 0x0073050B. Answer: 0x0073050B.

Sanity check by place value. Each field contributes (its value) shifted left by its starting bit: $\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$, and $7537291=\text{0x0073050B}$. ✓

On the three-source subtlety. Standard R-type semantics read rs1, rs2 and only write rd — the encoding gives you exactly two source register addresses. But mac needs a third source: the old value of rd. Nothing in the R-type encoding names a third source. So the extension resolves it by a microarchitectural convention: your custom decode logic treats the rd field as both a read address and a write address (a read-modify-write of the same register), adding an extra register-file read of rd. You are not inventing a new bit-field — you are giving the existing rd field a second meaning inside your unit only. (Alternatives real designs use: dedicate a fixed accumulator register, or add an accumulator as internal state in a RoCC unit so no third register-file port is needed.)

Baseline: $4n$ instructions, valid for any $n$. Accelerated, $n$ a multiple of 4: there are $n/4$ full groups, each costing $2$ loads $+1$ mac $=3$ issues: $\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$ (the edge case). Write $n=4q+r$ with quotient $q=\lfloor n/4\rfloor$ and remainder $r=n\mathrm{mod}4\in \{0,1,2,3\}$. The $4q$ elements run in $q$ full mac groups. The leftover $r$ elements cannot fill a 4-wide mac, so you finish them with a scalar tail loop at the baseline cost of $4$ instructions each: $\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 (matches $0.75\cdot 8$).
• Check $n=10$: $q=2,r=2\Rightarrow 3\cdot 2+4\cdot 2=14$ issues; speedup $=40/14\approx 2.86\times$ — lower than the clean $5.33\times$, because the tail is unaccelerated. As $n\to \infty$ the tail's fixed cost is negligible and the speedup approaches $5.33\times$. Answer: clean case $\approx 5.3\times$; with a remainder the tail loop drags the ratio down, exactly as shown for $n=10$. The gain comes from hiding 4 μops behind one issue slot (SIMD width), not from the opcode itself. Compare with Vector / SIMD extensions (RVV), whose runtime-set vector length removes this hand-written tail-loop headache.

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 gives $\approx 1.36\times$; Candidate 2 gives only $\approx 1.05\times$, despite its flashier $20\times$ kernel figure. Per engineer-month benefit: C1 buys $0.356$ speedup / 6 months $\approx 0.059$ per month; C2 buys $0.050$ / 1 month $=0.050$ per month. C1 still wins on both raw benefit and cost efficiency. Answer: build Candidate 1 first. The deciding factor is fraction of runtime $\times$ how much you cut it, capped by the un-accelerated remainder — not the kernel-only multiplier. This is the parent note's "benefit = frequency × cycles saved − cost, Amdahl-limited" made concrete. See Hardware accelerators vs general-purpose CPUs and Domain-specific architectures for the same reasoning at chip scale.

Their core decodes custom-0, finds no functional unit for it, and raises an illegal-instruction trap. The program stops (or the OS handles the trap) — it does not silently execute a different operation. That is the safety guarantee: an unimplemented custom op traps, it never returns a wrong result. Portability of standard binaries is untouched, because standard software never emits custom-0..3. Fragmentation here is purely a toolchain matter (each core needs its own intrinsics/assembler support), not a correctness break — exactly the steel-man in the parent note.