Memora8 on Artix-7: From Simulator to a Working FPGA Processor

AI Summary: Memora8 has moved from the mr8sim software simulator to a working MR8 processor implementation on an Artix-7 XC7A200T FPGA. The first hardware profile uses one CPU, 16 physical 8 KiB pages, and 128 KiB of SRAM. mr8sim controls the FPGA over Ethernet using the MR8A command protocol, while MR8P transfers physical pages separately from the control plane. The bring-up verified Ethernet, RGMII, UDP, CSR access, MMU mapping, page ownership, PageMover and snapshot commands, sequence handling, retries, RTL and C++ tests, and a timing-closed bitstream. The next stage is scaling to banked SRAM, more pages and CPUs, and executing real programs on hardware.

Memora8 started as a processor and memory architecture that was convenient to explore inside the mr8sim software simulator. But simulation leaves one fundamental question open: can the same model be moved into real hardware while preserving its architectural properties?

In August 2026, we took the next step: running MR8 on an Artix-7 XC7A200T FPGA and connecting the hardware implementation to mr8sim over Ethernet.

This became more than an FPGA processor implementation experiment. We had to work through the memory system, MMU, page ownership, CPU pipeline, timing closure, Ethernet/RGMII, and finally define dedicated protocols for communication between the simulator and the real processor.

By the end of this stage, mr8sim could control MR8 running on Artix-7, transfer memory pages to it, and receive confirmed responses from the FPGA.

Why Connect mr8sim to a Real MR8

We did not want to create two separate systems: one simulator for development and another independent set of tools for FPGA hardware.

Instead, mr8sim should remain the external environment used to control the processor regardless of where MR8 is actually running:

• inside the software simulator;
• on an FPGA;
• potentially on another hardware implementation in the future.

The resulting architecture looks like this:

mr8sim
   │
   │ Ethernet / UDP
   ▼
MR8 Artix-7
   │
   ├── CPU
   ├── MMU
   ├── SRAM
   ├── ownership
   └── PageMover

The FPGA is therefore not treated as a separate black box, but as another implementation of the Memora8 architecture.

That required a precise boundary between the processor architecture itself and the transport used by the external host to control it.

The First Hardware Profile

The target Memora8 banked-memory model for Artix-7 is designed around one cluster, 32 SRAM banks, 128 pages of 8 KiB each, and up to eight CPUs.

For the first hardware bring-up, however, we deliberately used a smaller profile.

The version tested on the board contains:

CPU:              1
physical pages:   16
page size:        8192 bytes
SRAM:             128 KiB

Each page contains 2048 32-bit words.

This distinction is important. The architectural model is already designed for a larger banked memory system, but the first experiment had a different goal: prove that the entire path works end to end:

host
→ Ethernet
→ FPGA
→ memory
→ MMU
→ CPU

There is little value in scaling memory before this path behaves predictably.

First, Ethernet Had to Work

The first Artix-7 connection quickly demonstrated a familiar property of hardware development: the actual bug may be nowhere near the place where you expect it.

The Ethernet link came up. Packets from the PC physically reached the FPGA. ILA showed activity on GMII RX.

But the UDP parser did not complete packet processing, and MR8 produced no valid response.

The problem turned out to be the phase shift of the incoming RGMII RX clock.

The original scheme used a 90-degree phase shift, while the BX72 board required the RX clock without that shift. After changing the clock generation, Ethernet RX became stable, the UDP parser began completing packets, and the FPGA started transmitting responses.

A minimal standalone UDP echo bitstream was particularly useful for debugging. It allowed us to verify the full path independently:

PHY
→ RGMII
→ Ethernet RX
→ IP
→ UDP
→ UDP TX

Only after that did we return to MR8 itself.

In FPGA development, separating a complex system into minimal independently verifiable paths can save significant time.

The Second Failure Was on Windows

Once the physical Ethernet path was working, strange UDP timeouts still appeared occasionally during page uploads.

The FPGA was actually responding.

The cause was inside mr8sim.

Windows Winsock expects SO_RCVTIMEO to receive a DWORD containing milliseconds, while the existing code passed a POSIX timeval structure.

A timeout intended to be approximately one second effectively became roughly one millisecond on Windows.

After separating the Windows and POSIX implementations, the random timeouts disappeared.

This episode also showed why a formal transport protocol was necessary. With real hardware, it is not enough to simply send a UDP packet. The system must know what happened if a request or response was lost, delayed, or duplicated.

From Raw UDP to MR8A

The initial transport was enough to verify networking, CSR reads and writes, and basic data transfer.

But that is not sufficient for normal processor operation.

The host needs to be able to:

• discover hardware capabilities;
• read CPU state;
• reset the processor;
• stop it;
• run it;
• execute a single step;
• configure the MMU;
• manage physical-page ownership;
• control the PageMover;
• query operation status;
• initiate snapshots.

