Memora8: One Week of Building an Eight-Core FPGA Computer

AI Summary: Between October 3 and 10, 2026, Memora8 advanced from an eight-core processor toward a more complete FPGA computer. The Artix-7 XC7A200T build combines eight 32-bit CPUs, 1 MiB of shared SRAM, System Bus, PageMover, physical microSD, two UARTs, 19 GPIO lines, and BLAKE3-256 and Ed25519 VERIFY hardware. The final reported build used 109,517 LUTs and met its checked timing constraints at 125 MHz, with setup WNS of +0.090 ns and hold WHS of +0.041 ns. Physical tests covered the microSD interface, UARTs, GPIO, and cryptographic blocks. A custom Ethernet controller and incremental formal verification are planned next; neither is presented here as completed.

Between October 3 and October 10, Memora8 made a series of changes across memory, storage, physical I/O, and cryptography. The goal was to move beyond instruction execution and bring more of a computer’s core functions into one eight-core FPGA system.

Memora8 is a custom 32-bit processor architecture developed at Sekura. Its current FPGA implementation targets the Xilinx Artix-7 XC7A200T on the BX72 board and runs at 125 MHz. The project is developed alongside the Reganta operating system and Sekura JS.

This report summarizes the week’s implementation and test results, while distinguishing completed hardware work from the next planned stages. For the earlier processor and memory status, see the eight-core implementation overview and the K4,4 memory architecture report.

PageMover and Memory Optimization

PageMover moves pages of data between system components. Since processors, memory, and peripheral devices rely on these transfers, the number and arrangement of physical channels affect both FPGA resource use and routing complexity.

Three changes were made to the memory subsystem during the week:

• The number of physical PageMover channels was reduced by half, saving 7,119 LUTs compared with the previous implementation.
• BRAM port access was redistributed to simplify how memory resources are shared.
• The legacy STEP mechanism for instruction-by-instruction execution was removed because it no longer matched the current processor architecture.

After the changes, the eight processor cores and page-transfer operations were tested. The results show why FPGA optimization must account for both logic count and physical connections: a design can fit within the device’s LUT budget and still be difficult to route at its target clock frequency.

microSD Storage and 8 KiB Pages

Memora8 now has a physical microSD interface tested on the FPGA board. The interface uses raw sector-level access: the hardware reads and transfers blocks, while software can interpret their contents. This avoids putting a full file-system implementation in the FPGA logic.

Memora8 pages are 8,192 bytes (8 KiB). In the selected access mode, each microSD sector is 512 bytes, so one page requires 16 consecutive sectors:

16 sectors × 512 bytes = 8,192 bytes

The measured physical-board test reported:

This throughput is the result of the reported test, not a claim of maximum interface performance. The test demonstrates that the hardware read a complete page from a physical card and provides a basis for future software-module loading from persistent storage.

Two Hardware UARTs and 19 GPIO Lines

Memora8 added two independent serial interfaces, UART0 and UART1. Each has separate receive and transmit signals, independently configurable baud rate, data widths from 5 to 8 bits, parity and stop-bit options, buffering, and receive/transmit error handling. Both devices connect to System Bus and the EVENT_POOL event mechanism.

Both UARTs were tested on the physical BX72 board, including loopback tests using external jumper wires. That checked the signal paths through the FPGA pins in addition to the internal logic.

The board configuration also exposes 19 general-purpose GPIO lines, two software-accessible buttons (KEY0 and KEY1), a hardware reset button (KEY2), and two controllable LEDs. Input changes can be reported through EVENT_POOL, allowing software to handle changes as events instead of continuously polling each pin.

These interfaces provide direct connections to external equipment and lay groundwork for Reganta’s future device support. The System Bus reference documents the processor’s device interface.

BLAKE3 and Ed25519 VERIFY on the FPGA

Two hardware cryptographic blocks were implemented and tested on the physical Artix-7 system:

• BLAKE3-256 computes hashes for pages and software modules.
• Ed25519 VERIFY checks digital signatures using trusted public keys.

The tests exercised both devices through the processor and System Bus interfaces, including interactions with SBI and hardware events. BLAKE3 tests covered HEADER and MODULE operations, data preservation, and continued CPU execution after a result was returned. Ed25519 tests covered trusted keys and rejection of an incorrect key or unsupported command.

The durations are for the complete test procedures, including hardware communication; they are not single-operation accelerator latency measurements.

These devices are intended to support a trusted loading path for Reganta modules. The planned design stores a module’s signature in its ModuleHeaderPage and uses public keys embedded in the FPGA configuration. The processor does not store private cryptographic keys. Integrating verification into the module-loading procedure remains future work; hardware tests of the blocks alone do not establish a completed trusted-boot flow.

Routed Build and Timing at 125 MHz

The week’s integrated build completed for the Artix-7 XC7A200T and generated a bitstream. Reported resource use was:

The final build reported +0.090 ns setup WNS, +0.041 ns hold WHS, no timing violations, 185,393 routed nets, and zero routing errors. DRC reported warnings but no errors. Placement and routing took 2 hours 10 minutes, including 1 hour 44 minutes for routing.

The positive slack shows that this routed build met the checked 125 MHz timing constraints. The margins are small, and the report notes routing congestion. Future hardware changes will need fresh implementation and timing checks; this result does not guarantee timing for later configurations.

The cryptographic blocks were also measured separately: BLAKE3 used 2,288 LUTs after optimization from 3,118 LUTs, a reduction of about 27%. Ed25519 VERIFY used 8,330 LUTs and four DSP blocks. These block figures are component measurements and should not be added to the full-build total as if they were separate builds.

Next: A Custom Ethernet Controller

The next planned hardware milestone is a production-oriented Ethernet controller. The existing UDP-DEBUG path is intended for development and diagnostics rather than as Reganta’s general network interface.

The proposed controller will be a FunctionDevice connected through System Bus, with four receive pages, four transmit pages, PageMover transfers, and SmallFIFO queues. It is still under development and requires physical-board validation after implementation.

With 81.4% of LUTs used in the reported build and routing already taking substantial time, integrating Ethernet will require attention to resource use, placement, and signal paths. Board testing will need to validate packet transmission and reception, integration with PageMover and System Bus, and operation at the target clock.

Formal Verification After the Hardware Baseline

After Ethernet implementation and board testing, the next major stage is planned formal verification of Memora8 mechanisms. The proposed effort will begin with defined properties and boundaries rather than trying to prove the complete processor at once. Initial areas include instruction behavior, CPU state updates, memory transfers, System Bus and PageMover operations, and multicore interactions.

The intended process is:

Requirement → Formal contract → Implementation check → Reproducible proof

This work has not yet established proofs for the processor. It is a roadmap for building a set of independently scoped, reproducible proofs against a fixed baseline RTL, while hardware development continues.

From Processor to Computing Platform

In one week, Memora8 optimized PageMover, added physical tests for microSD, two UARTs, and GPIO, and implemented and tested BLAKE3-256 and Ed25519 VERIFY across all eight CPUs. The integrated Artix-7 build used 109,517 LUTs, generated a bitstream, and met checked timing at 125 MHz.

The immediate next milestone is a custom Ethernet controller and its hardware validation. Formal verification is planned after that baseline is established. Together, storage, physical interfaces, cryptography, networking, and reproducible proofs are the steps from a processor that executes instructions toward a complete computing platform.

Memora8 is a custom 32-bit eight-core processor architecture developed as part of Sekura, alongside the Reganta operating system and Sekura JS programming language.