I built a nonlinear FPGA computing core with persistent internal state and a 343-node 7×7×7 topology.

This is Gen1. Later generations already exist, but Gen1 is the one I am opening for public inspection.

It does not follow a conventional CPU pipeline model, so I am especially interested in feedback from people who build their own CPUs, soft-cores, and FPGA architectures.

Source, RTL, tests, and documentation:
https://github.com/etoyruben-wq/R-CORE-

A patent application has been filed for the architecture.

Run it. Break it. Change the topology. Port it. Show me where it fails.

I am not looking for “interesting”.

Show me tests.

Hi RUBEN, and welcome. Sorry, can't help with tests. Can say it seems interesting, even though that's not what you're looking for.

I thought it might help others if I say a few words about what I think it is that you've built, according to what you've written.

It's something like a 3D cellular automaton, except with 16 bit states at each node, and with the update mechanism interpreting these states as oscillators. So the effect is a quantisation of a big 3D array of coupled oscillators. There's an initialisation which gives each oscillator a frequency, I think - the oscillators are in effect phase-accumulating.

In order for each node to update according to neighbours, you have a pair of states for each, one is read and the other written. This is a familiar cellular automaton tactic.

As an implementation detail, you have just one update engine which scans the whole array, after which the role of the pair of states can be flipped. Among your questions is the question of what happens with more update engines.

The update engine uses a global precalculated sine table.

Of course I might well have misunderstood something - I'll stop there, and wait for corrections.

Thank you — your interpretation is very close.
I would make only a few small clarifications.
The two state copies are global current/next state banks rather than two physical oscillator states. During a complete sweep, every neighbor read comes from the current bank and every updated node is written to the next bank. Only after node 342 is committed are the banks exchanged, which gives the serial hardware implementation synchronous global-step semantics.
You are also correct about the per-node frequency term. Each node has a fixed deterministic drift value �, and its 16-bit modular phase state evolves from its previous phase, that drift, the sinusoidal contribution of its valid face-neighbors, and optional external injection.
The cellular-automaton analogy is useful, although I would describe Gen1 more specifically as a deterministic local-state lattice with finite-width modular phase dynamics and sinusoidal coupling.
And yes — the question of replacing the single time-multiplexed update engine with multiple engines is one of the important scaling directions. The difficulty is not only duplicating arithmetic, but preserving identical state semantics while handling memory banking, neighbor reads, synchronization, and the atomic global commit.
Thanks for taking the time to read it closely. You understood the architecture very well.
I also plan to add Generation 7 here soon. Judging by the responses so far, there are clearly people here who can read this kind of architecture at the right technical level, so I think the comparison between Gen1 and Gen7 should be much more interesting.

Hi RUBEN,

Your computing core seems like an interesting device, but a bit beyond me, so I have some learning to do. I am not planning on testing anything in the near future. I tend to stick to my own cores. Having independent testing is a good idea. I think there would not be that many people who would know how to test the core.

I cannot fathom how it would be applied? Would it be integrated along side GPU software to manage states?

If the entire R-Core is time multiplexed, then would it not be slow? It seems like there would be opportunity to speed things up if rows, columns, or grids were processed in parallel.

The choice of a 7x7x7 lattice is interesting. Since it is time multiplexed I think there is not much difference from using a linear array (343)? The difference being only in the node labelling.

I am reminded of a couple of devices I have worked on, a neural network with time multiplexed neurons, and an interval timing device (PIT) that uses time multiplexing to update the counters. I think I can see where it may be possible to emulate something like the R-Core using interval timers and software to update the counters. The PIT has the capability of generating timing events on time-outs. My point is there existing infrastructure in a GPU / CPU / peripherals that could be extended?

Hi Robert,
Thank you — these are exactly the kinds of questions I hoped people would ask.
You are correct that the single update engine in Gen1 is time-multiplexed, so the current reference implementation sacrifices throughput for compactness and very explicit, reproducible state semantics. A complete steady-state sweep of all 343 logical nodes takes 7301 FSM cycles. Gen1 is therefore a baseline implementation rather than a final high-throughput mapping.
Parallel update engines are one of the obvious scaling directions. Rows, planes, or partitions of the lattice could be processed concurrently, provided that every engine still reads only the current-state bank, writes only the next-state bank, and the new field becomes visible only after the entire global step is complete. The practical issues then become memory banking, BRAM port conflicts, neighbor/halo reads, routing, and synchronization.
On the 7×7×7 question: the storage itself can certainly be a linear array of 343 words. The important part is not the physical layout in memory but the logical adjacency relation. Node � is mapped to coordinates �, and its valid neighbors are the open-boundary subset of �, �, and �. So a linear 343-element storage array and a 7×7×7 lattice can use the same memory representation, but they are not the same dynamical system unless the same 3D neighborhood graph is preserved.
I also think your point about emulating the semantics using existing CPU/GPU or timer/event infrastructure is valuable. A semantically exact software implementation would make a useful comparison baseline, especially if it preserves the same finite-width arithmetic, sine LUT, double buffering, and global-step commit behavior.
As for applications, Gen1 is intentionally a public reference architecture rather than a finished application-specific processor. I am also experimenting with a nonlinear AI system based on a related persistent-state architecture, where an LLM is not used as the computational core. The idea is to perform computation through persistent state evolution, nonlinear interactions, structured memory, and hardware-oriented state transitions rather than through next-token prediction.
That work is still experimental, so I would rather demonstrate its behavior with reproducible tests than make broad claims about it.
Thanks again. Your experience with PITs and time-multiplexed neural systems is actually quite relevant to the questions around physical mapping and parallelization here.

