How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
The GA144 from GreenArrays is a highly novel 144 core processor that combines high performance with low power consumption. This post covers initial experiences with breadboarding the GA144 and using the Forth IDE to drive its I/O.
The GA144 comes in an 88-pin QFN package and the 144 nodes — each core is a self-contained F18A Computer with 64 18-bit words each of ROM and RAM — are arranged in an 8x18 grid. Those around the edge of the grid are equipped with I/O ranging from asynchronous serial boot, GPIO and SPI flash, through to high-speed SERDES and analogue I/O.
Forth might not be the language of choice for most embedded developers these days, but it's perhaps not surprising that this is used to program the GA144 when you consider that Forth's creator, Charles H. Moore, is co-founder of GreenArrays. The esoteric technology choices don't end there and the chip employs a clock-less, or asynchronous, processor design. Which means that a core should only draw power when doing work, and even with all 144 cores running and a peak aggregate performance of 96 billion operations/second, power consumption is only 650 milliwatts.
GreenArrays offer an evaluation board that packs two GA144 devices, USB-to-serial interfaces, SRAM, flash storage and many other useful features. But a much cheaper route to experimentation is to breadboard the device via a SchmartBoard for breakout to through-hole.
The GA144 and Schmartboard breakout
The SchmartBoard makes it possible to hand solder the QFN and the first steps are to line up the device, tape it down and apply flux.
A soldering iron with a very fine tip is then used to melt the solder which is already in the channels leading up to the chip, and to push this up to the QFN pins. Finally, the board is turned over and the combined heatsink and common ground is soldered to the paddle on the underside of the package.
An FT232R-based USB-to-serial adapter is required for communicating with the GA144 and this needs to support the 1.8v logic levels used. The configuration in the FT232R EEPROM may also needed to be updated as the GA144 uses inverted RS232 signals, and the arrayForth IDE ships with a file that can be used with the FTDI configuration utility to achieve this.
Unfortunately the IDE is Windows-only but instructions are provided for getting this up and running on Linux via Wine. This was simple enough and just required installing the Wine emulation software and configuring /dev/ttyUSB0 as a DOS com port.
The arrayForth IDE on start up
The arrayForth environment is built upon colorForth, a variant of the Forth programming language in which different colours are used to determine how words are treated, e.g. comments are in white, yellow text will be interpreted and green will be compiled. This comes preconfigured for use with the GA144 Evaluation Board and the primary serial port on this is referred to as port A. So it is necessary to check that the underlying device and port speed are correctly configured, and the easiest way to do this is to type def a-com to edit the block that contains these parameters.
Here we see that com3 will be used with a port speed of 115,200 baud.
Once confident that the serial port configuration is correct we can type 3 selftest to run the automated chip tests.
With all the tests passed the next step is to connect to one of the 144 nodes in preparation to instructing it to do something. This is done by typing host load panel followed by talk 0 500 hook upd. What this does is load the indicator panel, connect to the chip, wire path 0 to node 500 and update the display.
In the above image the green text shows that we are connected to node 500 via node 707 (which is adjacent to node 708 where the serial link terminates), and that there are 10 hops between these nodes.
Next we place the numbers 3 and 4 on the stack by typing 3 lit followed by 4 lit. At this stage it's important to point out that there are multiple Forth environments in use here: an interpreted one on the Linux/Windows host, and those provided by the F18A node targets. And what the lit word does is to remove a number from the host computer's stack and to push it onto the target node's stack.
The numbers 3 and 4 on the stack of node 500 (end two columns of the 3rd row down)
With two numbers on the stack we can then add these by typing r+. Were we to simply type”+” the IDE would attempt an operation on the host stack, and the r prefix signifies a remote operation.
The stack of node 500 with the result of the add operation
The GPIO pins of nodes 317, 500 and 715 were connected to LEDs in order to enable experimenting with I/O. The other side of the LED connected to node 500 is tied to Vcc, and is illuminated by pulling the GPIO pin low by switching to hex input and typing 20000 io r!. For weak pull-down on a GPIO pin we would type 10000 io r!, it would be driven high by typing 30000 io r! and 0 io r! sets it to high impedance.
An LED being illuminated by pulling the GPIO pin 17 of node 500 low
This barely scratches the surface of the features provided by the IDE and GA144, but does give an idea of how relatively simple it is to get up and running with these once you get past the esoteric and somewhat archaic feel of the IDE. For a far more thorough introduction it is recommended to read the documentation provided by GreenArrays.
The GA144 stands out in a world where so many processors share a similar architecture and its performance on paper is undeniably impressive. However, it may be that certain resource and development constraints mean that it doesn't find quite as much use as it might if nodes had slightly more memory and could be programmed in, say, C.
Nevertheless, the GA144 is a fascinating platform and given its fairly unique characteristics there are likely to be particular applications at which it excels. One such possibility may be in low power wireless sensor networks, with a single device being used to communicate with sensors, perform some processing and implement a software-defined radio transceiver.