My interest in asynchronous arrays started with my interest as a physicist in cellular automata (CA) and the thermodynamics of computation. That interest then turned itself into a personal challenge to see if I could actually create hardware that would implement these ideas. It was in researching the topic of very large asynchronous arrays of simple processors that I first ran across Dave Ackley’s YouTube channel. That was several years ago, and I’ve been lurking there ever since. I was excited about his work with his Demon Horde Sort simulation. Now that he has started building actual hardware, I’m watching with interest the T2-Tile Project.
Back when I first became interested in arrays of simple processors, I read through a lot of publications on the subject. But at that time, I don’t recall reading any papers that combined the separate subjects of self-assembling and processor arrays into a single research effort.
Papers that dealt with the concept of self-assembly seemed to focus on self-assembly of electrical elements, using techniques of nano-assembly and DNA to implement this process; that is, self-assembling primitive logic elements that could then be self-assembled further into logical computational structures.
While looking at the subject of array processor IC’s and processor arrays, I found that the published research is all over the road-map. But despite the wide range of approaches found in the literature, they all still have one thing in common; that is, the array elements are the computational mechanism of the structure. This is fundamentally different than what Dave Ackley is proposing with the Movable Feast Machine (MFM). In his case, the underlying silicon electronics is not responsible for the computational action of the array structure; rather, it is the interactions of the CA-atoms that are responsible for computation. The underlying electronics is just the structure that the CA-atoms move upon and reside within.
This is the conundrum of the T2-Tile Project: the CA-atoms are running within a virtual machine, which in turn is running upon a classical computational architecture – the very design constraint that Dave is trying to get away from with his concept of Robust-First-Computing. I don’t want this to be taken as criticism; I find Dave’s work fascinating, just not complete. But then again, he is a software person, not a hardware designer. And as a hardware guy myself, I consider the work he’s done to date pretty damn good for someone whose background is not hardware to start with. What I would like to do in the coming months is to pick up where the T2-Tile Project leaves off and carry it further into the design of the underlying hardware – the complementary construction where the MFM will finally be able to become what it wants to be.
What this means, as far as hardware design goes, is that any processor element that forms the array sub-structure underneath the MFM has to be designed, not as computational element in itself, but rather for its ability to support whatever the CA-atoms are programmed to do. In other words, the CA-atoms and the underlying silicon form a symbiotic structure; you can’t design one side of the concept without designing the other side at the same time. It is for this reason I think that this area of research has never been explored; there is no research group out there that has the breadth of expertise to develop both sides of the “robust-first CA-computation” and “self-assembling processor array” combination within a single research effort.
The first step is to outline the fundamental hardware problem, so here it goes…
It is a problem I’ve run into before in hardware design; trying to take a project that ran within a virtual system, then re-cast it as an FPGA based design. It turns out that there are subtle things that virtual machines allow you to do that you can’t reproduce with hardware alone. Something that software people don’t always appreciate, but hardware designers will, is that a virtual machine can step outside of itself and take advantage of computational processes at the hardware level, that the CA running under the virtual machine can’t. The best way to illustrate this is with an example…
The reason DReg or Res can read what’s in a neighboring cell is that the virtual machine, that the MFM is running under, can take advantage of the fact that all of the data of neighboring cells is contained within the same common area in RAM. But this can’t be done within an array where each cell of the array is hardware-independent from its neighbors. In such an arrangement, each cell only knows what’s in its own memory; to find out what resides in a neighboring cell, some form of hardware interrogation must transpire. This kind of interrogation process is not contained in Dave Ackley’s core programming for the CA-atoms.
The virtual MFM machine also keeps a common library of function calls that each cell can access. The only information then that a cell needs to contain is a single 64(?) bit data string. But this feature doesn’t translate from the virtual machine environment to an array of hardware-independent processor elements either. In this case, each CA-atom has to maintain an independent local copy of all of its programming code.
That is, before we can re-create the MFM at the hardware level, a number of the functional attributes that the CA-atoms currently possess get thrown out, while other features will have to be added. That’s where the hardware design becomes challenging. Basically, short of inspired brilliance, one has to work by an iterative process of cut and try; propose a primitive computational structure for the underlying hardware elements, then try out complementary sets of instructions for the CA-atoms, run it all in simulation, and see what happens; then rinse, repeat!