on the topic of performance, it's often useful to look at that from a perspective of memory accesses.

without any cleverness, each of 343 nodes needs to read its own value and the 6 neighbour values. That's 2401 reads from present state and 1 write to next state, as well as perhaps some number of lookups in a big sin table.

if all those reads are from one memory system, that's 2401 sequential accesses.

but if you had, say, 7 banks of memory striped across the array in planes, you could get 3 reads per cycle. And therefore fewer reads per cell evaluation.

if you had some kind of local buffer which holds a few present-state values, and your evaluator accesses are appropriately ordered, you might get some extra parallelism by having some of the reads satisfied from the local buffer, which reduces the number of reads needed from the present state memory system. The simplest approach is just to hold two values: the present state of the present cell, and the present state in the cell from the forward direction. When then evaluator moves forward, both those values are in the 6+1 neighbourhood of the cell in question, so only 5 reads are needed from global memory.

If the evaluator moves diagonally, then (if my imagination serves me well) three of the neighbours of the new cell were read in the previous evaluation as neighbours of the cell then being evaluated.

Diagrams will surely be needed.

Hi Robert,
Thank you — your comments about memory access are very useful, and I think this is exactly the right way to look at the current Gen1 implementation.
One small numerical clarification: because the 7×7×7 lattice has open boundaries, not every node has six valid neighbors. The complete field contains 1764 directed neighbor relations, so a naive full sweep corresponds to 343 self-state reads plus 1764 valid neighbor reads, or 2107 logical state reads. The value 2401 is the upper bound if every node had six neighbors.
But your main point absolutely stands: a large part of the traffic is redundant if the traversal order and local buffering are designed properly.
I especially like the idea of retaining values from the previous neighborhood. Consecutive cells share part of their local neighborhood, so a streaming/windowed implementation should be able to reuse state instead of returning to global state memory for every term.
The memory-banking idea is also interesting. I would want to construct the bank-conflict schedule explicitly, because the exact gain depends on how the 3D coordinates are mapped to physical banks. A simple “seven banks” mapping may still produce collisions for some neighbor combinations, but this is exactly the kind of hardware experiment worth measuring.
A useful comparison would be:
current single-bank / single-engine baseline;
banked state memory without reuse;
banked memory plus local neighborhood buffering;
eventually, multiple update engines operating on partitions of the same field.
In all cases I would want the result to remain bit-identical to the current Gen1 transition law. The optimization should change only the physical movement of data, not the state semantics.
There is another reason I am interested in this direction.
About four months ago I was already using a related version of this persistent-state core as the basis of an experimental nonlinear AI system in which an LLM is not the computational core. The idea is to perform computation through persistent state evolution, nonlinear interaction, structured memory and state transitions rather than through next-token prediction.
While working on that system I also arrived at several storage and reconstruction ideas. One of them became a separate technology that I call V-PACK, for which I have filed a patent application.
V-PACK is not simply “compress a byte stream harder.” The basic idea is that if part of a machine state can be deterministically reconstructed from a compact canonical representation, a reconstruction profile, parameters and only the necessary residual or exception data, then it may not be necessary to store every derived state explicitly.
That is particularly interesting for persistent-state machines, because the amount of state that is logically available does not necessarily have to be equal to the amount of state that is physically materialized at one moment.
In a later architecture — what I am currently treating as Generation 9 — I plan to investigate integrating this kind of representation/reconstruction mechanism much more directly into the core itself, rather than treating memory purely as an external storage layer.
So your questions about memory bandwidth, local reuse and banking are very relevant to where I am going. I am trying to separate three things:
what state must physically exist now;
what state can remain persistent but inactive;
what state can be deterministically reconstructed when required.
That is why I think the memory architecture may eventually become just as important as the nonlinear update engine itself.
Thanks again. Your comments give me a concrete hardware optimization direction to test rather than just speculate about.