This led to MR8A: the MR8 Artix-7 Command Exchange Protocol.

MR8A is a compact binary control protocol carried over UDP.

Each request is exactly 16 bytes:

0..3    magic = "MR8A"
4..5    version
6..7    sequence
8       opcode
9       flags
10..11  command / subcommand
12..15  argument / data

All multibyte values use network byte order.

The response also has a fixed size and always contains the sequence number of the request. This allows mr8sim to determine unambiguously which request a given FPGA response belongs to.

Why Sequence Numbers Matter

UDP does not guarantee delivery, ordering, or protection from duplicates.

For a simple laboratory echo test, this is not particularly important. For a command such as MMU_MAP or OWNER_ACQUIRE, it becomes an architectural issue.

Consider this situation:

1. mr8sim sends a page-ownership request.
2. The FPGA executes it.
3. The response is lost.
4. The host sees a timeout.
5. The command is transmitted again.

Without explicitly defined retry semantics, the host and processor can end up with different views of architectural state.

MR8A therefore uses a monotonic sequence number and explicitly distinguishes normal commands, duplicates, and stale sequences.

A request may only be retried when the operation is idempotent or when the protocol defines safe behavior for repeated delivery.

A timeout by itself never means that the command was not executed.

After an uncertain result, mr8sim must query hardware state and perform reconciliation.

This turns UDP from a collection of unreliable datagrams into a controlled processor-management protocol.

MR8A Commands

The current version contains several groups of operations.

Capability and status discovery:

CAPABILITY
STATUS

CPU control:

RESET
STOP
RUN
STEP

MMU control:

MMU_MAP
MMU_UNMAP

Page ownership:

OWNER_ACQUIRE
OWNER_RELEASE

Page movement and transfer control:

PAGE_WRITE_BEGIN
PAGE_READ_BEGIN
PAGE_TRANSFER_STATUS
PAGE_TRANSFER_ABORT

Snapshot control:

SNAPSHOT_REQUEST
SNAPSHOT_CAPTURE
SNAPSHOT_STATUS

The first Artix-7 profile supports one CPU, so only CPU mask 0x01 is valid.

This is also part of the protocol contract: the host must not assume capabilities that a specific hardware profile does not provide.

Control and Data Are Separate

One of the most useful architectural decisions was to separate control traffic from bulk data transfer.

MR8A is designed only for short commands. For example, PAGE_WRITE_BEGIN can tell the FPGA that the host is about to upload a page. But the 8 KiB page itself is never carried inside MR8A.

A separate protocol was introduced for page data: MR8P.

The architecture became:

MR8A = control plane
MR8P = page data plane

This is cleaner than gradually turning the command packet into a generic variable-length transport format.

MR8P: Transferring Physical Pages

MR8P is responsible for transferring physical SRAM pages between mr8sim and MR8.

Each page has a size of:

8192 bytes

The page is transferred in blocks of up to 512 bytes.

The packet contains:

magic
version
operation
page_id
transfer_id
block sequence
byte offset
payload length
CRC32
payload

Each transfer has its own transfer_id. This makes it possible to distinguish blocks belonging to the current operation from blocks belonging to an earlier or later transfer.

Why Page Writes Use COMMIT

The most interesting part of MR8P is not the packet format, but its semantics.

During a write, the host first starts a transfer and then sends the page blocks:

BEGIN
DATA
DATA
DATA
...
END
COMMIT

Until COMMIT, the new page version must not become architecturally visible.

The FPGA accepts data into a staging buffer and verifies:

• page ID;
• offsets;
• block ordering;
• absence of missing blocks;
• total size;
• packet CRC;
• full-page integrity.

Only after successful verification does the new page become visible to the processor.

If a transfer is interrupted or corrupted, the partially uploaded page must not become the new version of memory.

This matters especially in Memora8, where a page is not merely a range of bytes but an independently managed architectural object.

Ownership Applies to the Host as Well

Uploading a page over Ethernet must not become a way to bypass the architecture.

If a page is currently owned by the CPU or the PageMover, the host cannot replace it at the same time.

The hardware model uses exclusive ownership:

FREE
CPU
PageMover
host transfer

A conflict returns BUSY or OWNERSHIP_CONFLICT.

Networking does not sit above the architecture. It is simply another client of the same memory-ownership model.

This is an important Memora8 principle: architectural constraints should remain valid regardless of whether an operation comes from a CPU instruction, a DMA-like PageMover, or an external host tool.

MMU and Page Ownership

The Artix-7 implementation uses a page-oriented memory model.

The CPU does not work directly with arbitrary physical addresses. Instead, it accesses memory through page windows.

In the target configuration, each CPU has eight such windows.

In the Artix-7 hardware profile, MMU_MAP is optimized so that mapping and exclusive acquisition of the physical page happen atomically.

Conceptually:

MMU_MAP
    ↓
validate page
    ↓
