The processor development archive.

Five stages, one data path.

Fetch, decode, execute, memory and writeback form one in-order pipeline. In EXTERNAL_PORTS=1 mode, instruction and data memories are supplied by separate ports outside the core. Each channel allows one outstanding request and uses rising-edge valid && ready transfers; the two channels can overlap. The older self-contained mode remains for historical regressions.

Opt-in, architecturally ordered fault-stop

With FAULT_HALT=1, the EX stage recognizes illegal/unsupported encodings, misaligned taken branch/JAL/JALR targets, and misaligned or out-of-range loads/stores. Any older memory operation finishes before the younger fault is reported; older writeback can retire. The faulting instruction never enters memory, and wrong-path or younger instructions cannot modify architectural state. A pending external fetch may still be accepted and drained without execution.

Four outputs retain the first diagnosis until reset: fault_valid (sticky), fault_cause (0 control-target alignment; 1 modeled instruction-fetch range; 2 illegal instruction; 4/6 load/store misalignment; 5/7 modeled load/store range), fault_pc (faulting instruction or fetch PC), and fault_tval (illegal instruction bits, invalid fetch PC, bad target or effective address). The default FAULT_HALT=0 preserves prior behavior.

A bad fetch is not always an architectural fault

When the next fetch PC falls outside 0x00000000–0x00000fff, FAULT_HALT=1 creates one synthetic IF-to-EX fault token instead of reading an aliased internal word or issuing an invalid external I request. If an older taken BEQ, JAL or JALR at 0x00000ffc redirects in range, it flushes the wrong-path token. If the fetch is real, EX reports sticky cause=1 with fault_pc=fault_tval equal to the invalid fetch PC.

An aligned JAL/JALR to 0x00001000 is itself valid: the link register retires, then the *younger fetch* at that address faults. Earlier loads or stores drain first, even with independent I/D delays and held responses. Reset clears the sticky diagnosis. This checks only the fixed local teaching memory; external hardware bus errors and architectural instruction-access trap handling remain unsupported.

Two ports, independently stalled

The test adapter varies instruction and data latency independently and can hold either req_ready low. A response remains valid, with the same tag and payload, until the core raises rsp_ready. Fetch checks both the echoed PC and tag; data checks its tag. The adapter commits stores at the response handshake once. This is a bounded, single-outstanding educational protocol on one core clock, not AXI or a physical SRAM timing model.

EXTERNAL I/D TRANSACTIONS / CAPTURED HANDSHAKEREAL RTL SIMULATION · NO HARDWARE TIMING CLAIM

Earlier latency-controlled internal memory

Before external I/D ports, the core used an internal behavioral memory adapter. That prior milestone tested base delays of 1, 2 or 4 cycles plus deterministic extra delays of up to three cycles; its trace remains below as historical evidence.

EARLIER INTERNAL DATA-MEMORY HANDSHAKESIMULATOR SIGNALS, NOT HARDWARE TIMING

Implementation with receipts.

The newest instruction-fetch boundary implementation and independent tests come first. Earlier fault-stop, external I/D bus, internal latency-memory and integration sources remain linked below at their original verified revisions.

Instruction-fetch range and ordered fault token / new milestone

wire [31:0] forward_a = ex_match1 ? ex_mem_alu_res :
                        wb_match1 ? rf_wd : id_ex_rd1;
wire [31:0] forward_b = ex_match2 ? ex_mem_alu_res :
                        wb_match2 ? rf_wd : id_ex_rd2;

Fetch faults. In instruction order.

The independent fetch-boundary bench executes 12 distinct scenarios under six internal/external I/D timing configurations. Each run compares 32 registers and 1,024 modeled RAM words, yielding 72 scenario runs and 76,032 final-state comparisons—not 76,032 different instructions or tests. The checks verify that valid instructions finish, speculative fetch faults are squashed, and no invalid external instruction request is offered. The I/D adapter also exercises response backpressure.

