virtualjaguar-libretro/docs/gpu-timing-spec.md

Jaguar GPU (TOM RISC) Cycle-Level Timing Specification

Ground-truth timing rules for the GPU cost model in virtualjaguar-libretro (issues #401 / #313: emulated GPU finishes work 2-4x faster than hardware).

Primary source: jag_sim/netlists/tom/*.NET — these are the ORIGINAL Flare/Atari design source files (netlist language with the designers' own comments, dated 1991-92, including dated bug-fix notes). They are not reverse-engineered: they are the files the TOM silicon was compiled from. The MiSTer core (Jaguar_MiSTer/rtl/Rework/*.v, e.g. sboard.v module _sboard) and jag_sim/verilog/tom/*.v are 1:1 mechanical translations of these netlists into structural Verilog (Torlus's translator), so the .NET files are strictly more readable and equally authoritative. The DSP in JERRY uses the same pipeline blocks (jag_sim/netlists/jerry/SBOARD.NET, EXECON.NET, DSP_MEM.NET, DSP_GATE.NET), so every rule below applies to the DSP as well, with "local RAM" = 8K DSP RAM and the gateway talking to JERRY's bus interface.

All costs are in GPU ticks = system clocks (26.590906 MHz NTSC; the GPU, blitter, OP and memory controller all run in this one clock domain; the 68000 runs at sysclk/2). Evidence tags:

• [RTL file:lines] — read directly from the netlist source.
• [RTL-derived] — follows from the netlist state machines by short hand analysis (1-2 flops of reasoning); high confidence.
• [JTRM prose] — stated in the Technical Reference Manual.
• [inference — needs simulation] — bounded but exact count should be confirmed with a Verilator run of jag_sim (recipe in §9).

Source citations below are relative to the root of a checkout of ElectronAsh/jag_sim (the netlists/tom/*.NET and netlists/jerry/*.NET files are the original Flare design sources, comments intact). Clone it anywhere to follow along; nothing in this repository depends on its location.

---

1. Pipeline shape (what the model must represent)

Three overlapping stages [PREFETCH.NET:9-21, EXECON.NET:8-18, SBOARD.NET:7-27]:

1. Prefetch — a 32-bit queue holding two 16-bit instructions; program words are always fetched in pairs from a long-word boundary; a fetch is initiated whenever there is room for two more instructions [PREFETCH.NET:14-17, 227-241].
2. Decode/execute — one instruction is decoded through the microcode ROM into a latched microword and executed in one tick when no wait is asserted (exe = vins & !wait & exec) [EXECON.NET:80-93, INS_EXEC.NET:267-284].
3. Write-back — results (ALU, move, immediate, internal load, external load, divide) are written to the register file in a later tick, and the scoreboard conceals the write behind the read ports when it can; when it can't, it stalls execution [SBOARD.NET:414-449, 523-541].

The emulator does not need to model the structure — only the stall rules below, which are exactly what the structure produces.

---

2. Baseline issue rate

R1. Every instruction issues in 1 tick when no hazard applies. ALU ops (ADD/SUB/logic/shifts/SAT/MOVE/CMP/BTST...), MULT/IMULT (the 16x16 multiplier is combinational — MP16 [ARITH.NET:103-107]), MOVEQ, MOVETA, MOVEFA, NOP: 1 tick. Confirms JTRM "all instructions execute in one cycle unless noted". [RTL: EXECON.NET:80-93; ARITH.NET:103-110] Confidence: pinned.

IMULTN/IMACN/RESMAC also issue 1/tick — the product/accumulate is pipelined (macop_p, macop_pp [ARITH.NET:71-73]) and the sequence is made atomic with the next instruction [INS_EXEC.NET:210-223], so a MAC chain sustains 1 tick per IMACN. Confidence: pinned.

---

3. Scoreboard interlocks (the missing 30-50%)

The scoreboard compares the pending write-back address at pipe stage 1 against the source and destination fields of the current instruction and suspends execution on a match [SBOARD.NET:20-26, 144-156].

R2. ALU result-use interlock: +1 tick. If instruction N+1 reads the register written by instruction N (ALU-class result, reswr), N+1 stalls exactly 1 tick (aludwait = alu_wback & (dst-match & dst-read-enabled | src-match & src-read-enabled)) [SBOARD.NET:132-156]. The pending window is one stage deep (single alu_wbaddr register), so an instruction two slots later pays nothing. Note: the destination operand of a normal ALU op is also a read (it is dstrrd), so ADD r1,r2 ; ADD r2,r3 stalls, and so does ADD r1,r2 ; ADD r3,r2. MOVE/MOVEQ write without reading dst (dstrwr, dstwen) — ADD r1,r2 ; MOVEQ #0,r2 does NOT match on dst-read but the write-write is resolved by write-back priority, not a stall [SBOARD.NET:106-130, INS_EXEC.NET:305-318]. Confidence: pinned.

R3. Flags interlock: +1 tick. An instruction that uses the ALU flags issued immediately after one that loads them stalls 1 tick (flagwait = flag_pend & flag_depend, flag_pend = flagld delayed one tick) [SBOARD.NET:405-412]. flag_depend = conditional JUMP/JR (condition field non-zero) or ADDC/SUBC [INS_EXEC.NET:448-457]. The canonical CMP ; JR cc pair therefore costs +1 tick. Put one instruction between the compare and the branch to avoid it. Confidence: pinned.

R4. Write-back port steal: +1 tick (second-order). A write-back is invisible when it can go out on a register port the current instruction is not using, or whose address matches the operand being read. If the current instruction reads both ports and the pending write-back address matches neither, or if two write-backs mature in the same tick, execution stalls 1 tick (wbwait = (!wbdeq & !wbseq & bothen & wback) + mult_wback) [SBOARD.NET:523-541, 414-449]. This mostly fires in load-heavy code where an internal/external-load write-back lands while a two-operand instruction executes. Confidence: pinned (condition), frequency in real code needs simulation.

---

4. Loads and stores

Decoded memrw instructions request a local-bus cycle; the local bus arbitration priority is (highest first): I/O (68K register access) > gateway (returning external program data) > data (load/store) > program fetch [GPU_MEM.NET:30-35, 121-127]. A local memory transfer is a one-tick cycle following the arbitrated request [GPU_MEM.NET:128-143].

R5. Internal load (GPU local RAM / GPU-visible internal regs): 3-tick latency, non-blocking, max 1 in flight. "Internal loads take three ticks, but only one of these may be pending. (This also applies to stores.)" [SBOARD.NET:177-184 — designer's words]. Timeline: T0 exe + datreq; T1 RAM cycle + datack; T2 data pipelined (mem_data [GPU_MEM.NET:249-252]) and written back. Execution continues underneath. Stalls only when:

• the load's target register is read before write-back (ldwait via dlaeq/slaeq while the load engine is not idle) [SBOARD.NET:236-245];
• another load/store issues while the engine is busy (ldwaitt[2] = !idle & memrw) [SBOARD.NET:244] — so back-to-back local loads sustain 1 load per 2 ticks;
• LOAD rX,rY ; <op using rY> immediately: ~2 stall ticks [RTL-derived]. Confidence: pinned.

R6. Indexed addressing ((R14/R15+n), (R14/R15+Rn)) — address precompute adds 2 ticks before the memory request. These opcodes set precomp (instructions 43,44,49,50,58-61 [INS_EXEC.NET:361-365]); the load engine walks comp1, comp2 (address through the ALU) before raising the request [SBOARD.NET:223-258, 264-271]. Indexed local load: request at T2, RAM cycle T3, data T4 → engine busy ~4 ticks; a dependent use right after costs ~3-4 stalls. Confidence: RTL-derived (state machine explicit); exact overlap with next instruction — needs simulation for the ±1.

R7. Indexed STORE: +1 tick on the instruction itself. "An extra wait state is generated for computed address cycles, to read this data" (compdwait) [EXECON.NET:173-189]. So STORE rN,(R14+n) costs 2 ticks of issue even before any bus effect. Plain STORE issues in 1 tick. Confidence: pinned.

R8. Local STORE: fire-and-forget, engine busy ~2 ticks. Store data is latched and the RAM cycle happens in the background; the next instruction runs unless it is itself a load/store (R5 busy rule). Confidence: pinned.

R9. External LOAD (DRAM/cart/TOM regs): non-blocking, up to 2 in flight, latency = local handoff (2) + bus grant + memory cycle + return (2). Mechanism: the local cycle "completes with no data" (del_xld [GPU_MEM.NET:183-192]), the gateway takes over and raises a bus request, and the scoreboard tracks the outstanding target register(s) [SBOARD.NET:273-343, GATEWAY.NET:75-137]. Costs:

• Pipeline keeps executing. Stall only when: target register of either outstanding load is read (xlddwait) [SBOARD.NET:325-339]; a third load is issued (twold) ; any load/store issues while the gateway is active (mbusywait = memrw & (gate_active + twold) ...); or a store issues while any external load is pending (datwe_raw & (oneld+twold)) [SBOARD.NET:345-357].
• Absolute-best-case latency from exe to register-usable, bus already owned by TOM, DRAM page hit: ~7-8 ticks — T0 exe, T1 local serv (del_xld), T2 gateway active + breq, T3 arbitration latch (arben at ack boundary [ARB.NET:119-124]), T4-T5 DRAM page-mode cycle [MEM.NET:150-165,185-197], T5 data latched (ddatld), T6 xld_ready (FD1Q delay [GATEWAY.NET:160-168]), T7 write-back. [inference from RTL chain — needs simulation for the exact constant]
• Add bus-grant latency if TOM does not own the bus (§7).
• Add DRAM page-miss / ROM wait states (§8). Confidence: mechanism and stall conditions pinned; the constant "7-8" needs simulation (bound: 6-9).

R10. External STORE: non-blocking issue (1 tick), but the gateway stays gate_active for the whole bus transaction; the next load/store stalls until it completes. Write data is enabled the tick after the bus ack [GATEWAY.NET:253-260]. So isolated external stores are nearly free to the GPU; a burst of external stores runs at bus speed (one per grant+cycle). Confidence: pinned (mechanism); per-store bus cost from §7/§8.

---

5. Jumps

R11. The instruction after a jump ALWAYS executes (mandatory delay slot). The jump is latched and only passed to the prefetcher when the next instruction is ready, precisely so programmers can rely on the delay slot [PREFETCH.NET:67-99 — designer's words: "To allow programmers to rely on the instruction after jump being executed"]. Jumps are atomic with the following instruction (no interrupt between) [INS_EXEC.NET:141-208].

R12. Taken JUMP (Rn): ~4 ticks for {jump + delay slot} when running from local RAM = 1 (jump) + 1 (delay slot, useful work) + ~2 dead ticks while the queue is flushed (force0 [PREFETCH.NET:129]) and the pair at the target is fetched (request, RAM cycle+ack, queue-ready). Net penalty vs. straight-line: +2 ticks. [RTL-derived from PREFETCH queue/ack chain — needs simulation for the exact refill count (bound 2-3)]

R13. Taken JR (relative): +1 tick over JUMP. The relative target is computed from the pipelined source one tick later (jrel), and insrdy is masked while jrel is active [PREFETCH.NET:82-99, 174-179]. Net penalty +3 ticks. Same confidence as R12.

R14. Not-taken JR/JUMP: 1 tick (condition evaluates false, no queue flush) — plus the R3 flags interlock (+1) if it directly follows the flag-setting op. Confidence: pinned.

If the jump target/stream is in external memory, replace the 2-tick refill with a full external program fetch (§7, §8; and R18).

---

6. Divide, MMULT, MOVEI

R15. DIV: 1 tick issue + 16 ticks background; result usable at tick ~18. Non-restoring divider computes 2 bits per tick; div_active lasts 16 ticks after div_start [DIVIDE.NET:7-10, 240-262]; write-back is requested in the first tick after div_active drops [SBOARD.NET:386-396]. Stalls only when: the destination register is read while the divide runs (divdwait), or a second DIV issues before completion (diviwait) [SBOARD.NET:369-403]. Reading the remainder register (G_REMAIN) is an internal load and should also only be done after completion. So DIV r1,r2 ; <17 independent instructions> hides the divide completely; DIV r1,r2 ; use r2 costs ~17 stall ticks. Confidence: pinned.

R16. MOVEI: 3 ticks minimum (opcode + two immediate words each consumed on insrdy through states imm1, imm2 [EXECON.NET:118-133]); it also drains 2 extra words from the prefetch queue, so out of local RAM with the queue previously full it is exactly 3; when fetch-starved it is longer. Interrupts cannot split it [INS_EXEC.NET:141-208]. Confidence: pinned.

R17. MMULT (systolic matrix multiply): per-element pipelined memory read + MAC; N-element column ≈ 2 ticks/element + setup; it holds the data-request path (mtx_mreq ORed into datreq [INS_EXEC.NET:601-606]) and other memory ops stall behind it (mbusywait gate) and interrupts are locked out (mtx_atomic). [SYSTOLIC.NET; INS_EXEC.NET:155-158, 234-241] Confidence: mechanism pinned; per-element constant [inference — needs simulation].

---

7. External bus: arbitration, grant latency, blitter/OP interaction

R18. Bus priority (highest → lowest), definitive list [ARB.NET:85-95, matches JTRM]:

pr	master
10	daisy-chained external bus master
9	DRAM refresh
8	DSP (high priority, DMAEN)
7	GPU (high priority, DMAEN)
6	Blitter (high priority, BUSHI)
5	Object Processor (video fetch)
4	DSP (normal)
3	68K under interrupt
2	GPU (normal)
1	Blitter (normal)
0	68K (always requesting; default owner)

R19. Re-arbitration happens at every memory-cycle ack (arben = q2 & ack — ownership can change only when TOM holds the bus off the 68K and the memory state machine finishes a cycle) [ARB.NET:105-124]. Consequences:

• GPU (2) vs. blitter at normal priority (1): the GPU WINS. A running blit does NOT block a GPU external access beyond the current memory cycle: the blitter requests the bus continuously for the whole blit (blit_breq active while outer loop busy [OUTER.NET:134-141]) but the GPU's pending request preempts it at the next ack boundary. GPU grant latency over a normal-priority blit ≈ remainder of the in-flight bus cycle (0..cycle_len-1) + 1 arbitration tick. The blit stretches by the GPU's cycles (this is the "GPU steals blitter cycles" direction, not the reverse).
• BUSHI blits (pr 6) beat normal GPU (2): the GPU's external access waits until the blit finishes (or until refresh preempts) unless the GPU sets DMAEN (pr 7 > 6), which is the documented escape hatch: FLAGS bit 15 gives GPU data transfers DMA priority [GATEWAY.NET:66-73,272-283].
• OP video fetch (5) beats normal GPU (2): during the active-display portion of a line, OP object fetches win every arbitration; GPU external accesses effectively wait for horizontal gaps. On text/HUD-heavy lines this is the dominant stall for GPU external traffic. [RTL: priority list; magnitude needs simulation/measurement]
• 68K interaction: the 68K is the default owner. When no internal master held the bus, TOM must raise BR and wait for BG (state machine 0→1→2 [ARB.NET:33-45]); the 68K grants between its own bus cycles — add ~2-12 sysclks (a 68K bus cycle is 4 CPU clocks = 8 sysclks) for the handoff when the 68K was running. When a daisy-chained master releases, the bus returns to the 68K first [ARB.NET:126-134]. [RTL + 68K datasheet; exact distribution needs simulation]

R20. BUS_HOG (G_CTRL bit 11): after an external program fetch the GPU holds its bus request for 4 extra ticks so consecutive external fetches chain without re-arbitrating [GATEWAY.NET:262-270]. Confidence: pinned.

R21. GPU program fetch and data load may both be pending externally at once (gateway handles one bus transaction at a time; program returns via gatereq onto the local bus, stealing one local-bus tick from the next fetch/data cycle) [GPU_MEM.NET:16-28, 150-213]. Confidence: pinned.

---

8. Memory-cycle lengths (TOM memory controller)

State machine in [MEM.NET:150-273]; one state = 1 sysclk; ack overlaps the idle/branch state, so charge the states between grant and ack:

cycle	length (sysclks)
DRAM read/write, page hit (match)	2 (states 3a,3b) per 1-4 sub-cycles depending on bus width vs transfer width
DRAM page miss: RAS precharge + row access first	+ (2..4) + (1..3) = +3..+7 by dramspeed (MEMCON1): speed0/1 → 4+3, speed2 → 3+2, speed3 → 2+1 [MEM.NET:167-183, 339-361]
CAS-before-RAS refresh	~9 states, steals the bus at pr 9 [MEM.NET:199-215]
ROM (cart)	2 + wait{2,3,5,7} by romspeed (MEMCON2); fastrom skips waits [MEM.NET:217-234, 428-442]
fast internal device (TOM/JERRY regs)	write 1, read 2 [MEM.NET:236-249]
external I/O device	2 + wait{1,3,7,15} by iospeed [MEM.NET:251-266]

A 64-bit-wide DRAM bank transfers 64 bits per column sub-cycle; narrower widths run multiple sub-cycles (MEMWIDTH breaks the transfer up, nextc per sub-cycle) — e.g. a phrase access to 16-bit cart ROM = 4 sub-cycles. The GPU's external data accesses are ≤32-bit (msize), i.e. one sub-cycle on the 64-bit DRAM. Actual dramspeed/romspeed values are whatever the boot ROM programs into MEMCON1/MEMCON2 — read them from the emulated registers rather than hardcoding. Confidence: state machine pinned; consult MEMCON defaults at runtime.

R22. Executing GPU code FROM external memory: every 2 instructions cost a full external bus transaction (grant + cycle + gateway return + 1 local bus tick), lower priority than data loads; with BUS_HOG the transactions chain. Order of magnitude: 6-15+ sysclks per instruction pair vs 1 from local RAM. [RTL-derived; needs simulation for tight numbers]

---

9. Fetch starvation from local RAM (why 1/tick is the ceiling)

The GPU local RAM (1K x 32, single port [GPU_MEM.NET:325-334]) serves program fetch at the LOWEST local priority [GPU_MEM.NET:30-35]. A pair fetch (2 instructions) takes a request tick + a service tick, so straight-line code exactly keeps the 2-deep queue full: sustained 1 instr/tick is achievable, and every scoreboard stall gives the prefetcher headroom. But each load/store to local RAM also consumes one RAM service tick at higher priority, and 32-bit instructions (MOVEI) drain 3 words, so dense load/store+MOVEI sequences intermittently empty the queue (1-tick bubbles). [RTL-derived; per-pattern exact bubbles need simulation]

---

10. Interrupt entry

The interrupt control unit hijacks the instruction stream and injects the call sequence (intser overriding the prefetch output [INS_EXEC.NET:225-247]); it cannot break MOVEI, MMULT, IMULTN/IMACN pairs, or jump+delay-slot (atomic terms [INS_EXEC.NET:141-223]). Entry cost = the injected sequence (store return address, redirect) ≈ 4-6 ticks + refetch at the vector. [inference — needs simulation]

---

11. Contrast: current emulator model (what to change)

src/tom/gpu.c today:

• gpu_opcode_cycles[64] is all 1s (gpu.c:178-188) — correct only for R1; DIV, MOVEI, indexed stores, jumps are all charged 1.
• GPU_EXT_ACCESS/bus_arbiter_charge_access (gpu.c:59-63) charges a flat external-access cost — the only non-unit cost in the model, and it charges it synchronously (blocking), whereas hardware external loads are split-transaction/non-blocking (R9) — but since VJ retires the load instantly, a blocking charge of the full latency is actually the right shape for an event-driven core; the missing part is everything else.
• No scoreboard interlocks (R2-R4), no flags interlock (R3), no load latency (R5/R6), no jump costs (R12-R13), no divide latency (R15), no MOVEI cost (R16).

Minimal implementable rule set (per-opcode add-on costs, GPU ticks)

For an interpreter that retires one instruction at a time, model the scoreboard as "last writer" state:

state: last_alu_dst (reg# or NONE), last_flags_set (bool),
       load_busy_until (tick), load_dst (reg#), div_busy_until (tick),
       div_dst (reg#), ext_pending (0..2) with dst regs, gate_active_until
per instruction:
  cost = 1
  if reads(last_alu_dst): cost += 1                       # R2
  if uses_flags && last_flags_set: cost += 1              # R3
  if reads(load_dst) && now < load_ready: cost += load_ready - now   # R5
  if reads(div_dst)  && now < div_ready:  cost += div_ready - now    # R15
  if is_div && now < div_done: cost += div_done - now     # R15 second div
  if is_memop && engine_busy: cost += busy_remaining      # R5/R9/R10
  if is_store && ext_pending: cost += until_ext_done      # R9
  opcode extras: MOVEI +2; indexed STORE +1; JUMP taken +2; JR taken +3;
                 (delay slot then executes normally)
  loads:  local LOAD ready at now+3 (indexed now+5); external LOAD ready at
          now + 2 + grant_latency + mem_cycle + 2  (do not block issue)
  update last_alu_dst := dst for ALU-class writes else NONE
  update last_flags_set := instruction sets flags (and not held in a wait)

grant_latency and mem_cycle come from the existing bus_arbiter, which should implement the R18 priority table with re-arbitration at cycle boundaries (R19) — notably GPU-over-blitter preemption at normal priority and OP wins during active display.

Expected effect: typical GPU kernels (dependent ALU chains + CMP/JR loops + loads) gain ~40-100% more cycles per instruction, which is the right order to close the 2-4x gap of #401 without touching machine timing.

---

12. What could NOT be pinned by reading — Verilator recipe

Needs simulation (all bounded above, exact constants wanted):

1. Taken JUMP/JR dead-tick count from local RAM (bound 2-3 / 3-4) — R12/R13.
2. External load end-to-end constant with idle bus (bound 6-9 sysclks) and its distribution vs. 68K ownership — R9/R19.
3. MMULT per-element rate — R17.
4. Interrupt entry cost — §10.
5. Fetch-starvation bubbles for MOVEI/load-dense code — §9.
6. GPU grant-latency distribution while a normal blit / BUSHI blit / OP fetch is running — R19.

Recipe (jag_sim, already cloned here)

• Tool: Verilator; harness exists at jag_sim/verilog/verilator/ (verilate.sh builds top module emu from jag_sim/verilog/jaguar.sv with -I../base -I../tom -I../jerry, plus main.cpp, bios.cpp, ssram.cpp, dram model in dram.cpp; boot ROM image verilog/os.mem).
• Faster targeted alternative: verilate only the GPU island — top = gpu (from verilog/tom/gpu.v, translation of GPU.NET) plus gpu_mem, gateway; drive clk[0], tie the coprocessor-bus ack to a scripted bus model. That avoids booting the whole console.
• Loading a GPU kernel (full-chip route): in main.cpp's DRAM/68K path, poke the kernel into GPU RAM ($F03000+) through the 68K I/O port (or bypass: write the words directly into the gpu_ram memory array in the verilated model — Vemu___024root exposes it), write G_PC = $F03010, then set GPUGO in G_CTRL ($F02114 bit 0).
• Instrument: per-tick sample of the netlist-named signals (Verilator --public or /*verilator public*/ on the translated nets): gpu.ins_exec.execon.exe (instruction retires), sbwait, aludwait, flagwait, ldwait, xlddwait, mbusywait, wbwait, divdwait (inside sboard), progreq/progack, datreq/datack (gpu_mem), gpu_breq/gpu_back, mreq/ack (TOM mem). Count ticks between exe pulses per kernel = ground-truth CPI; the wait lines attribute every bubble to a rule above.
• Kernels to run (assemble with any Jaguar RISC assembler, e.g. rmac): a) 64x dependent ADD chain (R2); b) same with interleaving (R1); c) CMP/JR loop (R3+R12-14); d) LOAD/use distance sweep 0..4 (R5); e) indexed load/store sweep (R6/R7); f) DIV then use at distance 0/8/17 (R15); g) MOVEI burst (R16); h) external load loop with 68K stopped vs. spinning (R9/R19); i) kernel while a large SRCEN+DSTEN blit runs, BUSHI off/on (R19); j) same during active display vs. VBLANK (OP).

