Memora8: Eight Processors and All Planned Peripherals Fit into a Single Artix-7 200T FPGA

AI Summary: On October 17, 2026, Memora8’s complete planned digital architecture passed Vivado synthesis, placement, routing, and timing analysis on one Artix-7 XC7A200T FPGA. The build combines eight 32-bit CPUs, 1 MiB of shared SRAM, and controllers for storage, networking, camera, motion, and cryptographic functions. It used 90.2% of LUTs and 84.5% of Block RAM, with a post-route setup slack of +0.030 ns, and produced a bitstream. This confirms implementation fit and timing closure for the reported build; it does not establish that every external peripheral has been validated on the physical BX72 board.

Architecture, FPGA resource utilization, memory organization, and the redesigned LOAD/STORE pipeline. A technical review of the implementation as of October 17, 2026.

On October 17, 2026, the Memora8 project reached an important engineering milestone: the complete computing system, including eight custom processor cores and all planned peripheral blocks, successfully fit into a single Artix-7 XC7A200T FPGA.

This was more than a successful synthesis of individual modules. The complete system passed placement and routing in Vivado 2025.2, met the specified timing constraints, and was converted into an FPGA configuration bitstream.

We managed to integrate eight 32-bit processor cores, 1 MiB of shared SRAM, a DDR3 controller, Ethernet, microSD, a camera interface, eight motor control channels, eight position sensor channels, I²C, SPI, UART, GPIO, timers, hardware page transfer mechanisms, and BLAKE3 and Ed25519 accelerators into a single FPGA.

These are the hardware controllers and interfaces. External DDR3 memory, the microSD card, camera, sensors, and motors remain physical components connected to the board.

The main achievement is that implementing the entire planned digital architecture did not require a larger FPGA or the removal of any planned subsystem.

This result came after a series of changes affecting not only the peripherals but also the processor itself: the instruction pipeline, memory access paths, control signal localization, and hardware arithmetic operations.

For background, see the Memora8 implementation overview and the report on its K4,4 memory architecture. The previous weekly development report covers the work leading up to this implementation milestone.

1. Complete FPGA Implementation Results

The target device is the AMD/Xilinx Artix-7 XC7A200T-FBG484-2, installed on the BX72 board.

On October 17, the complete mr8_bx72_top design passed synthesis, placement, routing, and post-route optimization.

The Vivado implementation reports produced the following results:

Resource utilization and timing results are taken from the Vivado implementation reports generated on October 17, 2026. Available resource counts correspond to the XC7A200T device.

The mr8.bit configuration file was generated on October 17 at 22:24.

Three results are particularly significant.

First, 90.2% LUT utilization. The system occupies a substantial portion of the programmable logic available in the Artix-7 200T. Approximately 13,000 LUTs remain available, meaning that further expansion will require careful consideration of hardware costs.

Second, Block RAM utilization. Almost 85% of the available Block RAM capacity is already used. This is expected for an architecture with its own SRAM, numerous hardware buffers, queues, and data transfer controllers.

Third, positive timing results. After routing, Vivado reported WNS of +0.030 ns and WHS of +0.029 ns. All specified timing constraints were satisfied.

However, the timing margin is small: only 30 picoseconds on the worst setup path. This means the result cannot be interpreted as permission to add hardware blocks without considering their impact. Even relatively small RTL changes may affect routing and critical paths.

That is precisely why this milestone matters: the architecture not only fits within the available logic resources but also passes the complete implementation process on the actual target FPGA.

The routing report additionally confirms that all 196,845 nets requiring routing were successfully connected, with zero routing errors.

The Design Rule Check (DRC) report still contains warnings that require further review before finalizing the hardware implementation. A successful FPGA build does not mean every question related to physical implementation and operation has been resolved.

For us, it is important to distinguish between three different achievements: an implemented RTL architecture, a successfully generated FPGA configuration, and a system fully tested with real external hardware.

