eZX Spectrum — CPU

Applies to the eZX primary FPGA image. For the Next-compatible image's CPU, see Z80NG. For the eZX hardware specification, see spec. For the eZX chipset, see ezx.

The eZX CPU is the FireStorm EE

"eZX" names the FPGA, not the CPU. The eZX Spectrum's FPGA runs the exact same RISC-V core the Ant64's FireStorm runs — the FireStorm Execution Engine (EE), RV64GC plus the full extension stack (Xcrisp, Xstack, Xcond, Xlate, Xctx, Xmath, Xez, and wide mode). There is no separate eZX ISA, no eZX-specific register file, no eZX-specific CSR map, and no eZX-specific pipeline. A binary compiled for the EE runs unmodified on either machine's CPU; the two platforms differ in their chipset, their memory configuration, and their supervisor integration — not in their CPU.

This is a change from earlier eZX documentation, which specified a standalone 32-bit eZX-RV32 core with its own parallel extension set (ezx_xcrisp, ezx_xmath, ezx_xstack, ezx_xlate, ezx_xctx, ezx_xez, ezx_xwide, ezx_xcond). Maintaining two ISAs — an RV32 profile for the eZX and an RV64 profile for the Ant64 — made no sense once both machines share the same FPGA component; the eZX now adopts the EE wholesale. Those ezx_x* documents are retired. For the CPU architecture in full — register file (including wide mode's x32-x63 / f32-f63 extended banks), pipeline and prefetch buffers, memory architecture and mode selection, CSR map, trap and interrupt model, reset state, ABI, and toolchain integration — see the canonical Ant64 documentation, kept up to date at a single location:

  • EE - overview
  • EE - full ISA specification
  • Xcrisp - compiler-friendly memory and ALU fusion
  • Xmath - integer + single-precision FP compute
  • Xstack - hardware-accelerated BSRAM-backed user stack
  • Xlate - per-register load/store translators
  • Xctx - hardware context pool for fibers and async I/O
  • Xez - Z80 flag model and ergonomics, shared by both platforms since both run the one RV64 EE
  • Xcond - operand-based predicated execution
  • Xaccel - CM coprocessor offload (posted writes and scoreboarded reply offloads) - see also Accelerator for the redirection layer this complements

What follows in this document is eZX-board-specific integration - how the shared EE is wired up on the eZX Spectrum board specifically: which memory tiers the board populates, what runs where in the software stack, and the eZX-specific reset/boot story. Everything else about the CPU itself is in the EE docs above.

Memory tiers on the eZX board

The EE's memory architecture (EE § Memory Architecture and Mode Selection) defines three possible tiers - a narrow tier (HyperRAM) and two wide tiers (DDR3, 36-bit SRAM) whose extra per-byte bit carries the wide-mode extension nibble on code fetch and a debugger watch bit on data access. Which tiers a given board actually populates is a platform choice. On the eZX Spectrum:

  • HyperRAM - always populated. 16 MB, the narrow tier, always present regardless of configuration. This is the eZX's realistic main code-and-data tier - application code, libraries, file-system buffers, and most working data live here. See spec § HyperRAM for the part and access-strategy detail.
  • DDR3 SODIMM - optional, user-installable. The DDR3 expansion. When fitted, this is the eZX's wide tier - application-class code that wants the extended register file, wider immediates, or Xcond predication lives here, per the EE's standard wide-mode rules. 1/2/4 GB user-addressable, 8 GB address space reserved. See spec § DDR3 SODIMM details.
  • 36-bit SRAM - not populated by default. The eZX deliberately doesn't build Ant64's on-board wide-SRAM bank into the base machine, to keep the two platforms architecturally distinct despite sharing the same FPGA component. The pins are exposed on the SRAM expansion connector for an optional daughter-board instead. See spec § Why no parallel SRAM for the rationale.
  • BSRAM - not used for CPU code. The eZX primary image's ~765 KB BSRAM budget is fully claimed by chipset and CPU inner state (prefetch buffers, sprite tables, line buffers, palette storage, audio mixer voices, Xctx context-save storage, debug trace ring). There isn't enough left to host application code; see spec § On-chip BSRAM.

In practice: narrow-mode code runs from HyperRAM; wide-mode code (when a workload wants it) runs from DDR3 when the SODIMM is fitted, or from the SRAM expansion daughter-board's 36-bit SRAM tier when that's fitted instead. A base eZX with neither expansion runs entirely in narrow mode - full RV64GC plus the base extension set, no wide-mode features. This differs from the Ant64, which populates the 36-bit SRAM tier on the main board by default.

What runs where

AntOS does not run on the EE. AntOS is the supervisor operating system on DeMon's CM4/CM5 Compute Module - it runs the Luau interpreter, executes user scripts, drives USB/SD/WiFi/NFC, hosts the file system, services telnet/FTP, and brokers the FPGA image change-over via JTAG. The EE running inside the eZX FPGA is a separate processor with its own role.

What runs on the EE, on the eZX board:

  • User code - the primary workload: applications, libraries, language runtimes, games, demos, compiled for RV64GC plus whichever EE extensions the toolchain targets.
  • A small debugger / mini-OS, living in the FPGA's own flash chip, mapped into the EE's address space (the same flash that shares the MSPI boot bus with HyperRAM - see spec § HyperRAM). This provides boot-time setup, trap and debug handling (breakpoints, watchpoints via the wide-tier watch bits, single-step, register/memory inspection), and a syscall/mailbox interface to AntOS - user code traps into the mini-OS for file I/O, network access, or any other AntOS-provided service, and the mini-OS forwards the request to AntOS over the supervisor channel.

The mini-OS is small, executes directly from flash without copying to RAM, and provides only what user code needs to exist as a portable program on the eZX - no process model, no shell, no file system of its own; those live in AntOS on DeMon and are reached via mailbox. See spec § What runs on the eZX CPU for the full software-stack picture.

Reset and boot on the eZX board

Reset behaviour, the trap and interrupt model, and the CSR map are all defined generically by the EE spec (EE §§ Register File, CSRs) and apply unchanged on the eZX. The one board-specific detail is the reset vector: on the eZX, pc resets to the boot ROM region in the FPGA's own flash (the mini-OS entry point described above), matching the eZX's memory map rather than any Ant64-specific address. See spec § FPGA images for the eZX's FPGA boot story (the eZX primary image self-loads from the FPGA's own flash at cold boot; DeMon reloads the FPGA for the Classic Spectrum and Next-compatible images over JTAG on demand) - the EE's reset sequence begins once the eZX primary image is the one actually loaded onto the fabric.

Important: The eZX Spectrum board is at early design/prototype stage, everything you see here is subject to change.