Over the years I have not been shy about expressing my opinions on the GA144 and the earlier SEAForth parts. But now that I’m embarking on creating my own asynchronous array processor design, I find myself facing probably the same questions that the designers of the GA144 must have had to face as well.
In years gone by, at various SVFIG meetings, I had a chance to encounter most, if not all, of the original designers of the GA144 chip. All of these individuals struck me as top-tier design engineers. So it’s always been a mystery to me how such talent could have come up with such a deficient chip design. As I hope I’ve made clear already, I believe the core architecture of the GA144 is a brilliant piece of engineering. But it never seemed that the people who made it stopped to give a single thought about how or for what you would use a chip like this. I’ve been doing embedded systems design for a decade and a half now, and there’s a lot of standard design challenges that always have to be addressed, no matter what the final intended use of your embedded processor. But when I look at the GA144’s I/O pinout, it gives absolutely no indication that the designers of the chip gave any thought at all to the kind of circuits and/or applications that such a chip might be embedded into.
The assumption I’ve worked under all of these years was that the designers of the GA144 must have faced some very severe engineering design compromises when creating this part, and that its design came down to the question of trying to make it a general-purpose processor or an application-specific processor array. Not being able to make the hard choice between one or the other of these design directions, they chose to give the GA144 a little bit of both and, as a result, ended up with a part that was good for neither of these application options.
What the GA144 wanted to be was a SOC, a system-on-a-chip processor. If you go on the web and look at the various projects that have been done using the GA144, (for example, the video in the last blog post), you’ll see that they are all using this part in the same manner you might use a SOC processor part. That being the case, the folks at GreenArrays would have been better served by placing fewer cores on the die, giving each core a little more program memory and functionality. With fewer cores on the die, that would have allowed more of the individual cells to have pin-out access to the edge of the chip. Unfortunately for the commercial success of the GA144, there is no end of SOC processors on the market already. If the GA144 was to compete in that arena, its design would have to have been quite a bit different than it is.
But now that I’m starting on my own design, I am struck by the possibility that the reason the GA144 seems to be an ASIC chip with no specific application in mind is because there was in fact no application for such a processor architecture in the first place.
The reason I started this project to build a board size equivalent of the GA144 is because I, too, am star struck by the potential for what can be done with a processor architecture based on an asynchronous array of processors. It just seems there has to be something out there that such an architecture should be uniquely good for, but the GA144’s lack of pinouts doesn’t let you imagine any designs that would take advantage of its array structure to begin with. I thought naïvely that if I could create an asynchronous array structure with all the pins brought out to the edges, that the use for such a part might then become evident. But thinking about this the last couple of weeks, I’ve run into nothing but dead ends.
Areas where you might use an array of processors like this are either in neural networks or in parallel processing applications. But neural networks are best done in software running on high-end general-purpose computer systems. And parallel processing applications, if implemented in hardware, are best done using synchronous arrays. The only advantage to an asynchronous array over a synchronous one is that individual cells only draw power when they are active, and this advantage only comes into play if most of the cells are inactive at any one time.
What this all points to, is that any application an asynchronous array might be useful for doesn’t fall into any of the standard categories that you’ll find in the literature for processor architectures. I’ve been taking advantage of my alumni privileges at UC Santa Cruz to visit the library and search the literature. So far, I have not run across any paper or proceedings that describe a process that could best be implemented in an asynchronous array of processors.
In other words, after all of these years of criticizing the GA144 and SEAForth parts, I’m now coming face-to-face with the reality that, in fact, there is no application for which these parts are uniquely suited. So my opinion is now starting to think that the GreenArrays design team must have fallen under the same spell that I have been; star struck by the potential for such an array architecture, but not having any idea about what such a processor architecture might be good for. Rather than let go of the array processor concept and focus on creating a SOC targeted design, they chose instead to adopt the “Field of Dreams” business model; that is, if you build it they will come. They did the best design they could with the resources they had and then hoped that once the chip was out there, that someone, more inspired than they, would find an application for it. But sadly, that outcome ended up not being the case.
It appears that this endeavor to build an asynchronous processor array is becoming less a design project and more of a quest for that fabled application for which such an array would be uniquely useful.
The project is thus breaking down into several aspects. The first aspect is the creation of some kind of working hardware. I’m one of those people who thinks best with their hands. It’s a lot easier for me to express my creative ideas in building a piece of working hardware than it is to just work things out in my head, and then write them down on paper.
The second aspect will be a thorough search of current and past engineering literature on the subject of processor arrays to see if anyone has done anything like this before. If this search comes up empty, then a third aspect will be to look for inspiration in any direction I can find it.