edit: Just to clarify, with little interest I mean little interest in acquiring in-depth knowledge about it. I'm still interested in hearing about advances like this and their uses.
[1]: http://www.greenarraychips.com/home/news/docs/GreenArrays-Fo...
My understanding is that it's power efficient because the stack-based design allows you to transfer very little data in and out of registers. Additionally, the chip is very simple, has very few transistors and no clock. All this helps save power. Also, the cores can power down very quickly when they're not used, meaning you only pay the energy cost of the ones you are using at the moment. Of course, you shouldn't take my word for it: I'm desperately not a hardware person.
I've heard several compelling ideas for using these chips. They're a good fit for small, simple devices that need a long battery life: things like sensors in everyday goods and such, think "internet of things". Another possibility is using them in phones so that the main, power-hungry chip could go to sleep leaving a chip like this to monitor inputs and awaken the phone if needed.
Another thing I've been looking at it for is that the design makes it very easy to bit-bang protocols - if you can't get an off-the-shelf chip to speak a protocol for you, using one of these is far cheaper than sticking an FPGA in there, and is similarly cheaper (and easier to patch later) than getting a custom chip unless you're doing a truly massive run of devices.
http://www.ruf.rice.edu/~mobile/elec518/readings/DevicesAndC...
AMULET was an attempt to make a commercial async chip and it flopped pretty early, one of the reasons being interfacing with anything else in the entire world kinda requires a clock.
For example , energy micro, one of the leaders in low power microcontrollers use the very old 130nm process, same as those FA18A chips.
My guess (based on pure industrial-grade ignorance) is that about half the gap between the GA144 and, say, the ARM Cortex-A9, would go away if you corrected for the difference in useful work done per instruction.
The GA144 still comes out looking good even if that's so. But in that chart it looks miraculous and I think that's a bit of an illusion.
I think it is a mistake to compare the GA144 to an ARM. They are not really designed for the same sorts of tasks. There are big ARMs for large memory apps which the GA144 is entirely unsuited to and there are small ARMs with more limited memory that have no where near the power of the GA144. But then the GA144 with all processors running flat out uses power like the big ARM... so where is the right comparison?
I compare the GA144 to FPGAs. The GA144 has an array of very small processors with very limited memory. But they can be viewed as very beefy logic blocks that execute sequentially rather than parallel logic. To use the GA144 for something useful you need to design your app to suit. Thinking of it as a standard CPU won't get you very far.
You won't be running a useful version of Linux on the GA144 and it is too expensive to suit toaster type apps. But it might be the right device for any number of embedded apps that need raw performance like hearing aids or other signal processing apps.
I'm not sure what the GA144 would be great at. I can find a few apps it would be good for such as a small analog I/O board I currently build and need to respin because the FPGA is EOL. But I'm not sure I would ever use the GA144 for this product because it may go EOL at any time depending on the company. They are very small and I see no sign they are getting bigger. Will they be around in 5 years, 10 years?
But what about better manufacturing technologies for the F18A chip ? first, it negates some of the advantages of working asynchronously , because the much higher leakage current. Second, the processors game was always about software tools and ecosystems, which is the weak point of the F18A, and without solving this , we won't see it in more advanced manufacturing processes.
The manufacturing process might not be up to date, but that's precisely, I believe, one of the strengths of the chip: very low power consumption with cheaper manufacturing process.
Take this straight forward camera sensor:
https://www.sparkfun.com/products/retired/8668
If you look at the datasheet, there's a control interface (I2C), various clocks and a data interface (DOUT0-7). The clock minimum is ~6 MHz, so no biggy and suited for embedded systems. Until you start to work out the details: you need to send commands, read in a hefty datastream and do something with it (like writing to storage). That means you either write out the pixels as they come in, or you buffer an entire picture (or large part) and then write it out.
The first solution means that you'll need an embedded system with a clock that has an integer amount times the minimum clock for the sensor (you need to do stuff between different moments when data comes in).
The second solution means a large amount of RAM (think order MBit).
Embedded systems never scale the way you'd like them to, typically everything scales in one go. You want more internal RAM? Well, we also scaled this and that even though you won't need it, and it's 32-bit now instead of 8- or 16-bit. You want external RAM? Well here's an IC with the extra pins and an FSMC but it also has more Flash than you'll need and it comes with USB hardware you won't need. Result: more $ per unit even though you'll only need 40% of its functionality.
There's also an additional problem: This type of control from one single-core system will mean that you're going to write very dense code loops that won't be very happy about exceptions (e.g. flash write delays).
What you need in this kind of systems is a parallel approach:
- 1 core to do the I2C (very low requirement)
- 1 core to check the timing for your output stream (straight forward logic)
- several cores to read/process/filter the incoming stream (follow the datasheet)
- several cores to store everything in temporary external RAM on the fly (lockstep)
- one or more arbiters to tie everything together (the challenging part)
An 144 core system like this would be severely underemployed for this type of camera sensor. You could scale up the sensor to very high performance cameras.
Forth is a decent embedded language because you kind of edit your source as a REPL loop, and snapshot the environment, kind of? I'm talking about classical Forth which I haven't used in a long time not the new wave stuff as linked to today. Also another nice thing about FORTH is it upshifts and downshifts in abstraction level VERY fluidly. If I had to write a I2C interface to a device and I could select any language, FORTH would certainly be the easiest / most fun. So first you write a forth word(s) to control an I2C clock pin, and the data pin. Then you write a word that speaks very basic I2C out goes a byte in comes a byte by toggling the pins appropriately. Then a word that lives on top that speaks the I2C logical protocol of addressing and bus contention and enumeration and whatever. Then a word that uses the below stuff to talk to a I2C A/D converter chip, in a generic sense. Then a word that talks to a specific A/D converter at a specific address and scales its output so decimal 1024 means +3.15 analog volts or 72.1 degrees F something. Then...
That brings up another interesting aspect of FORTH and this hardware, if you are familiar with the Propeller chip this is like a 144 cog prop, sorta. So that's one interesting way to structure separate blocks of code, run each block on separate hardware...
This isn't going to go over very well with the HN communities interest in scalability, but much like the prop, if you have N cores/cogs/cpus on chip it scales real nice up to N and then doesn't do so well at N+1. Of course you can probably organize your program to separate at hardware, so unless you have 145 peripherals (or 9 for the prop) you'd be OK. Of course that enforces a certain hardware focus and demand for a device driver oriented architecture as a tradeoff, so its hardly the universal silver bullet.
I would not suggest writing an embedded webserver that serves each page or server process from a separate piece of hardware. On the other hand writing an embedded webserver that uses one dedicated core/cpu/cog per ethernet port sounds pretty reasonable, assuming you haven't already used up all your hardware.
On the other hand if you wrote a thermostat in FORTH on a multiprocessor chip like this, you'd probably have one processor do nothing but read the HEAT/COOL/OFF switch and update the internal shared memory state of the device, and spend most of its time in low power sleep mode. To say this would be easy to test and troubleshoot would be an understatement, there's only 3 states plus maybe "switch is broken so set alert mode and default to off" or something. And another CPU that completely separately does nothing but read a temp sensor and update internal shared state periodically and spends most of its time sleeping. Repeat until you're done. With a single processor system it depends on your chosen flavor of syntactic sugar (if any) but it would be much more of an ordered list, OK now we look and see if a button was pressed, then read the temp sensor, then update the screen, then... A long schedule or to do list. Or you can use syntactic sugar to program it differently, but fundamentally the processor will still do it that way, although probably a little slower.
But on paper it appears that a cog has more power than each one of these limited cores. Plus historically the Propeller has been cheaper than most of the esoteric crazy Forth chips and implementations.
Its important for medium size runs. You make a couple things for a small vertical market, or custom, or R+D and it doesn't matter, any choice is like one hour of embedded developer salary so it doesn't matter. If you're doing huge runs of a million in China you "have to" use the cheapest thing out there, and this won't be it. I bet around 10K production runs is where part cost creeps out of salary rounding errors but isn't high enough to utterly force the use of something specifically designed to be cheap.
As far as cost goes TI and Microchip have some low power offerings where $20 for this forth chip or $12 for a propeller minus the cost of a cheap low power competitor means you can afford a larger battery in the budget. Or you could afford more "whatever" in another part of the design.