Megapad-64 is a computer system built from scratch — CPU, BIOS, operating system, filesystem, SIMD tile engine, and interactive dashboard — all running inside a Python emulator (with an optional C++ accelerator) or, for source-level work, a hosted semantic simulator, and covered by a broad automated suite.
The core idea: put a large, fast scratchpad memory directly on the processor die and give the CPU a dedicated engine that runs SIMD operations across that memory one 64-byte tile at a time. Instead of shuttling data through a cache hierarchy, software works on tiles directly. A single MEX instruction can add, multiply, dot-product, or reduce an entire tile's worth of data in one shot.
Everything from the instruction encoding to the filesystem runs in the emulator. You can boot the system, type Forth at the REPL, create buffers, chain compute kernels into pipelines, ingest network data, browse on-disk documentation, and explore a 7-screen TUI dashboard — all interactively.
Assume everything is rough draft, both in this project and in the megapad project.
Feel free top drop by and discuss this project in the Tinkerers Guild channel of the Barayin-Adamah server: https://discord.gg/AnrXxhs3b2
| Component | Stats |
|---|---|
| BIOS | Subroutine-threaded Forth, device words, checked crypto, and boot loader |
| KDOS | Bank 0 core in kdos.f; loadable networking in userland networking.f |
| Emulator | 16-core SoC (4 full + 3×4 micro-clusters) with HBW math RAM |
| C++ Accelerator | Optional pybind11 CPU fast path |
| Hosted simulator | Semantic source backend with an optional native executor; runs the complete Akashic Desktop (simulator/README.md, docs/simulator-contract.md) |
| Rich terminal | Optional boot-loaded rich-terminal.f APT-1 module with a retained host compositor and viewer (docs/rich-terminal/) |
| Tests | Host, guest, RTL, multicore, and live-network coverage; resource and environment gates are reported separately |
| Filesystem | MP64FS — capacity-derived marker-1 geometry through 32 MiB, 128 entries, two extents |
| Tooling | CLI/debugger, two-pass assembler (with listing output), disk utility |
| Devices | 20 emulator MMIO peripherals, including UART, Timer, Storage, NIC, one-shot PCM Audio, crypto accelerators, Mailbox, Spinlock, SysInfo, and Port I/O Bridge |
| FPGA RTL | 36 Verilog modules + 32 testbenches + 12 target overrides (~430 HW tests), Genesys 2 + VU095 targets |
Core subsystems are broadly implemented: BIOS Forth, the KDOS core, tile engine, filesystem, scheduler, pipelines, the loadable network stack (L2–L7 through TLS 1.3 + socket API), disk I/O, auto-boot from disk, interactive TUI, built-in documentation browser, 16-core heterogeneous SoC (4 full cores + 3 micro-clusters of 4 cores each) with IPI, spinlocks, barriers, and 3 MiB HBW math RAM, core-type-aware scheduling, and post-quantum crypto (Field ALU, NTT, ML-KEM-512, and a source-defined X25519+ML-KEM/HKDF hybrid composition).
Transport is still under active qualification. The current TCP sender is a
one-outstanding-segment profile: retained data now has strict cumulative-ACK
accounting, bounded replay/failure, peer/congestion-window admission, durable
ACK intent, nonblocking neighbor recovery, bounded SYN/SYN-ACK/FIN replay,
half-open admission, and close-notify-before-FIN teardown. The TLS server can
construct and emit its complete flight in a socket-independent composition,
authenticate client Finished, and attach one exact queued TCP child to a
prepared server context. A sealed attached-flight step now carries retained
server records over that exact child with truthful backpressure and terminal
cleanup; its plaintext ServerHello/exact-send boundary is qualified. The
initial ClientHello now enters through the same exact child across arbitrary
TCP and TLSPlaintext-record fragmentation, with explicit record progress and
exact following-record retention. The existing attached emitter is now
qualified through its complete ACK-paced protected flight. The protected
client flight now enters through the same sealed child, preserves exact
record/TCP boundaries, authenticates client Finished, and reaches
1798
the existing
explicit publication boundary. Sticky terminal ingress now drives one exact
protected fatal or close-notify record over that child, or deliberately sends
nothing for a non-close peer alert; retries preserve ciphertext and nonce, and
close waits for alert acknowledgement before FIN. An authenticated attached
server context can now publish one reciprocal TLS descriptor through the exact
context generation only after descriptor capacity, credential ownership, and
the sealed child are proven in one transaction. Predictable contention and
capacity failures leave the raw context unchanged; stale child authority stays
abortable without touching a replacement. TLS-LISTEN now copies the listener
policy, pins the exact credential, atomically publishes the passive TCB, and
returns its opaque handle and generation. The fused nonblocking
TLS-SERVER-ACCEPT-CLAIM boundary uses that exact authority to transfer one
queued child directly into a pinned TLS server context, with no plaintext
accepted socket publication. TLS-LISTEN also owns listener close/unpin
cleanup. The generic LISTEN entry remains
fail-closed for TLS descriptors, and SOCK-ACCEPT remains deliberately
fail-closed for secure listeners.
Service lifecycle sits above that boundary. Akashic's persistent inbound
listener owner uses its external-I/O operation machinery for serialization,
deadlines, cancellation, retained success, callback containment, and exact
cleanup. Each cooperative step invokes one generation-qualified KDOS claim,
ingress, preparation, flight, disposition, publication, close, or abort
primitive. After authentication, Akashic adopts the published descriptor into
the same established KDOS-TLS NIO port used by outbound connections; HTTP's
connection owner receives only that already-open port. Independent TLS 1.3
clients qualify two connections on one listener, http/1.1 ALPN, application
bytes through the cooperative HTTP stack, authenticated close_notify/FIN,
and cancellation, deadline, malformed-handshake, cleanup-contention, and
recovery paths without exposing a plaintext accepted child.
A temporary KDOS coordinator previously qualified the lower phase ordering and
socket journey. It was retired after the Akashic path supplied equivalent
success and recovery evidence; its recorded results remain historical evidence,
not a current API or lifecycle layer. The compact lower TLS engine and fused
exact claim remain the KDOS boundary. Remaining protocol-profile items are
broader maturity work. See
docs/tls-hardening.md for current claims and
nonclaims.
┌───────────────────────────────────────────────────────────────┐
│ Megapad-64 SoC │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Core 0 │ │ Core 1 │ │ Core 2 │ │ Core 3 │ Full cores │
│ │ 16×GPR │ │ 16×GPR │ │ 16×GPR │ │ 16×GPR │ (tile+MEX) │
│ │ 4K I$ │ │ 4K I$ │ │ 4K I$ │ │ 4K I$ │ │
│ │ Tile │ │ Tile │ │ Tile │ │ Tile │ │
│ │ Engine │ │ Engine │ │ Engine │ │ Engine │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │ │
│ ┌────┴───┐ ┌────┴───┐ ┌────┴───┐ │
│ │Cluster0│ │Cluster1│ │Cluster2│ 3 × 4 micro-cores │
│ │ 4× μC │ │ 4× μC │ │ 4× μC │ (scalar only, shared │
│ │ 1K SPAD│ │ 1K SPAD│ │ 1K SPAD│ MUL/DIV, HW barrier) │
│ └────┬───┘ └────┬───┘ └────┬───┘ │
│ │ │ │ │
│ ┌────▼───────────▼───────────▼───────────────┐ │
│ │ Round-Robin Bus Arbiter (per-core QoS) │ │
│ └────────────────────┬───────────────────────┘ │
│ ┌───────────────┼───────────────┐ │
│ │ │ │ │
│ ┌────▼────┐ ┌───────▼───────┐ ┌────▼──────┐ │
│ │Bank 0 │ │ MMIO Devices │ │ Mailbox │ │
│ │ 1 MiB │ │ UART Timer │ │ IPI + │ │
│ │ System │ │ Disk NIC │ │ Spinlock │ │
│ ├─────────┤ │ CRC AES │ │ │ │
│ │Banks 1-3│ │ SHA3 TRNG │ │ │ │
│ │ 3 MiB │ │ FieldALU │ │ │ │
│ │ HBW Math│ │ NTT KEM │ │ │ │
│ └─────────┘ └───────────────┘ └───────────┘ │
└───────────────────────────────────────────────────────────────┘
Heterogeneous 16-Core SoC — Four full cores (with tile engine, I-cache, and full ISA) plus three micro-core clusters of 4 cores each (scalar-only, shared MUL/DIV, 1 KiB scratchpad, hardware barrier per cluster). All 16 cores share a unified address space via a round-robin bus arbiter with per-core QoS weights. Cores communicate through a hardware mailbox (IPI) and 16 spinlocks. Micro-clusters are gated by the SysInfo CLUSTER_EN register. KDOS automatically routes tile/SIMD work to full cores only.
Scalar CPU — Each full core has 32 general-purpose 64-bit registers, variable-length instructions (1–11 bytes), 16 instruction families, and heritage from the RCA CDP1802 with modern 64-bit extensions. Any GPR can serve as PC, data pointer, or stack pointer through runtime selectors. The checked-in portable RTL is an in-order, IF/DEX-buffered multi-state core with a per-core 4 KiB direct-mapped instruction cache. The IF/DEX names describe a functional split, not a sustained one-instruction-per-clock pipeline: common warm scalar instructions currently have a roughly four-clock floor and execute or memory operations take longer.
Tile Engine — Per-core SIMD execution unit controlled through CSR registers and triggered by MEX instructions. Each operation processes a 64-byte tile (8 to 64 lanes depending on element width) with element-wise ALU, multiply, dot product, or reduction functions. Extended operations include FMA, widening multiply, saturating arithmetic, rounding shifts, tile views (SHUFFLE/PACK/UNPACK/RROT), strided 2D loads/stores, and FP16/bfloat16 support. A 256-bit accumulator enables multi-tile accumulation without overflow.
4 MiB Internal Memory — Bank 0 (1 MiB system RAM at address 0) holds
the BIOS, dictionary, stacks, and heap. Banks 1–3 (3 MiB HBW math RAM
at 0xFFD0_0000) provide dedicated high-bandwidth storage for tile/SIMD
working buffers, avoiding contention with Bank 0. KDOS includes an HBW
bump allocator (HBW-ALLOT, HBW-BUFFER, HBW-RESET) and the BIOS
exposes HBW-BASE / HBW-SIZE words.
Devices — UART (serial I/O), Timer (cycle-accurate with interrupts),
Storage Controller (sector-based disk I/O), NIC (Ethernet frames with
DMA), CRC ISA engine (three exact non-reflected 32/64-bit tuples), AES-256-GCM (encrypt/decrypt with
authentication), SHA-3/SHAKE (Keccak-f[1600], 4 modes + XOF squeeze),
TRNG (hardware CSPRNG, ring-oscillator on FPGA), Field ALU (GF(2²⁵⁵−19)
arithmetic + raw 256×256→512-bit multiply), NTT Engine (256-point NTT/
INTT, configurable modulus), KEM Engine (working synchronous Python
ML-KEM-512 values for generated/well-formed keys; current RTL is an
incompatible non-cryptographic stub), one-shot PCM Audio (deterministic
headless capture with optional host playback), SystemInfo (CPUID, memory
size), Mailbox (inter-core IPI), and Spinlocks (8 hardware mutexes). Peripheral
devices are memory-mapped at 0xFFFF_FF00+; CRC, SHA-2, and Field ALU
acceleration are EXT.CRYPTO ISA facilities instead. The audio register contract
is implemented in the emulator; its physical DMA/I2S bridge remains pending.
┌─────────────────────────────────┐
│ User Programs │ ← Forth words at the REPL
├─────────────────────────────────┤
│ networking.f (userland / XMEM) │ ← Ethernet through TLS 1.3,
│ Network · Sockets · Data Ports │ sockets, UDP data-port transport
├─────────────────────────────────┤
│ KDOS Core (Bank 0) │ ← Buffers, kernels, pipelines,
│ Buffers · Kernels · Pipelines │ scheduler, filesystem, TUI,
│ Scheduler · Filesystem · TUI │ module loading, multicore, PQC
├─────────────────────────────────┤
│ BIOS (bios.asm) │ ← Subroutine-threaded Forth,
│ 481 words · EVALUATE · FSLOAD │ compiler, I/O, tile, multicore
├─────────────────────────────────┤
│ Hardware / Emulator │ ← emulator/megapad64.py + emulator/devices.py
└─────────────────────────────────┘
BIOS — A subroutine-threaded Forth interpreter/compiler in assembly.
481 dictionary words covering arithmetic, logic, stack manipulation,
memory access, control flow (IF/ELSE, BEGIN/UNTIL/WHILE, DO/LOOP),
strings, compilation, I/O, disk, timer, tile engine, NIC, multicore
(COREID, NCORES, IPI-SEND, SPIN@/SPIN!, WAKE-CORE, CORE-STATUS),
performance counters, CRC engine, AES-256-GCM, SHA-3/SHAKE,
TRNG, Field ALU (FADD–FPOW + MUL_RAW), NTT engine,
KEM words (Python ML-KEM-512 value path; RTL stub), memory BIST,
tile self-test,
strided/2D addressing, and FP16/BF16 modes.
Includes FSLOAD for booting KDOS directly from a disk image. Hardened
with stack underflow detection, EVALUATE depth limiting, dictionary-full
guards, and FSLOAD error recovery with file/line context.
KDOS core — The Bank 0-resident part of the Kernel Dashboard OS,
written entirely in Forth. It covers utility words, described buffers with
constructor-specific alignment guarantees, tile-accelerated buffer operations
(B.SUM, B.ADD, etc.), a kernel
registry with 18 built-in compute kernels, a pipeline engine, raw and
named file I/O, the MP64FS filesystem, a documentation browser, dictionary
search tools, a cooperative scheduler with timer-assisted preemption, a
9-screen interactive TUI (with auto-refresh), data-port structures and binding,
benchmarking, a full dashboard, a categorized help system with per-word
DESCRIBE, pipeline bundles, multicore dispatch (CORE-RUN,
CORE-WAIT, BARRIER, P.RUN-PAR), and auto-boot.
Its core-0 module registry stores complete, case-sensitive evaluator IDs in
dynamic Bank 0 chains. The current 1–246-byte ID envelope comes from the
evaluator's line bound, not a fixed registry capacity or MP64FS filename limit.
Duplicate registration is allocation-neutral; bucket growth is best effort,
and entries remain valid across userland transitions and XMEM-RESET.
Networking module — networking.f supplies Ethernet, ARP, IPv4,
ICMP, UDP, DHCP, DNS, TCP, TLS 1.3, sockets, and the UDP-backed data-port
transport. The standard autoexec.f enters userland and loads this module
with KDOS REQUIRE before it loads tools.f, keeping the KDOS core dictionary
in Bank 0. The module loader batches large and fragmented MP64FS extents into
a separate external-memory temporary allocation, so it does not re-enter the
BIOS boot loader's live buffer. REQUIRE pre-registers the source's exact
PROVIDED ID before evaluation to terminate dependency cycles. Entry OOM
executes no source; a source throw unwinds its evaluator frame, transfer
allocation, relative-directory state, and every frame-owned provisional ID
while preserving a nested dependency that already completed. The corrected
source can then be retried.
The feature inventory is not a completion claim: current TCP/TLS qualification
boundaries are recorded in docs/tls-hardening.md.
Use CPython 3.12 for the current build and test workflow. The hosted Python executor can run without compiling either native extension.
Architectural emulation requires the C++ extension; hosted simulation also
has a native executor. Build both with make build using CPython 3.12,
pybind11, and a C++17 compiler. The focused make accel and
make simulator-accel targets remain available.
git clone <repository-url>
cd megapad-64megapad.py starts one shared session using the selected execution mode.
The emulator is the default. The existing session viewer and control client
attach to all three modes through the same socket protocol.
make build
python megapad.py --help
python megapad.py --mode emulator --bios bios.asm --storage sample.img
python megapad.py --mode simulator --storage desktop.img --executor native
# A settings disk, attached write-protected to the second storage controller:
python megapad.py --mode simulator --storage desktop.img --settings-storage settings.img
python megapad.py --mode hybrid --storage hybrid.img --executor native --hybrid-routines routines.json
# Each mode documents its own supported options.
python megapad.py --mode simulator --help
# Equivalent Make entry point:
make serve ARGS='--mode simulator --storage desktop.img --executor native'Use a prepared MP64FS source image with the ordinary KDOS autoexec entry for
simulator sessions; the existing Akashic image preparation remains applicable.
Each running session needs its own writable image and socket/runtime namespace.
--executor python|native|auto applies to simulator and hybrid preparation and live
execution. An explicit option takes priority over MEGAFORTH_EXECUTOR; when
both are absent, production sessions require the native semantic extension.
A missing or stale required extension fails before boot source runs. Select
python for the reference executor, or auto to permit fallback when the
native extension is unavailable or incompatible. Embedded MegaForthRuntime
and HybridRuntime.create retain their Python default when no executor or
environment setting is supplied. Emulator
lane and clock controls remain emulator options. Python-only simulation and
launcher help do not require the emulator extension. The simulator and viewer
also import no architectural backend.
All modes report a common runtime object in session status: selected mode
and executor, work/step units, timer and RTC policy, and supported diagnostic
and reset actions. A native executor may still use Python service fallbacks.
See the session API for the boundary and status
fields. The default application mode remains emulator.
Hybrid mode runs Forth semantically and declared MP64 integer routines on a native core that shares one memory image. As on the chip, a routine's CALL.L and RET.L use the Forth return stack, and a routine can call Forth words at declared sites, which run on the caller's own stacks. Machine instructions and cycles are reported separately from semantic work. Machine MMIO, native BIOS images and multicore hybrid execution are not part of this mode. See the hybrid design and manifest format.
The architectural monitor in cli.py remains a separate debugging tool.
Server implementations and programmatic interfaces live in emulator.server,
simulator.server, and hybrid.server; start a session with
megapad.py --mode MODE, which selects one.
# Build the sample disk image (KDOS core, networking, modules, docs, tutorials)
python diskutil.py sample
# Boot from disk (recommended) — BIOS auto-loads KDOS from disk
python cli.py --bios bios.asm --storage sample.img
# Without disk (development mode — KDOS core only, no FS or networking module)
python cli.py --bios bios.asm --forth kdos.fRun the emulator as a background service with remote access via TCP:
# Start headless server (default port 6464)
python cli.py --bios bios.asm --storage sample.img --headless
# Start on a custom port
python cli.py --bios bios.asm --storage sample.img --headless --headless-port 7777
# Connect with the built-in client
python cli.py --connect localhost:6464
# Or discover the active server from its status file
python cli.py --connect
# Or connect with nc / telnet
nc localhost 6464The headless server writes status to /tmp/megapad_headless.json (PID + port)
for discoverability. Multiple clients can connect simultaneously.
For a parallel checkout, export a short runtime namespace before starting the
server. Its discovery file is placed in the UID-owned, mode-0700 directory
/tmp/megapad-runtime-<uid>-<namespace>/, and the default TCP port is assigned
by the OS so it cannot collide with the legacy port:
export MP64_RUNTIME_NAMESPACE=megapad-concurrency
python cli.py --bios bios.asm --storage sample.img --headlessThe selected port is printed at startup and recorded in headless.json.
python cli.py --connect reads that file when the same namespace is exported.
An explicit connection endpoint or --headless-port still overrides
discovery.
You'll see the KDOS banner and land at the Forth REPL:
------------------------------------------------------------
KDOS v1.1 — Kernel Dashboard OS
------------------------------------------------------------
Type HELP for command reference.
Type SCREENS for interactive TUI.
Type TOPICS or LESSONS for documentation.
HELP \ Full command reference
DASHBOARD \ System overview
0 1 256 BUFFER demo \ Create a 256-byte buffer
42 demo B.FILL \ Fill every byte with 42
demo B.SUM . \ Sum → 10752
demo kstats \ Prints sum, min, max
0 1 256 BUFFER a \ Two more buffers
0 1 256 BUFFER b
10 a B.FILL 20 b B.FILL
a b demo kadd \ Tile-accelerated add: demo = a + b
HEX demo B.PREVIEW DECIMAL \ Show first 64 bytes in hex
SCREENS \ Launch 9-screen TUI dashboard# Optional C++ accelerator
python -m venv .venv && .venv/bin/pip install pybind11 pytest
make accel
# Focused foreground qualification
make test-sequential TEST_PATH=tests/test_system.py K=TestKDOSTLSServerClientHello
make test-one K=test_name # isolated monitored selection
make test-quick # small BIOS/CPU smoke
# Broad sequential suite (background + status dashboard)
make testNote: Always run tests via the Makefile (
make test,make test-one, etc.). UnderAGENTS.md, worker-spawning, unusually large, and broad resource-heavy runs require approval and test suites must remain sequential with respect to one another.
The suite covers the CPU, BIOS, KDOS, filesystem, assembler, disk utility, devices, multicore, simulated networking, crypto, post-quantum crypto, and the extended tile engine.
For real-network tests against a Linux TAP device:
make test-net # requires mp64tap0 TAP device (see cli.py --nic-tap)| File | Purpose |
|---|---|
emulator/megapad64.py |
CPU and tile-engine emulator, including extended operations and FP16/BF16 |
emulator/accel/ |
Optional multi-source pybind11 execution kernel |
emulator/accel_wrapper.py |
Drop-in Python wrapper for the C++ CPU core |
emulator/system.py |
SoC integration and batched execution |
bios.asm |
Forth BIOS in assembly: boot, devices, multicore, and checked crypto |
bios.rom |
Pre-assembled BIOS binary |
kdos.f |
Bank 0 KDOS core: compute, storage, scheduler, UI, modules, crypto, and multicore |
networking.f |
Userland Ethernet-through-TLS module, sockets, and UDP data-port transport |
cli.py |
CLI, boot modes, headless TCP terminal, and debug monitor |
asm.py |
Two-pass assembler with listing output |
emulator/devices.py |
MMIO device models |
audio_sinks.py |
Explicit opt-in audio playback adapters |
nic_backends.py |
Loopback, UDP-tunnel, and Linux TAP NIC backends |
data_sources.py |
Simulated network data sources |
diskutil.py |
MP64FS image utility |
tests/ |
Host, guest, integration, resource-gated, and live-network tests |
Makefile |
Current build, focused sequential test, monitoring, sanitizer, and live-network targets |
setup_accel.py |
pybind11 extension build configuration |
bench_accel.py |
CPU-path benchmark driver |
rtl/ |
Portable RTL plus target overrides |
rtl/sim/ |
RTL testbenches |
The docs/ directory contains comprehensive reference material:
| Document | Contents |
|---|---|
| docs/getting-started.md | Quick-start guide — booting, REPL, first buffer, first kernel, first pipeline |
| docs/bios-forth.md | BIOS Forth word reference by category; docs/BIOS-DICTIONARY.md records the 481-entry dictionary |
| docs/kdos-reference.md | KDOS core and loadable networking word reference, organized by source section |
| docs/isa-reference.md | CPU instruction set — all 16 families, encodings, condition codes, CSRs |
| docs/architecture.md | System architecture — memory map, MMIO registers, boot sequence, interrupts |
| docs/filesystem.md | MP64FS specification — on-disk format, directory entries, file types |
| docs/tile-engine.md | Tile engine programming guide — CSRs, MEX encoding, extended ops, FP16/BF16 |
| docs/extended-tpu-spec.md | Extended TPU specification — crypto, DMA, BIST, perf counters, FP16 |
| docs/tools.md | CLI & debug monitor, assembler, disk utility, test suite, C++ accelerator |
| docs/development-session.md | Headless and shared live control, terminal snapshots, JSON scenarios, pygame viewing, and PNG capture |
| docs/rich-terminal/FLOWING-APPEARANCE.md | Opt-in rounded-channel rendering, recorded-frame previews, and remaining desktop semantics |
| docs/audio-output.md | One-shot PCM DMA contract, deterministic capture semantics, and hardware direction |
Note: Some details (e.g., the full multi-bank megapad architecture) reflect the simplified emulator model rather than the complete hardware design.
Forth might seem like an unusual choice for a modern system, but it's remarkably well-suited to this architecture:
Compactness — The entire BIOS interpreter, compiler, and 481 built-in
words fit in an ~83 KiB ROM image (bios.rom). Forth is one of the most
space-efficient programming environments ever created.
Interactivity — Type a word, it executes immediately. Development is fast and exploratory — perfect for building kernels and pipelines on the fly.
Extensibility — New words are defined in terms of existing ones. There's no distinction between "system" words and "user" words. The dictionary is open and everything is inspectable.
Control — Forth gives complete control over memory, I/O, and execution flow. You can write high-level abstractions or drop to raw machine operations as needed.
The combination of Forth (for orchestration) and the tile engine (for data-parallel computation) creates a programming model that's both powerful and surprisingly elegant.
The Python emulator and its native acceleration path are architectural simulations: they implement the instruction set and devices, but do not simulate every edge or pipeline bubble in the portable RTL. One emulator step is one retired guest instruction. The separate deterministic virtual cycle model advances timers, devices, scheduling, and replay; neither value is an automatically measured RTL clock count.
The FPGA RTL (targeting Genesys 2 / Kintex-7 325T) implements the full heterogeneous SoC including the extended tile engine and crypto/PQC accelerators. Key differences from the emulator are cycle-level timing and block-RAM-backed memory:
- 1 MiB SRAM base (4 MiB expanded), backed by FPGA block RAM
- Buffered in-order IF/DEX state machine with a per-core 4 KiB direct-mapped instruction cache; no speculation or branch prediction
- Four full cores plus three four-microcore clusters with round-robin bus arbitration and per-core QoS weights
- Crypto accelerators: AES-256-GCM, SHA-3/SHAKE, CRC, TRNG, X25519/ Field ALU, NTT, and a working Python ML-KEM-512 value path whose current RTL counterpart remains a stub
- Fully static design — retains state down to DC for ultra-low power
Manual resource estimates in Kintex-7 325T terms (no synthesis yet). The
full floating-point datapath (docs/floating-point.md) is a large share of
the chip: each of the seven tile engines (four full cores, three clusters)
has two multi-format FMA units, two divide and square-root units, and
sixteen TCVT lane converters, and each full core and cluster has one scalar
FPU. These are rough hand estimates, not synthesis results.
| Resource | Before full float | Full-float additions | Estimated total | Kintex-7 325T |
|---|---|---|---|---|
| LUTs | ~145K–185K | ~250K–350K | ~400K–535K | 203,800 |
| FFs | ~220K | ~30K–50K | ~250K–270K | 326,080 |
| BRAM36 | ~240 | 0 | ~240 | 445 |
| DSP48E1 | ~420–620 | ~220 | ~640–840 | 840 |
The RTL describes the intended chip, so it no longer fits the Kintex-7
325T as a whole. A prototype on that board would build fewer engines or
set FMA_UNITS = 1, which keeps every result and changes only the cycle
counts.
Software written for the emulator is intended to run identically on the RTL. The simplification affects timing, not architectural behavior. A future roughly 1--2 average-CPI scalar implementation is an RTL/ASIC and memory-system optimization target; it does not require the functional emulator to invent pipeline stalls, and it is not a promise that every instruction completes in one or two clocks.
CC0 (for all components not superseded by existing licenses)
This project draws inspiration from:
- The Forth programming language and its interactive, stack-based model
- Modern GPU architectures and their data-parallel execution models
- Classic microcomputers like the Commodore 64, where hardware and software formed a unified, exploratory environment
- The RCA CDP1802 for its register-designator concepts and compact instruction encoding
- The RISC-V ISA for its clean, orthogonal design principles
Megapad-64 is a synthesis of these ideas, reimagined for a hypothetical architecture that never was — but perhaps could be.