As of October 17, the first two milestones had been achieved. Complete physical testing of the new peripherals remains the next stage.

2. Memora8 Architecture: Eight CPUs, One Memory Cluster

Memora8 is a custom 32-bit processor architecture. The current implementation contains eight identical CPU cores integrated into a single computing cluster.

Each processor has 32 general-purpose registers, each 32 bits wide, its own memory management unit (MMU), and an instruction execution pipeline.

The Memora8 instruction set consists of 32 primary operations using fixed-length 32-bit instructions.

The architecture supports integer arithmetic, logical operations, shifts, comparisons, branches, multiplication, division, memory operations, and dedicated instructions for accessing the System Bus.

Unlike conventional multicore systems that rely on cache hierarchies, the current Memora8 implementation uses a banked SRAM architecture with explicit memory page ownership management.

Physical SRAM Organization

The shared SRAM has a capacity of 1 MiB and is divided into 128 pages of 8,192 bytes each.

The implementation uses the K4,4 topology, also identified as mr8_mem_067.

Physically, memory consists of 16 banks containing eight pages each. Logically, these banks are represented as 32 access endpoints, each exposing four pages.

This arrangement provides a fixed topology connecting processors to memory without requiring a universal switching network in which every CPU can simultaneously access every physical page.

Each processor has eight MMU windows. Each window maps an 8 KiB virtual memory region to a particular physical page.

Memora8 uses exclusive page ownership.

A page may be free, owned by one of the processors, or temporarily assigned to the hardware data transfer mechanism known as PageMover.

The presence of multiple physical SRAM ports does not mean that several CPUs may independently modify the same page. Access permissions remain controlled by the ownership mechanism.

This approach moves part of the complexity of memory coordination away from dynamic hardware arbitration and into explicit page management operations.

Dual-Port Memory

An important implementation feature is the use of dual-port Block RAM.

Port A serves ordinary processor memory operations: LOAD and STORE.

Port B is used for instruction fetching and, when page ownership permits, PageMover operations.

As a result, a processor can fetch an instruction and access data within the same physical memory page simultaneously, provided that the accesses target different words.

This is particularly important for the eight-stage pipeline: instruction fetching should not stall simply because the processor is performing another data read or write.

Simultaneous STORE and instruction fetching from the same physical word do not guarantee a defined instruction value. This limitation is explicitly considered in the architecture and its tests.

3. System Bus: A Unified Interface for Peripheral Devices

Memora8 uses its own System Bus interface to communicate with peripheral devices.

A fundamental design decision is that processors do not need a separate machine instruction for every new device.

Instead, devices expose their interfaces through a common System Bus address space.

Each CPU has a local 128-byte buffer consisting of 32 32-bit words.

DATA0    word 0
DATA1    word 1
...
DATA30   word 30
CONTROL  word 31

The first 31 words are used for command parameters and operation results.

The final word, CONTROL, specifies the device and command.

DEVICE_REF = (GROUP << 5) | DEVICE

CONTROL = (CMD << 10) | DEVICE_REF

A command is initiated by writing to CONTROL.

For ordinary devices, the result is returned through the same local buffer. Typically, DATA0 contains the operation status, while subsequent words contain the results.

Devices requiring full data transfer buffers may use specialized contracts.

This means adding a new hardware device does not require changing the processor instruction set.

The device developer implements the agreed System Bus interface, and software can access the device through the existing SB and SBI instructions.

Device Map as of October 17

The current configuration implements the following groups:

A group does not necessarily contain all 32 possible devices. Actual device availability is determined by the hardware configuration and can be discovered through the device information mechanism.

This matters for system software: System Bus provides a universal interaction model without assuming that every possible peripheral is present.

4. Hardware Devices Integrated into the Artix-7 200T

PageMover and the Memory Hierarchy

In Memora8, ordinary LOAD and STORE instructions operate on memory mapped through the MMU.

