Comparison of GreenArrays Chips with TI Micropower Controllers (2010) [pdf](greenarraychips.com)
greenarraychips.com
Comparison of GreenArrays Chips with TI Micropower Controllers (2010) [pdf]
http://www.greenarraychips.com/home/documents/greg/WP003-100617-msp430.pdf
18 comments
You can purchase one gA144f18a with an easy-to-solder breakout board for 35 USD from Schmartboard:
http://schmartboard.com/schmartboard-ez-qfn-88-pins-0-4mm-pi...
http://schmartboard.com/schmartboard-ez-qfn-88-pins-0-4mm-pi...
Funny you should say that. Reminds me of this video[0] where Alan Kay, almost impolitely, tears into today's computing while talking at CMU.
[0] https://www.youtube.com/watch?v=PFc379hu--8
[0] https://www.youtube.com/watch?v=PFc379hu--8
People always complaining about the cost of the dev board or about how they can't think of a practical application. Maybe those are valid criticisms, but honestly we have something unique here, try not to dismiss it with vapid complaints. This computer and the engineering culture from which it comes is radically different. It's more efficient then anything else I've seen. Sure, it makes some things more complicated to program but makes many other things vastly simpler. It enables a level of software control that approaches the functionality of an FPGA yet retains the interactively of a fully software solution. And it's fun to program, and simple enough to understand everything about it. I wish we had more computers like them
Erlang is a high-level language ideally suited to concurrent (not parallel) computing on multiple cores.
Is there any kind of cross-over here, with GreenArrays processors? Is it feasible to have an Erlang VM running on a GA chip, and would it have any advantages over the current (typically x86) hardware?
(From the Erlang website (http://erlang.org/faq/implementations.html): "Getting Erlang to run on, say, an 8 bit CPU with 32kByte of RAM is not feasible. People successfully run the Ericsson implementation of Erlang on systems with as little as 16MByte of RAM. It is reasonably straightforward to fit Erlang itself into 2MByte of persistant storage (e.g. a flash disk).")
Another question: the computing demands of self-driving cars are somewhat self-defeating (https://www.bloomberg.com/news/articles/2017-10-11/driverles...). Isn't low-power computer vision a perfect match for GA chips...?
Is there any kind of cross-over here, with GreenArrays processors? Is it feasible to have an Erlang VM running on a GA chip, and would it have any advantages over the current (typically x86) hardware?
(From the Erlang website (http://erlang.org/faq/implementations.html): "Getting Erlang to run on, say, an 8 bit CPU with 32kByte of RAM is not feasible. People successfully run the Ericsson implementation of Erlang on systems with as little as 16MByte of RAM. It is reasonably straightforward to fit Erlang itself into 2MByte of persistant storage (e.g. a flash disk).")
Another question: the computing demands of self-driving cars are somewhat self-defeating (https://www.bloomberg.com/news/articles/2017-10-11/driverles...). Isn't low-power computer vision a perfect match for GA chips...?
No chance of that, GreenArrays processors are arrays of f18a computers - each of which only has 64 18bit words of RAM. Orders of magnitude less then Erlang requires.
I would start with the product briefs if you want to learn more: http://www.greenarraychips.com/home/documents/downindex.html
This comparison looks like bad content marketing at best. "The MSP430 family certainly includes peripheral options that current Green Array chips do not, such as flash memories and timers." => TI's 430 range peripherals is imo one of the primary use-cases.
MSP430's aren't trying to be energy efficient per operation - they are really bad at processing. What they are good at is running complex circuits/peripherals at a low total energy consumption over a long time.
The fact that they're running at 8Mhz is telling... that's far from the "low power" level. As far as I recall, you generally run using internal low-frequency RC oscillator for low power, and then just boot up the high speed crystal oscillator if you really need it.
MSP430's aren't trying to be energy efficient per operation - they are really bad at processing. What they are good at is running complex circuits/peripherals at a low total energy consumption over a long time.
The fact that they're running at 8Mhz is telling... that's far from the "low power" level. As far as I recall, you generally run using internal low-frequency RC oscillator for low power, and then just boot up the high speed crystal oscillator if you really need it.
I can't imagine the utility of low-power processors that "aren't trying to be energy efficient per operation" and are "really bad at processing" - I thought that was the whole point!
These really are completely different type of computers - I believe if you can apply the MSP430 successfully to your application then the GA144 is probably the wrong chip to use.
But what if you need real-time nano-second reaction times on many separate pins? What if you need to process a 30 Mhz signal? While controlling a display and accepting input? All at the same time?
Then you might need the GA144, which can do all those things at the same time without needing to worry about interrupts or waking up from low power sleep modes or any of the other complex mechanism computers employ to minimize power loss.
These really are completely different type of computers - I believe if you can apply the MSP430 successfully to your application then the GA144 is probably the wrong chip to use.
But what if you need real-time nano-second reaction times on many separate pins? What if you need to process a 30 Mhz signal? While controlling a display and accepting input? All at the same time?
Then you might need the GA144, which can do all those things at the same time without needing to worry about interrupts or waking up from low power sleep modes or any of the other complex mechanism computers employ to minimize power loss.
I think that malanj's point is that the article is disingenuous because it compares the Green Array chip to an MSP430 product under a set of operational conditions specifically designed to maximize the MSP430 power consumption while excluding the many advantages of the MSP430 has in features. The summary of the whitepaper even start with the line, "there are apples and oranges in this comparison."
I can't imagine the utility of low-power processors that
"aren't trying to be energy efficient per operation"
10 seconds a week running a WiFi radio, TCP/IP, SSL and all that. 604,790 seconds a week waiting for a button to be pressed. Battery powered.
If you can monitor a button on 1 microamp, and run WiFi on 60 milliamps, 50% of your battery capacity will go on sleeping and 50% on waking.
And wake-state power consumption is dominated by the radio module, so the best way to cut down on wake state power consumption is to make the wake as short as possible.
That's the other side of low power devices, and part of the the beauty of asynchronous logic, it does nothing better then anything else! Computers like the ga144 'sleep' mid instruction waiting for a pin (button) to change, consuming only gate leakage for as long as needed.
I'm not sure I see where this is used.
It's way to expensive to put into a consumer product (adding another cell is way cheaper than shaving 100uA).
For niche products (can afford a $20 uC on the BOM), development cost is non-trivial, so the excellent MSP430 documentation and support negates any advantage the GreenArray product might have.
In essence, it's too expensive for the low and high end (albeit in different units of cost) so who do they go after?
If they want to fix #2, don't use a 10 chip MOQ ($200) and charge $450 for the demo board. Hand out a few at cost to some ECE departments or at a conference and let people do cool things with your tech. Their trials an tribulations are free publicity and support material.
It's way to expensive to put into a consumer product (adding another cell is way cheaper than shaving 100uA).
For niche products (can afford a $20 uC on the BOM), development cost is non-trivial, so the excellent MSP430 documentation and support negates any advantage the GreenArray product might have.
In essence, it's too expensive for the low and high end (albeit in different units of cost) so who do they go after?
If they want to fix #2, don't use a 10 chip MOQ ($200) and charge $450 for the demo board. Hand out a few at cost to some ECE departments or at a conference and let people do cool things with your tech. Their trials an tribulations are free publicity and support material.
> the excellent MSP430 documentation and support negates any advantage the GreenArray product might have.
The advantage of the GA144 is not that it has slightly better specs. It is a completely new paradigm. This is basically a new zeppelin that can take you from one continent to another in a comparable time to a commercial flight, and you are complaining because the price of the ticket is much higher.
I do not think the point of these new chips is not make a dent in the market (either for consumer products or enthusiasts), but to show that radically different computing systems are possible. Maybe it is not directly profitable, but it surely is mind-opening.
The advantage of the GA144 is not that it has slightly better specs. It is a completely new paradigm. This is basically a new zeppelin that can take you from one continent to another in a comparable time to a commercial flight, and you are complaining because the price of the ticket is much higher.
I do not think the point of these new chips is not make a dent in the market (either for consumer products or enthusiasts), but to show that radically different computing systems are possible. Maybe it is not directly profitable, but it surely is mind-opening.
I’m not trying to complain, and I don’t disagree.
My wording is used.
If the GA144 can actually be better than existing solution, there’s thousands of engineers who would happily try it. But until GreenArray can demonstrate a compelling use case, an unmet need, something — the product won’t make it very far.
My wording is used.
If the GA144 can actually be better than existing solution, there’s thousands of engineers who would happily try it. But until GreenArray can demonstrate a compelling use case, an unmet need, something — the product won’t make it very far.
This was from 2010, so probably not a plug as much as a case study of an unusual architecture by a legend in the field.
So much of the stuff out there is just a variation on a well-worn theme. A multi-core stack machine with 18-bit words implemented in asynchronous logic[0] is definitely a road not taken. It's nice to see people sticking their necks out--especially in the space of tangibles where starting costs are usually much higher.
[0] http://worrydream.com/refs/Sutherland%20-%20Tyranny%20of%20t...
So much of the stuff out there is just a variation on a well-worn theme. A multi-core stack machine with 18-bit words implemented in asynchronous logic[0] is definitely a road not taken. It's nice to see people sticking their necks out--especially in the space of tangibles where starting costs are usually much higher.
[0] http://worrydream.com/refs/Sutherland%20-%20Tyranny%20of%20t...
Related, Chuck Moore’s 2013 strangeloop talk on greenarrays: https://www.infoq.com/presentations/power-144-chip
MSP430: Has IDE and toolchain that's familiar for people
GreenArrays: You can use our chips if you unlearn EVERYTHING YOU KNOW ABOUT SOFTWARE AND HARDWARE.
That said, it's amazing hardware
GreenArrays: You can use our chips if you unlearn EVERYTHING YOU KNOW ABOUT SOFTWARE AND HARDWARE.
That said, it's amazing hardware
Can you please not use all caps for emphasis? It's basically yelling and the site guidelines ask everyone not to: https://news.ycombinator.com/newsguidelines.html.
Sure, I can understand why GA went with 144 cores. Because of their insistence on software defined i/o, you need them. Smarter move would have been GA4+I2C allowing any number of them to be glued using their asynchronous i/o.
Whatever. Their fate is not my problem. Would have loved for them to be insanely successful.
Computing is so ing boring these days.