---

13. Cross-check corpus

• JTRM "Software Reference" pipeline prose agrees with R1/R2/R11/R15 (it documents the scoreboard, the jump delay slot, and divide 2 bits/cycle). Where JTRM is silent (exact stall counts, arbitration boundaries), the netlists above are the only written authority.
• MiSTer rtl/Rework/{sboard,execon,prefetch,gateway,mem,arb}.v — same logic, usable to confirm the translation introduced no timing edits (the only GE-tagged functional edits found: mem.v DRAM ram_rdy synchronization for the FPGA's external RAM — MEM.NET:286-288,364-369 — which slightly ALTERS MiSTer's DRAM pacing vs. real silicon; do not treat MiSTer DRAM cycle counts as authentic, use the §8 state machine).

---

14. Verilator-pinned results (2026-08-11, jag_sim netlist GPU)

Micro-kernels driven through the verilated GPU island; full method and raw counts in the calibration session's VERILATOR-RESULTS.md.

• R9 resolved — external LOAD latency: L = 7 + D sysclks (slope exactly 1 across D=1..8; identical for use-distance k=0..5, latency max(k+1, L)). DRAM page hit (D=2) => 9; at this model's page-miss-average D=5 => 12. The §4 bound of 6-9 resolves to its top end and slightly beyond at miss.
• §9 resolved — fetch starvation is ~zero for load-dense code (+0.016 cyc/instr vs pure ALU). The exact rule: a run of g consecutive local-RAM loads costs g - 1 extra clocks — first load free (2-deep prefetch queue), each additional back-to-back load +1.
• NEW RULE (was not in §3): write-back port conflict dominates real IPC. Every register-writing instruction in a disjoint-register stream retires at 2.00 ticks/instr (NOP streams: exactly 1.00; a following NOP does not conceal it). This is the JTRM "Register Write-Back" dual-port-RAM rule firing on essentially every back-to-back ALU pair: concealment requires the next instruction to read the write-back target or read fewer than two registers. Real compiled GPU code therefore sits near 0.5 IPC, and §2's 1/tick is only reachable by non-register-writing streams.