External DDR3 and microSD storage are not exposed to processors as one continuous linear address space accessible through ordinary memory instructions.

Instead, data transfers are handled by the PageMover family.

It consists of three devices.

PM0 (0x200) transfers pages between SRAM regions. It is also used during hardware boot to copy the boot page from ROM into SRAM.

PM1 (0x201) transfers pages between SRAM and external DDR3 memory.

PM2 (0x202) operates on RAW microSD data through dedicated intermediate buffers.

The basic transfer unit is an 8,192-byte page.

PageMover separates large data transfers from ordinary CPU instruction execution.

For example, data may be transferred from DDR3 into SRAM, after which ownership of the page is assigned to a processor for computation. Once processing is complete, the page can be released and reused for another transfer.

The hardware ownership mechanism prevents a page from being used simultaneously by incompatible participants.

Ethernet

The Memora8 network subsystem is built around a hardware MAC and an RGMII interface.

Ethernet provides several independent ways for software to interact with the network.

The main FunctionDevice, 0x221, handles configuration, status, and statistics.

Devices 0x123 and 0x124 implement queues for small Ethernet RX and TX messages.

Special memory pages are provided for larger frames and can be accessed through PageMover.

0x404–0x407  Ethernet RX pages
0x408–0x40B  Ethernet TX pages

This allows short messages to be transferred through FIFO queues while larger blocks use memory pages.

Different transfer mechanisms can therefore be selected depending on the amount of data.

The hardware Ethernet subsystem provides Layer 2 frame handling. Conventional network protocols, including IP and TCP, are intended to be implemented in software.

A separate hardware UDP debugger provides system access independently of application code running on the processors.

OV5640 Camera

The camera is exposed as device 0x222 in Group 17.

The implementation includes a digital DVP input path that transfers incoming image data into external DDR3 memory.

Camera configuration is performed through SCCB.

A ring-buffer mechanism is provided for storing image frames in DDR3.

Configurations with one, two, four, or eight buffers are supported.

This separates physical image acquisition from subsequent processing by the CPUs.

The camera can produce image data at its own rate while software processes previously captured buffers.

However, implementing the interface and successfully simulating the digital logic do not replace testing with the physical camera.

Position Sensors and Motion Control

Memora8 implements eight hardware channels for AS5048A angular position sensors.

These are exposed as Group 4 devices at addresses 0x080–0x087.

Motion control is implemented through eight independent Group 18 devices.

Each channel generates STEP, DIR, and ENABLE signals, monitors an external FAULT input, and performs motion according to configured parameters.

Some operations, including STEP pulse generation, are implemented directly in hardware.

Therefore, the processor does not need to generate every STEP pulse through software.

A common E-STOP mechanism is provided for the entire motion subsystem. Its effect on motor outputs is implemented in hardware and does not depend on how quickly a CPU processes the corresponding event.

After the emergency signal is removed, a separate acknowledgment and restart procedure is required.

During development, considerable attention was paid not only to functionality but also to limiting hardware resource consumption.

In particular, shared parameter preparation and validation operations are separated from the local logic of each motor channel.

This allows eight independent motion channels to be implemented without duplicating all supporting logic eight times.

I²C, SPI, and UART

The I²C (0x223) and SPI (0x224) devices are implemented as separate hardware controllers.

Both use an asynchronous execution model from the CPU’s perspective: the processor submits an operation, the device accepts it, and the physical transfer proceeds independently.

Each controller uses 32-byte transmit and receive buffers.

The I²C controller supports read and write operations, repeated START, ACK/NACK, and clock stretching.

The SPI controller supports all four standard CPOL/CPHA modes.

The system also includes two UART interfaces with their own transmit and receive queues.

Together, these interfaces support a broad range of peripheral modules without requiring protocols to be implemented by repeatedly toggling GPIO pins in software loops.

Hardware Cryptography

Group 22 contains two specialized devices:

0x2C0 — BLAKE3.