check FREE
    ↓
create mapping
    ↓
owner = CPU

MMU_UNMAP performs the reverse transition and releases ownership.

At the general architecture level, mapping and ownership remain separate concepts. Combining them is an optimization of this particular FPGA profile.

The Memory System Was as Challenging as the CPU

The implementation work was not limited to the network interface.

One of the main sources of critical timing paths was the SRAM fabric.

An additional BRAM output register was introduced for memory reads. Memory responses now travel through a registered response path.

The initial implementation also uses a simplifying restriction: a client should not have multiple simultaneously outstanding requests unless a FIFO is present.

This reduces some potential parallelism, but significantly simplifies response-routing correctness.

For a first-generation FPGA implementation, this is a reasonable trade-off: achieve predictable behavior first, then expand concurrency.

The Pipeline Had to Adapt to Real Timing

A software simulator places almost no practical restriction on the length of combinational logic. An FPGA does.

During implementation, the main critical paths were found in:

• MMU and ownership logic;
• page-window selection;
• the register file and wide multiplexers;
• SRAM response routing;
• forwarding paths between CPU stages;
• memory-address calculation.

The goal was not simply to insert arbitrary pipeline stages. Memora8 has a defined instruction-processing order, and changing timing must not change the ISA.

Long paths were therefore registered only where the architectural semantics could be preserved.

After several synthesis and implementation cycles, timing became positive.

For the first stable networked version:

WNS: +0.130 ns
TNS: 0

After integration of the complete MR8A control protocol, the final bitstream also completed implementation successfully:

WNS: +0.038 ns
TNS: 0 ns
hold slack: +0.055 ns
DRC errors: 0

The margin is still small, but timing is closed.

What Has Been Verified on Real Artix-7 Hardware

The experiment has passed several important milestones.

The following have been confirmed on the real board:

• Ethernet RX/TX;
• RGMII operation;
• bidirectional UDP communication;
• requests and responses between mr8sim and the FPGA;
• CSR read/write operations;
• physical-page acquisition;
• upload of one complete page: 2048 32-bit words;
• mapping a page into an MMU window;
• loading a stack page from mr8sim;
• CPU control through a common Artix7Transport;
• MR8A dispatcher operation;
• sequence and response matching;
• duplicate/stale handling;
• timeout and retry logic;
• MMU and ownership commands;
• PageMover control;
• snapshot commands;
• hardware-backed STATUS and PAGE_TRANSFER_STATUS;
• RTL tests for the dispatcher and sequence path;
• C++ transport tests;
• successful Vivado implementation;
• generation of a working bitstream.

This is already significantly more than “the FPGA responds to UDP.” The first complete Memora8 hardware/software execution path now exists.

What This Does Not Mean Yet

A successful bring-up does not mean that the complete hardware Memora8 architecture is finished.

The currently verified hardware profile is still reduced:

1 CPU
16 × 8 KiB SRAM pages

The target Artix-7 banked-memory architecture is much larger:

up to 8 CPUs
32 SRAM banks
128 pages
1 MiB SRAM
8 MMU windows per CPU
IFD + MEM memory channels
PageMover

The intended design uses local bank arbitration instead of a large central crossbar.

Two requests targeting different pages in the same bank can potentially use the two BRAM ports in parallel, while a third request waits in the bank FIFO. A conflict in one bank should not block unrelated banks.

This banked implementation is the next scale of the hardware experiment.

Why This Stage Matters

Before a working FPGA prototype existed, Memora8 could mainly be viewed as an architectural model and a simulator.

Artix-7 adds another dimension.

Now architectural decisions have to survive verification across several layers at once:

ISA
↓
CPU pipeline
↓
MMU
↓
page ownership
↓
banked memory
↓
RTL
↓
FPGA timing
↓
transport
↓
mr8sim

An error at any level becomes observable.

Sometimes it is an incorrect architectural dependency. Sometimes it is an excessively long combinational path. Sometimes it is an RGMII clock phase. And sometimes it is a wrongly configured SO_RCVTIMEO on Windows.

That is probably the most valuable part of the experiment: the architecture gradually stops being a collection of ideas and becomes a set of contracts that can be tested against real hardware.

The Next Step

The immediate goal is no longer to prove that a computer can send a UDP packet to Artix-7. That part is done.

The next steps are higher-level:

• complete loading and execution of real programs;
• run language_lib directly on MR8;
• move from the minimal configuration to banked SRAM;
• increase the number of physical pages;
• verify PageMover behavior;
• expand the hardware profile;
• compare mr8sim and FPGA behavior on the same programs.

The last point is particularly interesting.

If the software and hardware implementations of Memora8 follow the same architectural model and use the same formal interfaces, mr8sim becomes more than just a simulator.

It becomes a reference environment against which the real processor can be verified.

That is the point where the Artix-7 experiment begins to turn into a genuine hardware implementation of Memora8.