---

15. Bus grant latency under load (S2, 2026-10-13) — read-derived, NOT simulated

Section 12 item 6 asked for a Verilator-pinned grant-latency distribution. It could not be simulated: the vsim/ island rig behind §14 is in no checkout and not on the LAN build host, Verilator is not installed there, and that rig tied gpu_back granted with no ARB/MEM logic, so even recovered it cannot measure grant latency; the full-chip emu route needs a jag_sim checkout + a 68000 model on the build host. The function below is therefore assembled from the JTRM (rev 8 text, page numbers verified in the PDF text), the ARB.NET state machine (excerpts, see †; not simulated) and measured traffic; docs/timing-campaign-plan.md S2 has the result and test/tools/contention_model.py the arithmetic. Evidence tags as in the preamble.

Priorities below use the JTRM's numbering (1 = highest), the reverse of R18's table in §7.

Term	Rule	Constant(s)	Evidence
Who beats whom	refresh 2 > OP 6 > DSP-normal 7 > CPU-under-interrupt 8 > GPU-normal 9 > blitter-normal 10 > CPU 11	—	[JTRM p.8] + ARB.NET req[] chain (same order)†
Re-arbitration point	ownership changes only at a memory-cycle ack	—	[JTRM p.29] "ownership can be lost during a request (but not during a memory cycle)"; ARB.NET arben = q2 & ack†
OP holds its burst	RELEASE clear => bus held between data fetches; Doom: RELEASE clear on 100% of objects (measured)	wait = B²/2T, B = OP+refresh per line (low: per-object bursts)	[JTRM p.19, p.7]; burst contiguity inferred
Refresh	grouped after the OP's STOP; CLK/(64·(REFRATE+1)), REFRATE=5 measured	3 clk/refresh (JTRM table) .. 9 (MEM.NET CBR walk, §8)	[JTRM p.11, p.24] vs §8 — unresolved, bounded
Blitter vs GPU/DSP	normal-priority blit preempted at the next ack; BUSHI never set by Doom (0/378 blits per field)	wait = U_blit · c/2, c = 2..5	[JTRM p.8, p.69, p.75]
DSP vs GPU	DSP-normal beats GPU-normal; 16-bit external interface => 2 transactions per long	wait = U_dsp · L/2, L = 1..2 transactions × price × hold 1..2	[JTRM p.8, p.97]; JERRY-side hold inferred
68K default owner	Idle->Request needs a local request; Request->Hold waits for the 68000's BG; Hold->Idle as soon as no local request remains (no hold-off counter) => every access arriving while the bus is parked on the 68K pays BR->BG	P_idle × H, H = 2 / 6 / 12 sysclks	ARB.NET state table†; H from R19's 68000-datasheet bound — not verified locally, not simulated. Verdict-insensitive: the term is 0.02-0.18 field/flip for Doom
68K stretch	lowest priority; stalls for every foreign tenure while it needs the bus	duty (measured 81%) × others' occupancy + 0..4 sysclk resync per tenure	[JTRM p.8]; resync inferred
GPU spin occupancy	hardware-rate main-RAM polls (4 loads/iteration at L = 7+D)	utilisation 0.25 / 0.40 / 0.60 while spinning	§14 + loop shape, inferred (the emulated poll rate is unphysical and not used)

† ARB.NET was consulted through a summarizing web fetch of the public jag_sim repository (no local checkout; it would not relay verbatim text): the quoted expressions are excerpts it relayed — not verbatim, not simulated.

Doom attract demo, per external access (stock config): GPU work access waits 4.7 / 7.4 / 11.2 sysclks (OP+refresh dominate; handoff is small because GPU render traffic coincides with blitter tenure, which keeps the bus off the 68K); DSP 16-bit transaction 2.2 / 3.4 / 9.5. Checkered Flag (2.5x Doom's OP traffic, lines 33-61 carry ~490 sysclks of OP fetch) puts the total GPU wait at 9 / 36 / 42 sysclks per access.