Earlier illegal instruction and data fault-stop checks

The preceding opt-in fail-stop milestone established EX-stage illegal-instruction, misaligned control target, and invalid data-access diagnostics. Its 90 scenarios and 95,040 architectural comparisons remain separate from the new instruction-fetch boundary regression.

The fault-halt suite runs 12 invalid-instruction or access scenarios and three non-fault cases under each of six configurations: three internal-memory and three independently timed external I/D combinations. Every run checks 32 registers and 1,024 data-memory words, including whether younger instructions were suppressed, valid older work survived and the diagnosis remains stable until reset.

Earlier external I/D bus verification

The preceding port-level regression separately passed 42 directed runs and 12 interpreter-reference runs, totaling 57,024 state comparisons, plus two expected corrupted-tag rejections. Its independently timed instruction/data traces and source remain linked below. None of those checks are counted as part of the new 95,040 fault-stop comparisons.

The external regression uses a separate adapter with independently varied instruction and data timing. Six configurations run seven self-checking programs each: mixed load/store hazards, branch redirects and wrong-path suppression, backward branches with delayed fetch, signed subword loads and masked stores, reset cancellation of an outstanding store, a 300-redirect loop that wraps fetch tags, and a 301-instruction straight-line test. Every completed case checks all 32 registers and 1,024 modeled memory words against explicit expected state.

bash scripts/run_external_regression.sh /tmp/rv32i-external

Earlier internal memory-latency verification

The previous internal-memory adapter was checked across six delay configurations and against a separate Python sequential interpreter. Those 50,688 architectural comparisons and four expected-fault tests are earlier, distinct evidence; they are not included in the external-port totals above.

bash scripts/run_memory_regression.sh /tmp/rv32i-memory-regression

Earlier one-cycle integrated milestone

Before the delayed-memory design, the first integrated regression passed four programs with 4,224 state checks, plus a separate jump/control-flow test. Its captured trace is retained as historical evidence of how the processor developed.

EARLIER INTEGRATED SIMULATION / LOAD-TO-BRANCH PROGRAMVCD SAMPLES · NOT PHYSICAL TIMING

bash scripts/run_regression.sh /tmp/rv32i-evidence

The earlier module-level foundation

Standalone self-checking tests for the ALU, register file and control unit still pass. The original captured ALU waveform remains below as a separate, narrower piece of evidence.

REAL SIMULATION DATA / ALURUN ID: 2026-10-14

Verification boundary. FAULT_HALT=1 checks only the modeled local 4 KiB instruction/data ranges and reports sticky fail-stop diagnostics, including modeled fetch cause 1. It does not save machine-mode CSR state, jump to mtvec, execute a trap handler or MRET, or resume without reset. There is no physical/external bus-error response, memory protection, MMIO, AXI/AHB, interrupts, privilege, cache coherence, full ISA compliance, formal proof, synthesis or FPGA evidence. FAULT_HALT=0 retains prior legacy simulation behavior, including $fatal for invalid accepted data requests. External-memory and core reset must still cancel outstanding transactions together.

Development provenance. AI-assisted development and review were used in this iteration. The listed results describe actual, reproducible simulator runs, not a claim that every RTL and test line was independently handwritten. The linked source and verification procedures are provided for direct inspection.

The interesting problems aren't finished.

1. From modeled fail-stop to architectural traps.

   Add true externally reported instruction access faults, machine-mode CSRs, mtvec, exception entry and MRET recovery, followed by broader ISA compliance work. The current fetch fault is only a local modeled bounds check.

2. Build an actual memory system.

   Define MMIO, address mapping and bus-error responses, then integrate a real AXI or cache bridge as appropriate. The current external ready/valid ports remain a bounded educational protocol.

3. Build hardware evidence.

   Measure synthesis and static timing, integrate a synthesizable memory system, and test on an FPGA before making frequency, area or physical performance claims.