0x2C1 — Ed25519 VERIFY.

BLAKE3 provides hardware hash computation, including processing streams of memory pages.

Ed25519 provides digital signature verification using one of two configured public keys.

Both devices use an asynchronous command model.

A processor submits the required data and initiates an operation. The device then continues independently. The result can be retrieved through the corresponding status and result commands, while completion is reported through the event mechanism.

This avoids occupying a CPU for the entire duration of a cryptographic operation.

5. The Eight-Stage Pipeline and the STORE Redesign

One of the most significant changes introduced on October 17 was the redesign of the memory pipeline.

Memora8 uses an eight-stage instruction pipeline:

IFD-MMU
   │
   ▼
IFD-BRAM
   │
   ▼
IFD-LOAD
   │
   ▼
LR
   │
   ▼
EX
   │
   ▼
MEM-MMU
   │
   ▼
MEM-BRAM
   │
   ▼
COMMIT

The first three stages handle instruction addressing, fetching, and reception.

LR obtains operands from registers and performs the necessary forwarding operations.

EX performs arithmetic, computes memory addresses, and evaluates branch conditions.

MEM-MMU verifies the virtual address, page mapping, and access permissions.

MEM-BRAM handles hardware memory accesses.

COMMIT is responsible for architectural instruction completion.

The processor uses in-order commit.

However, separate computations and memory operations may occupy different pipeline stages simultaneously.

The Previous Organization

Before October 17, LOAD and STORE followed different paths.

LOAD generated its request at MEM-BRAM, and its result was committed when the instruction completed.

STORE passed address verification and waited until COMMIT. Only then was the write submitted to a separate hardware channel.

Additional W0/W1 stages and the write_drain mechanism were used to complete physical writes.

LOAD:

EX → MEM-MMU → MEM-BRAM → COMMIT


STORE:

EX → MEM-MMU → COMMIT → W0/W1 → BRAM

This provided control over architectural state changes, but it increased the complexity of the memory path.

In particular, the implementation had to track writes that had already been authorized but had not yet physically completed.

The New LOAD/STORE Organization

On October 17, reads and writes were unified into a single memory access path:

                EX
                 │
                 ▼
              MEM-MMU
                 │
                 ▼
              MEM-BRAM
                 │
          ┌──────┴──────┐
          │             │
         LOAD          STORE
          │             │
          └──────┬──────┘
                 │
                 ▼
               COMMIT

Both types of memory access are now generated from the same MEM-BRAM stage packet.

The packet carries the address, the route to the physical memory bank, write data, and the READ/WRITE operation indicator.

Communication with the memory channel uses the valid and ready handshake.

A STORE advances to COMMIT only after its memory request has been accepted.

COMMIT no longer issues the same STORE a second time.

The accepted request is physically executed on the following BRAM clock edge.

The W0/W1 stages and the four-cycle write_drain mechanism have been removed.

Memory Ordering

The new organization allows consecutive memory operations to pass through a single ordered channel.

Consider the following instructions:

SW r3, 0(r1)
LW r4, 0(r1)

The first instruction writes a value to memory. The next reads the same word.

When the necessary resources are available, the two requests can reach BRAM on consecutive clock cycles.

There is no need for a dedicated forwarding path that passes STORE data directly to LOAD.

Instead, correctness is ensured by the ordering of physical memory operations.

This does not mean that every LOAD/STORE sequence is guaranteed to execute at one instruction per cycle.

Stalls may still occur because of register dependencies, pending results, MMU operations, system commands, and other pipeline constraints.

However, the artificial delay associated specifically with the previous STORE path is no longer necessary.

Precise Exceptions and STORE Cancellation

Allowing STORE requests to proceed through MEM-BRAM raises an important question: how can we guarantee that a younger STORE does not modify memory when an older instruction must raise an exception?

Memora8 uses the MTR mechanism for exception handling.