Yes, boundaries complicate things a little.

(I'm Ed, by the way, not Robert!)

There are a couple of tricks used in Game of Life engines which might be applicable. If your engine evaluates a patch of nodes, the boundary of the patch is not as big as it would be, because of adjacency. Also, when the engine moves to the next patch, it already has some of the information it needs.

For example, a 2x2 patch of nodes has 4+4+2+2+2+2 neighbours. The four nodes individually have 24 neighbours but the patch only 16. If the next patch is face-adjacent to the previous, then the four node values become neighbours, four of the neighbours become the nodes, and only 4+2+2+2+2 new node values need to be fetched. That's 12 fetches instead of 16 or 24.

Another possible limitation is how many sine lookups are needed, and how often. You might do well to duplicate or replicate the sin table.

Another possible limitation is the number of multiplies and additions are needed. How many multipliers can you engage, in parallel?

There's always a bottleneck, of course. But you reduce the ones you can reduce.

Hi RUBEN,

Would the typical AI system have a correlation between the number of dimensions (order) of the lattice and space-time? Space-time being at least four dimensions, I wonder if it would help the AI to have a 7x7x7x7 lattice? I am assuming the 7x7x7 lattice is partly what allows non-linear interaction (like a 3-layer neural net). How would maps be represented in the AI memory? I think this may affect the access pattern depending on what the AI is thinking.

With each node reading from up to six adjacent nodes, it may help to have a ‘power-of-two’ lattice size. (8x8x8). The 7x7x7 strikes me as a bit weird. Also why not close the boundaries (wrap around the indexing)? The memory addresses to read from could then be easily calculated from the node number, if indexing the nodes with a counter.

I am assuming an eventual goal is to have the lattice be a window onto a much larger lattice stored in memory.
I have found DDR RAM to be very fast. In one project I worked on memory is read from DDR in 1 or 2kB blocks in about 150 clocks IIRC. (DDR controller core with 32-byte wide interface) This may be fast enough to read and cache several rows while the previous row is being worked on.

The DDR RAM interface is abstracted by the vendor’s DDR core which just takes a linear address. There is not much to allow manipulation of banks. But one may select how the linear address is mapped to banks. Writing a custom DDR RAM controller is a project in itself.

Hi Robert,

Thank you. One important clarification is that 7×7×7 is not a fixed requirement of R-Core. The lattice topology and its dimensions are intended to be configurable. It could be 5×5×5×5, 7×7×7×7, 8×8×8×8, or another geometry depending on the implementation and experiment.

I selected 7×7×7 for the current FPGA experiments mainly because the FPGA has a limited resource budget. It gives me a useful non-trivial lattice while still fitting enough of the architecture into the available logic and memory. So the number 7 should not be interpreted as a hardware limitation of the R-Core architecture itself.

The same applies to dimensionality. A fourth lattice dimension does not have to correspond directly to physical spacetime. It is simply another coordinate of interaction in the computational topology. A 4D lattice is therefore completely possible, but so are other dimensionalities and shapes.

Your 8×8×8 suggestion is therefore valid. It would indeed simplify some binary address calculations, and it would be useful as a comparison configuration. The question for me is not whether R-Core can use 8, but how different topologies behave under the same computational rules.

Boundary wrapping is also something that can be configurable. A periodic lattice is useful because every node can have the same neighbourhood, while an open lattice gives real boundaries. I do not want either behaviour to be permanently hard-wired into the architecture.

Linear RAM addressing is compatible with this. The physical memory can use a linear address while the R-Core logic interprets that address as coordinates in an N-dimensional topology. So the logical topology and the physical memory layout do not have to be the same thing.

Regarding DDR, I agree that an active lattice could potentially operate over a much larger state space stored externally. I see that as one possible scaling mechanism rather than a requirement of the core itself.

At the moment I am still testing the core on FPGA. In parallel, I am working on the physical crystal architecture — specifically how these nodes, local state, connections and topology should be laid out correctly in silicon rather than simply inheriting the structure imposed by an FPGA.

That is also why I am interested in your comments about addressing and memory organisation: the FPGA is currently the experimental platform, but it is not intended to define the final physical geometry of the processor

I will soon open source the v-pack technology on GitHub, I didn't have time to fully implement this technology into the kernel... maybe this will help you, because I see that you also encountered the limitations of FPGA. I partially implemented it into the kernel I'm just not a programmer I started 6 months ago because I see the industry is moving in the wrong direction .... I have about 9 projects and gen9 takes all my time now the codex has been working for 25 hours on testing the kernel and will work for another 9 hours... so there is no time... the problem is simply that with FPGA you have to work with binary code because the software understands only it unfortunately...