A memory access fault is detected during MEM-MMU. However, the exception becomes architecturally visible only when the corresponding instruction reaches COMMIT.

All younger instructions that must not execute after the exception are canceled.

Therefore, before a STORE request is accepted, the processor must ensure that it cannot pass an older instruction with an unresolved result, exception, or control-flow redirect.

The new implementation accounts for these dependencies directly in memory request admission.

If STORE itself encounters a fault, no write is performed.

If an older instruction detects an MTR condition, the younger STORE is canceled before SRAM is modified.

This is a fundamental guarantee of the redesigned pipeline.

Moving STORE onto the shared MEM-BRAM path must not compromise precise exception handling.

A dedicated memory_pipeline_test.sv was added to verify this behavior.

The test covers SW→LW, SW→SW, accesses to the same and different addresses, request backpressure, pipeline freezing, and cancellation of younger STORE instructions.

It also monitors the physical BRAM write-enable signal.

Obtaining the correct final program result is not sufficient: the test must ensure that an unauthorized write never occurs.

6. Signal Localization and Critical Path Optimization

Successfully fitting eight processors and numerous peripherals into one FPGA required more than changes to logical architecture.

Physical signal paths also had to be optimized.

In a large FPGA design, the problem is often not the number of operations but the distance between a signal source and its consumers.

For example, the result of reading one of several memory banks may need to pass through a shared data selection network before reaching a register inside the processor.

With many banks and processors, such paths can become critical.

An additional memory restructuring step was completed on October 17.

Registering LOAD Results Near the Memory Bank

The current implementation uses a parameter called BANKED_LOAD_RESULT.

Read results are registered close to their source, within the local memory bank logic.

The processor then receives already registered data.

Previously, the shared result selection path extended all the way to a register inside the CPU.

Now part of that logic is moved closer to the physical memory.

This helps reduce the length of the critical combinational path without adding another architectural LOAD stage.

Importantly, the change affects register placement and signal organization rather than instruction encoding or memory access semantics.

Localized Memory Routes

Memory route selection signals play an important role in the Memora8 banked architecture.

After LOAD and STORE were unified, both operations began using the same registered memory channel.

A further optimization introduced the ACTIVE_MEM_ROUTES mode, in which physical page selection is derived directly from the registered route.

Inactive channels must have zero-valued routes.

This condition is checked in Verilator.

The purpose of this change is to remove unnecessary control logic from the critical memory access path.

Arithmetic Operations

The optimization work also affected the long-latency arithmetic unit.

In particular, parts of multiplication were divided into additional registered stages to reduce the length of combinational chains.

This is a common FPGA design trade-off.

Allowing an individual operation to take additional cycles may be more beneficial than attempting to perform too much arithmetic in a single cycle.

The benefit is the ability to preserve the target clock frequency of the entire system.

Motor Controllers

A similar approach was used in motor control optimization.

Parameter validation and command preparation are separated from actual STEP pulse generation.

Configuration values are first captured in local registers.

This reduces long combinational connections between shared control logic and independent motion channels.

After the latest changes, preparing a START command takes 16 cycles from the moment the motor block accepts it.

At 125 MHz, this corresponds to 128 ns.

For motion control applications, this preparation delay is relatively small, while shortening critical paths can be important for the entire FPGA implementation.

7. Asynchronous Devices and EVENT_POOL

Another architectural principle in Memora8 is the separation of command acceptance from physical operation completion.

This is especially important for devices that operate much more slowly than the processor.

For example, an I²C transfer, a microSD read, or a cryptographic operation may require many clock cycles.

Keeping the CPU execution pipeline blocked until the physical operation completes would be inefficient.

Instead, a device accepts a command, reports its acceptance, and continues executing autonomously.

When the operation completes, the device updates its state and generates the corresponding event.

Memora8 uses EVENT_POOL, a dedicated Group 0 device at address 0x018, to manage these events.

Events are organized by group and device, allowing software to identify the source of a change.

Event acknowledgment is defined by the contract of the originating device.

For example, completing a PageMover operation, receiving Ethernet data, and finishing a cryptographic calculation require different actions from software.

This approach provides a common event mechanism without eliminating the specific behavior of individual devices.

For the future Reganta operating system, this is an important architectural foundation.

The operating system will be able to manage peripherals without converting every data transfer into a long synchronous CPU wait.

8. Implementation Verification

The project uses several levels of verification.

The first is testing individual RTL modules.

These tests examine specific properties such as FIFO behavior, SPI signal generation, BRAM access, error handling, and internal state machine interactions.

The second level is system simulation.

This allows the eight CPUs, shared SRAM, System Bus, and peripherals to be tested together within one digital model.

The third level is FPGA implementation in Vivado, including resource utilization and timing analysis.

The fourth is testing on the physical BX72 board.

As of this technical review, the most significant new achievement is successful completion of the third level for the complete configuration.

Memory Pipeline Verification

A dedicated test is provided for the redesigned LOAD/STORE mechanism:

bash mr8/verilator/test_memory_pipeline.sh

This connects the processor core to the RTL model of a physical memory bank.

The test scenarios cover consecutive writes and reads, request ordering, pipeline freezes, MTR handling, and the absence of duplicate STORE operations.

A critical part of the test is direct observation of the BRAM write-enable signal.

Additional system tests cover the MMU, PageMover, hardware boot, and CPU interactions.

Peripheral Verification

The repository contains dedicated verification scenarios for individual devices:

These tests make it possible to verify devices both independently and through the complete System Bus model.

However, successful simulation results must not automatically be interpreted as proof of correct operation under every physical condition.

For example, camera simulation verifies the digital acquisition and control model, but it does not replace testing the actual sensor, power supply, and physical connections.

Additional FPGA Diagnostics

The final commit on October 17, 578884b, introduced two new diagnostic commands:

test-cpu-stream
test-cpu-motion

test-cpu-stream is designed to verify long SW/LW instruction sequences on all eight processors, including dependencies and accesses to different SRAM pages.

test-cpu-motion verifies CPU access to sensor and motor controller registers using actual System Bus instructions.

These diagnostics were added after the evening bitstream had been generated.

They are intended for further testing of the FPGA configuration and do not, by themselves, establish that all physical peripherals have already been tested.

9. What Artix-7 200T Resource Utilization Tells Us

The implementation results are interesting for more than simply confirming that the design fits.

They reveal important characteristics of the architecture itself.

Logic: 90.2%

Using 121,448 LUTs indicates a high logic utilization density.

Memora8 contains eight processors, a distributed memory subsystem, System Bus, and numerous peripheral state machines.

In this architecture, hardware cost is not determined solely by the computational units inside the CPUs.

A significant amount of logic is consumed by data routing, device management, state validation, arbitration, memory interfaces, and hardware protocols.

Therefore, removing unnecessary control paths and unifying similar mechanisms directly affects the feasibility of implementing the complete system.

Block RAM: 84.5%

High Block RAM utilization is a consequence of Memora8’s extensive use of on-chip FPGA memory.

Block RAM is used not only for shared SRAM but also for various buffers, queues, and intermediate data storage.

The architecture relies on direct interaction with hardware-managed pages, making embedded memory one of the project’s most important resources.

The current result demonstrates that the Artix-7 200T can accommodate both the computational SRAM and the planned peripheral buffers.

DSP: 7%

DSP utilization tells a very different story.

Only 52 of the 740 available DSP48 blocks are used.

Therefore, the main limiting resources in the current implementation are programmable logic and embedded memory, rather than the number of hardware multipliers.

This is an important observation for future development.

It does not mean that new computational units can be added at no cost. In addition to DSP blocks, they also require registers, routing resources, control logic, and timing compliance.

However, the distribution of resource utilization clearly shows where the main constraints lie.

Timing: Positive but Limited Margin

A WNS of +0.030 ns means the design meets its timing constraints with a 30-picosecond margin on the worst setup path.

For a design of this density, this is a significant result.

At the same time, it means the architecture is already operating close to its specified timing limits.

Future development must therefore consider not only RTL functionality but also the physical cost of every architectural decision.

In some situations, adding a register or using a longer multicycle operation may be preferable to implementing a large combinational circuit.

The October 17 optimizations — memory localization, arithmetic stage separation, and STORE path restructuring — illustrate this approach.

10. Project Status as of October 17, 2026

To make the result reproducible, it is useful to record the sequence of changes.

Commit 27423b6 — October 17, 11:21

LOAD and STORE were unified into a shared memory access path.

The additional W0/W1 write stages and write_drain were removed.

Dedicated tests for the redesigned memory pipeline were added.

Commit 42b145a — October 17, 20:21

LOAD results and memory routing paths were localized.

Parts of the arithmetic implementation were reorganized.

Motor controller parameter validation was refined.

Vivado implementation — October 17, 22:22–22:24

The complete mr8_bx72_top design passed routing and timing analysis.

The mr8.bit configuration file was generated.

Commit 578884b — October 17, 23:42

Additional diagnostic tools were introduced to test CPU STORE/LOAD streams and access to motion-related devices on the FPGA.

This final commit changed testing tools rather than the RTL of the implemented hardware configuration.

Therefore, the evening bitstream corresponds to the RTL state following the architectural changes in 42b145a.

11. Next Steps: From Successful FPGA Implementation to System Validation

The October 17 result resolves one of the project’s main engineering questions.

Previously, we needed to demonstrate that the entire planned architecture could fit into the selected FPGA. The complete implementation results now confirm that it can.

The next stage involves a different kind of work.

We need to validate the system under real operating conditions: communication with physical DDR3 memory, Ethernet reliability, microSD access, sensor integration, motor control, emergency stop behavior, and image acquisition from the camera.

The timing characteristics of external interfaces, electrical constraints of the board, and interactions between hardware subsystems under simultaneous load will require particular attention.

Software development is continuing in parallel.

The Reganta operating system is being developed for Memora8, alongside the Sekura JS programming language.

Future software will need to make use of the processor’s architectural features: explicit memory page management, hardware events, asynchronous peripherals, and specialized computing units.

Another important task is bringing the mr8sim software simulator into alignment with the current RTL implementation.

After the recent changes to memory, the pipeline, and peripheral devices, some of the simulator’s earlier simplified models no longer accurately represent the behavior of the hardware system.

Why This Milestone Matters

When developing a custom processor, it is easy to focus on the functionality of individual blocks.

But building a complete computing system requires all components to operate together correctly.

Eight processors must access memory without violating page ownership rules.

Peripheral devices must perform operations independently of CPU execution.

The System Bus must provide predictable command and result exchange.

Hardware exceptions must not cause invalid memory writes.

And all of this logic must physically fit into the selected FPGA while meeting its timing constraints.

On October 17, we obtained confirmation that this combination of architectural decisions is implementable on the Artix-7 200T.

Eight custom processors and all planned Memora8 peripheral logic — from Ethernet and DDR3 to a camera, sensors, motors, and cryptographic devices — now fit into a single FPGA.

This is not the end of development.

It is the transition from asking, “Can we implement the entire architecture in one FPGA?” to a new question:

“How can we make the best possible use of the complete computing system we have built?”

That is where the next phase of Memora8 development will be focused.

Memora8 is developed by Jupiter Soft in Kazakhstan as the hardware foundation of the Sekura technology initiative.

Technical basis: Memora8 RTL as of October 17, 2026; commits 27423b6, 42b145a, and 578884b; Vivado 2025.2 implementation reports impl_utilization.txt, impl_timing.txt, and route_status.txt; and the generated mr8.bit configuration file.