14 ms·

Chuck Moore's Creations

200 points by samsaga2 13y ago

tikhonj 13y ago
If you want to play around with the F18A instruction set, I wrote an emulator for it[1]. This also comes with a system to synthesize F18A code with MCMC, using the basic technique from the Stochastic Superoptimization[2] paper. Additionally, there is an interesting project I worked on with several other people to make writing code for GreenArrays more accessible[3]. This includes a system for synthesizing and verifying F18A code using two different solvers (Z3 and Sketch[4]) as well as a system for automatically partitioning and laying out code over the different cores. It's a work in progress, but well worth a look. [1]: http://hackage.haskell.org/package/array-forth http://hackage.haskell.org/package/array-forth, https://github.com/TikhonJelvis/array-forth https://github.com/TikhonJelvis/array-forth [2]: http://cs.stanford.edu/people/eschkufz/research/asplos291-schkufza.pdf http://cs.stanford.edu/people/eschkufz/research/asplos291-sc... [3]: http://www.forth.org/svfig/kk/11-2012-Bodik.pdf http://www.forth.org/svfig/kk/11-2012-Bodik.pdf [4]: https://github.com/TikhonJelvis/array-forth-sketch https://github.com/TikhonJelvis/array-forth-sketch, https://bitbucket.org/gatoatigrado/sketch-frontend/wiki/Home https://bitbucket.org/gatoatigrado/sketch-frontend/wiki/Home
Semaphor 13y ago
As someone with little interest or knowledge in low level hardware, what are the advantages of this? What would you use it for? 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.
- tikhonj 13y ago
  The main advantage is that it's exceptionally power-efficient. Take a look at the chart on these slides[1] for more details. It gets this efficiency despite being manufactured with relatively outdated methods--if I'm not mistaken, it has 150nm transitors! [1]: http://www.greenarraychips.com/home/news/docs/GreenArrays-Forth-Day-2012.pdf 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.
  - jbri 13y ago
    I believe the big reason for the power-efficiency is that it's entirely clockless - the power consumption of an idle transistor is very low compared to one that's switching, and a central clock causes many, many transistors to switch every clock cycle. Being clockless is another way to only pay the power cost for silicon that's actually doing something. 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.
    - tubs 13y ago
      While this is somewhat true, it becomes less relevant over time. As transistor size shrinks, leakage and static power loss becomes more and more of an issue. http://www.ruf.rice.edu/~mobile/elec518/readings/DevicesAndCircuits/kim03leakage.pdf 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. http://apt.cs.manchester.ac.uk/projects/processors/amulet/ http://apt.cs.manchester.ac.uk/projects/processors/amulet/
      - hershel 13y ago
        Due to leakage current , for some types of applications it doesn't make sense to make the transistor size shrink. For example , energy micro, one of the leaders in low power microcontrollers use the very old 130nm process, same as those FA18A chips.
  - gjm11 13y ago
    What that chart reports is, in effect, energy per instruction executed. By that metric, the GA144 indeed does extremely well. But not all instructions are equal, and it's far from obvious what the right conversion factor is between F18A instructions and, say, ARM instructions. 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.
- VLM 13y ago
  The other answers are good/interesting, but did not cover the software. This hardware is optimized for Forth. Much like the C language is pretty much oriented around the available addressing modes of a classic PDP-11, this hardware is really good at forth. 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.
- jmpe 13y ago
  For embedded problems where speed/energy is a tradeoff you can't make. Then you start looking at solving it with parallelization. Take this straight forward camera sensor: https://www.sparkfun.com/products/retired/8668 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.
  - zwieback 13y ago
    So true, especially for the hobbyist. If you're big enough the chip vendor will build a custom combination for you but everyone else has to pick from the available tiers. Luckily, if power not price is the main issue you can typically clock down or disable portions of most modern microcontrollers.
jnbiche 13y ago
Amazing architecture; I remember reading about it and colorforth several years ago when I was researching parallel architectures. I almost want to buy a chip and mount it on a schmartboard, but I've got so much going on right now that I know it would probably sit there after that. The real reason for my comment, however, is a question: is that idiomatic F#? If so, I like it! It's got a lot of Haskell's succinctness, power, and functional goodness without becoming a tangled mess of indecipherable symbols. Yes, you can write Haskell this way, but in my experience, almost no one does. If this is typical for F#, it deserves a (very close) look. Add to that the fact that I was impressed with the readability and power of a bit of C# code the other day. I really got to give these MS languages another chance. It's too bad I can't stand the OS (and yes, I've tried Windows 8 -- even worse). How's Mono these days?
- xmonkee 13y ago
  Well F# is basically ML.net so why not check out OCaml? Same language, and no windows required.
  - ygra 13y ago
    F# runs perfectly fine on Mono. No Windows required there, either.
    - deleted 13y ago
      [deleted]
  - profquail 13y ago
    F# is an ML implementation for .NET; being an ML-based lanaguage, it shares many similarities with OCaml, but as I pointed out yesterday, it is definitely not the same thing as OCaml: https://news.ycombinator.com/item?id=6660947 https://news.ycombinator.com/item?id=6660947
  - bunderbunder 13y ago
    Basically, yes. But in detail, "F# is basicall ML.net" is about as useful a language summary as "Objective-C is basically C++.mac". Despite the common heritage, the two feel quite different once you sit down and spend some time with them. And seriously, this "the Common Language Runtime is only available on Windows" trope needs to die. Mono's been around for. . . what, a decade now? Something like that.
femto 13y ago
The fun thing is that you can buy a 10 pack of chips off the GreenArrays website for $200.
Cthulhu_ 13y ago
I was at Chuck Moore's talk at Strangeloop, it was... esoteric. From what I gather, it's not really something you'd want to write a full application in - Forth came across to me as a very low-level language, much like assembler. Which makes sense given how the chip executes it natively. also the dude did not wear shoes.
- david927 13y ago
  From the article: In his talk, Chuck Moore was wearing his FiveFinger shoes on stage. That cracked me up. Absolutely no convention is followed blindly by this guy. You call it esoteric; I call it thinking in revolutionary terms rather than evolutionary terms. I think it's brilliant. Also, that "dude" is Chuck Moore.
- davidw 13y ago
  > also the dude did not wear shoes. I have a recollection of Simon Peyton Jones taking off his sandals before a talk. Wonder if it's a language guy thing.
  - cturner 13y ago
    I saw Richard Stallman give a talk while rubbing ointment into his feet. And when I was at high school looking around my prospective uni, I got help from most of my questions from a random bearded guy in the compsci building who was wearing socks and sandals. He turned out to be the professor specialising in programming paradigms / AI.
    - petercooper 13y ago
      Try Richard Stallman eating something he picked off his feet: http://coub.com/view/14ua0go http://coub.com/view/14ua0go
- csmuk 13y ago
  Forth is actually pretty high level. You just have to get there first by building up the abstractions. You can end up with an almost Ruby/Python like language on top of it if you want. But you probably won't want that after using Forth for a bit and will end up writing DSL's for your programming concerns. The use case I had for Forth was a PLC-like controller. You ended up describing the configuration in Forth by the time the abstraction was built. Example for a simple "virtual relay" controlled light switch taht turns two separate circuits on and off in a ladder: bob relays 0 switch inports 1 light1 2 light2 outports switch inport bob coil ladder bob contact begin light1 outport light2 outport logical-and ladder plc Was awesome. Unfortunately I don't have rights to the source. It ran on a Z80 board.
STRML 13y ago
I would love to see this video. The only link I could find [1], unfortunately, was behind an auth wall restricted only to attendees of the event. Does anyone know where it might be found? 1. http://www.infoq.com/presentations/power-144-chip?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=StrangeLoop2013 http://www.infoq.com/presentations/power-144-chip?utm_source...
- astrobe_ 13y ago
  There's some on youtube in the manufacturer's channel, Greenarray. https://www.youtube.com/watch?v=NK1zlz67MjU https://www.youtube.com/watch?v=NK1zlz67MjU Also maybe try the designer's site, Chuck Moore. Google Colorforth.
- puredanger 13y ago
  The video will be released for all in the next couple weeks.
be5invis 13y ago
I saw a RMBP installed Windows while using the native resolution (2880x1800). Maybe he needs more area instead of neater display. Screen area is extremely important for an electronic engineer.
yiedyie 13y ago
Sounds like the future if just for the low-power. « 144-core asynchronous chip that needs little energy (7 pJ/inst). Idle cores use no power (100 nW). Active ones (4 mW) run fast (666 Mips), then wait for communication (idle).»
- david927 13y ago
  You're right -- it sounds like the future for several reasons. I can't wait to get my hands on an eval board. Why is it that if I have to list the three or four people doing the most to break new ground in our industry, they're all over 60? Chuck Moore is 75 and he's doing this.
  - kahunamoore 13y ago
    Here is a sample application note detailing an integration with the TI SensorTag: http://www.greenarraychips.com/home/documents/greg/AN012-130606-SENSORTAG.pdf http://www.greenarraychips.com/home/documents/greg/AN012-130...
deleted 13y ago
[deleted]
acegopher 13y ago
If you are interested in a more "conventional" Forth chip, check out the J1[1]. It's 200 lines of verilog, so you can put it on an FPGA pretty easily. But it's even easier than that because the J1 is the basis of the Gameduino[2]. The Gameduino is a shield for Arduino that gives you a VGA interface, sprites, and graphics. [1]: http://www.excamera.com/sphinx/fpga-j1.html http://www.excamera.com/sphinx/fpga-j1.html [2]: http://excamera.com/sphinx/gameduino/ http://excamera.com/sphinx/gameduino/
sehugg 13y ago
The F18A reference doc is amazingly concise; all you need to know about the architecture in about 10 pages. http://www.greenarraychips.com/home/documents/greg/DB001-110412-F18A.pdf http://www.greenarraychips.com/home/documents/greg/DB001-110... (PDF)
teddyknox 13y ago
How is this different from CUDA?
conjecTech 13y ago
I've had two separate people tell me about forth and green arrays this past week. My interest in piqued. Someone please point me in the direction of a good introduction to the language and its merits.
- Procrastes 13y ago
  This is a nice, concise overview: http://cs.earlham.edu/~stoneda/cs71/ http://cs.earlham.edu/~stoneda/cs71/ Why Forth: http://bernd-paysan.de/why-forth.html http://bernd-paysan.de/why-forth.html
lambda 13y ago
So, I'm actually looking right now for a microcontroller to run a bunch of real-time I/O that may involve a certain amount of fairly timing dependent bit-banging. I'm planning on building a pinball machine, and so need something that can take input from a couple of buttons, a bunch of switches and some sensors, and drive a bunch of solenoids, LEDs, and the like. Since I will need to do a bunch of PWM or possibly bit-banged serial protocols to drive all of the LEDs, and I want to have good real-time guarantees on input from the buttons and driving the solenoids, I'm trying to figure out what microcontroller I should use; something like a Propeller, or an FPGA, or maybe one of these, or something else entirely. Anyone have any experience with these kinds of issues? Will the GA144 be able to do some fairly timing-dependent bit-banging reliably? I notice in the docs that they say the time it takes for each instruction to execute is not fixed. How would you go about doing a timing dependent protocol on these? Is there a high-resolution timer you can poll to ensure that your transitions occur in a timely manner? Or should I bite the bullet and start learning FPGA programming?
- sehugg 13y ago
  Your solenoid response time is likely to be much, much slower than the bit-banging rate of any modern uC. A standard PIC or similar would do fine (assuming it has the I/Os you need).
  - lambda 13y ago
    For solenoids, sure, though some of them (the flipper solenoids) need to be PWMed to vary their strength; you do a full-strength pulse at the beginning to drive the flipper with a good amount of force to hit the ball, but when you hit the end of the stroke, there's a switch that tells you to switch to PWM with a low duty cycle so you avoid overheating the solenoid but can still hold the flipper up to trap the ball. So you need at least the ability to PWM that. Sure, I could probably build a little timer circuit to do that, but it would be convenient if I could just bit-bang a GPIO pin instead of building more hardware. For driving a few dozen RGB LEDs with PWM to control brightness on each of the three channels, you're very quickly going to reach the limits of what you can do with a standard PIC. Or even if not driving the LEDs directly but using something like these: http://www.adafruit.com/datasheets/WS2812.pdf http://www.adafruit.com/datasheets/WS2812.pdf you need to be able to produce a fairly high precision 800 khz serial signal with no clock. Between the number of inputs and outputs needed (lots of switches and sensors on the playfield, lots of solenoids to kick out balls and control various toys, lots of LEDs), and the high-speed output needed to drive the LEDs, I'm not sure a standard PIC is going to cut it, though I haven't actually sat down to calculate out the precise number of I/Os and speed that I'll need so I may be wrong. I'm more looking for a ballpark of what I should get a dev board for and start playing around with, I may wind up changing my mind and switching to something else later.
rthomas6 13y ago
I'd really like to see a Verilog/VHDL design of this chip to see how it works. Does anyone know if I can get that?
- Procrastes 13y ago
  It doesn't work that way. This isn't a Verilog/VHDL implementation, but instead a physical chip. Also he implemented the chip design tool in FORTH as well.
  - rthomas6 13y ago
    Okay, so how did he design the physical chip? Physical design starts with some kind of RTL, usually. Unless he mapped out the chip on a transistor level by hand, he used some kind of software to aid him in the design. If he didn't use Verilog/VHDL, I'd like to see whatever logic-level design he did make.
    - beagle3 13y ago
      He did design the physical chip, gates and all. He wrote the design software himself (supposedly, 500 lines of forth called OKAD). He uses a simpler model that is accurate enough for the process he is using. http://www.colorforth.com/vlsi.html http://www.colorforth.com/vlsi.html Everything he does is fascinating, but don't expect any of it to be useful unless you are, in fact, Chuck Moore (perhaps Chuck Norris also gets a pass...)
VLM 13y ago
What to do with 144 cores? I just watched a video last week about a guy doing SDR to monitor wireless tire pressure transmitters. Every car sold since 2010-ish has at least four of them, each with a unique 32 bit ID, for police tracking purposes, err, to "save the children" or whatever BS. Anyway the complaint was there are 127 or 121 or some prime number of different algorithms from different mfgrs so you need to run 120-something decoders to completely decode each protocol. This is a pain with a single core laptop. But with a 144 core forth chip I think giving each precisely one protocol to decode in parallel would be fine.
Procrastes 13y ago
I live in Northern California near Chuck Moore. He came and spoke at our office last week and showed off the new GreenArrays architecture. Afterwards we were trying to come up with things to disrupt with a super low power / massively parallel chip like that. The problem he brought up is that in products like smart phones the power usage is in the display and the radio. So there isn't much savings in a lower power processor. But... After the discussion several of us wondered about electronic ink signage. With the Green Arrays stuff you could definitely be completely solar powered. It would also make an interesting Personal Area Network central control unit for Quantified Self stuff using harvested energy. I would support a kickstarter for either of those, but I'm not going to pursue them myself right now. Green Arrays: http://www.greenarraychips.com/ http://www.greenarraychips.com/
pointfree 13y ago
Why the change to an uninformative title from 'A CPU with 144 "tiny" computers, without clock and 5-bit instructions'?

200 points by samsaga2 13y ago

If you want to play around with the F18A instruction set, I wrote an emulator for it[1]. This also comes with a system to synthesize F18A code with MCMC, using the basic technique from the Stochastic Superoptimization[2] paper. Additionally, there is an interesting project I worked on with several other people to make writing code for GreenArrays more accessible[3]. This includes a system for synthesizing and verifying F18A code using two different solvers (Z3 and Sketch[4]) as well as a system for automatically partitioning and laying out code over the different cores. It's a work in progress, but well worth a look. [1]: http://hackage.haskell.org/package/array-forth http://hackage.haskell.org/package/array-forth, https://github.com/TikhonJelvis/array-forth https://github.com/TikhonJelvis/array-forth [2]: http://cs.stanford.edu/people/eschkufz/research/asplos291-schkufza.pdf http://cs.stanford.edu/people/eschkufz/research/asplos291-sc... [3]: http://www.forth.org/svfig/kk/11-2012-Bodik.pdf http://www.forth.org/svfig/kk/11-2012-Bodik.pdf [4]: https://github.com/TikhonJelvis/array-forth-sketch https://github.com/TikhonJelvis/array-forth-sketch, https://bitbucket.org/gatoatigrado/sketch-frontend/wiki/Home https://bitbucket.org/gatoatigrado/sketch-frontend/wiki/Home

Semaphor 13y ago

As someone with little interest or knowledge in low level hardware, what are the advantages of this? What would you use it for? 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.

tikhonj 13y ago
The main advantage is that it's exceptionally power-efficient. Take a look at the chart on these slides[1] for more details. It gets this efficiency despite being manufactured with relatively outdated methods--if I'm not mistaken, it has 150nm transitors! [1]: http://www.greenarraychips.com/home/news/docs/GreenArrays-Forth-Day-2012.pdf 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.
- jbri 13y ago
  I believe the big reason for the power-efficiency is that it's entirely clockless - the power consumption of an idle transistor is very low compared to one that's switching, and a central clock causes many, many transistors to switch every clock cycle. Being clockless is another way to only pay the power cost for silicon that's actually doing something. 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.
  - tubs 13y ago
    While this is somewhat true, it becomes less relevant over time. As transistor size shrinks, leakage and static power loss becomes more and more of an issue. http://www.ruf.rice.edu/~mobile/elec518/readings/DevicesAndCircuits/kim03leakage.pdf 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. http://apt.cs.manchester.ac.uk/projects/processors/amulet/ http://apt.cs.manchester.ac.uk/projects/processors/amulet/
    - hershel 13y ago
      Due to leakage current , for some types of applications it doesn't make sense to make the transistor size shrink. For example , energy micro, one of the leaders in low power microcontrollers use the very old 130nm process, same as those FA18A chips.
- gjm11 13y ago
  What that chart reports is, in effect, energy per instruction executed. By that metric, the GA144 indeed does extremely well. But not all instructions are equal, and it's far from obvious what the right conversion factor is between F18A instructions and, say, ARM instructions. 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.
VLM 13y ago
The other answers are good/interesting, but did not cover the software. This hardware is optimized for Forth. Much like the C language is pretty much oriented around the available addressing modes of a classic PDP-11, this hardware is really good at forth. 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.
jmpe 13y ago
For embedded problems where speed/energy is a tradeoff you can't make. Then you start looking at solving it with parallelization. Take this straight forward camera sensor: https://www.sparkfun.com/products/retired/8668 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.
- zwieback 13y ago
  So true, especially for the hobbyist. If you're big enough the chip vendor will build a custom combination for you but everyone else has to pick from the available tiers. Luckily, if power not price is the main issue you can typically clock down or disable portions of most modern microcontrollers.

jnbiche 13y ago

Amazing architecture; I remember reading about it and colorforth several years ago when I was researching parallel architectures. I almost want to buy a chip and mount it on a schmartboard, but I've got so much going on right now that I know it would probably sit there after that. The real reason for my comment, however, is a question: is that idiomatic F#? If so, I like it! It's got a lot of Haskell's succinctness, power, and functional goodness without becoming a tangled mess of indecipherable symbols. Yes, you can write Haskell this way, but in my experience, almost no one does. If this is typical for F#, it deserves a (very close) look. Add to that the fact that I was impressed with the readability and power of a bit of C# code the other day. I really got to give these MS languages another chance. It's too bad I can't stand the OS (and yes, I've tried Windows 8 -- even worse). How's Mono these days?

xmonkee 13y ago
Well F# is basically ML.net so why not check out OCaml? Same language, and no windows required.
- ygra 13y ago
  F# runs perfectly fine on Mono. No Windows required there, either.
  - deleted 13y ago
    [deleted]
- profquail 13y ago
  F# is an ML implementation for .NET; being an ML-based lanaguage, it shares many similarities with OCaml, but as I pointed out yesterday, it is definitely not the same thing as OCaml: https://news.ycombinator.com/item?id=6660947 https://news.ycombinator.com/item?id=6660947
- bunderbunder 13y ago
  Basically, yes. But in detail, "F# is basicall ML.net" is about as useful a language summary as "Objective-C is basically C++.mac". Despite the common heritage, the two feel quite different once you sit down and spend some time with them. And seriously, this "the Common Language Runtime is only available on Windows" trope needs to die. Mono's been around for. . . what, a decade now? Something like that.

femto 13y ago

The fun thing is that you can buy a 10 pack of chips off the GreenArrays website for $200.

Cthulhu_ 13y ago

I was at Chuck Moore's talk at Strangeloop, it was... esoteric. From what I gather, it's not really something you'd want to write a full application in - Forth came across to me as a very low-level language, much like assembler. Which makes sense given how the chip executes it natively. also the dude did not wear shoes.

david927 13y ago
From the article: In his talk, Chuck Moore was wearing his FiveFinger shoes on stage. That cracked me up. Absolutely no convention is followed blindly by this guy. You call it esoteric; I call it thinking in revolutionary terms rather than evolutionary terms. I think it's brilliant. Also, that "dude" is Chuck Moore.
davidw 13y ago
> also the dude did not wear shoes. I have a recollection of Simon Peyton Jones taking off his sandals before a talk. Wonder if it's a language guy thing.
- cturner 13y ago
  I saw Richard Stallman give a talk while rubbing ointment into his feet. And when I was at high school looking around my prospective uni, I got help from most of my questions from a random bearded guy in the compsci building who was wearing socks and sandals. He turned out to be the professor specialising in programming paradigms / AI.
  - petercooper 13y ago
    Try Richard Stallman eating something he picked off his feet: http://coub.com/view/14ua0go http://coub.com/view/14ua0go
csmuk 13y ago
Forth is actually pretty high level. You just have to get there first by building up the abstractions. You can end up with an almost Ruby/Python like language on top of it if you want. But you probably won't want that after using Forth for a bit and will end up writing DSL's for your programming concerns. The use case I had for Forth was a PLC-like controller. You ended up describing the configuration in Forth by the time the abstraction was built. Example for a simple "virtual relay" controlled light switch taht turns two separate circuits on and off in a ladder: bob relays 0 switch inports 1 light1 2 light2 outports switch inport bob coil ladder bob contact begin light1 outport light2 outport logical-and ladder plc Was awesome. Unfortunately I don't have rights to the source. It ran on a Z80 board.

STRML 13y ago

I would love to see this video. The only link I could find [1], unfortunately, was behind an auth wall restricted only to attendees of the event. Does anyone know where it might be found? 1. http://www.infoq.com/presentations/power-144-chip?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=StrangeLoop2013 http://www.infoq.com/presentations/power-144-chip?utm_source...

astrobe_ 13y ago
There's some on youtube in the manufacturer's channel, Greenarray. https://www.youtube.com/watch?v=NK1zlz67MjU https://www.youtube.com/watch?v=NK1zlz67MjU Also maybe try the designer's site, Chuck Moore. Google Colorforth.
puredanger 13y ago
The video will be released for all in the next couple weeks.

be5invis 13y ago

I saw a RMBP installed Windows while using the native resolution (2880x1800). Maybe he needs more area instead of neater display. Screen area is extremely important for an electronic engineer.

yiedyie 13y ago

Sounds like the future if just for the low-power. « 144-core asynchronous chip that needs little energy (7 pJ/inst). Idle cores use no power (100 nW). Active ones (4 mW) run fast (666 Mips), then wait for communication (idle).»

david927 13y ago
You're right -- it sounds like the future for several reasons. I can't wait to get my hands on an eval board. Why is it that if I have to list the three or four people doing the most to break new ground in our industry, they're all over 60? Chuck Moore is 75 and he's doing this.
- kahunamoore 13y ago
  Here is a sample application note detailing an integration with the TI SensorTag: http://www.greenarraychips.com/home/documents/greg/AN012-130606-SENSORTAG.pdf http://www.greenarraychips.com/home/documents/greg/AN012-130...

deleted 13y ago

[deleted]

acegopher 13y ago

If you are interested in a more "conventional" Forth chip, check out the J1[1]. It's 200 lines of verilog, so you can put it on an FPGA pretty easily. But it's even easier than that because the J1 is the basis of the Gameduino[2]. The Gameduino is a shield for Arduino that gives you a VGA interface, sprites, and graphics. [1]: http://www.excamera.com/sphinx/fpga-j1.html http://www.excamera.com/sphinx/fpga-j1.html [2]: http://excamera.com/sphinx/gameduino/ http://excamera.com/sphinx/gameduino/

sehugg 13y ago

The F18A reference doc is amazingly concise; all you need to know about the architecture in about 10 pages. http://www.greenarraychips.com/home/documents/greg/DB001-110412-F18A.pdf http://www.greenarraychips.com/home/documents/greg/DB001-110... (PDF)

teddyknox 13y ago

How is this different from CUDA?

conjecTech 13y ago

I've had two separate people tell me about forth and green arrays this past week. My interest in piqued. Someone please point me in the direction of a good introduction to the language and its merits.

Procrastes 13y ago
This is a nice, concise overview: http://cs.earlham.edu/~stoneda/cs71/ http://cs.earlham.edu/~stoneda/cs71/ Why Forth: http://bernd-paysan.de/why-forth.html http://bernd-paysan.de/why-forth.html

lambda 13y ago

So, I'm actually looking right now for a microcontroller to run a bunch of real-time I/O that may involve a certain amount of fairly timing dependent bit-banging. I'm planning on building a pinball machine, and so need something that can take input from a couple of buttons, a bunch of switches and some sensors, and drive a bunch of solenoids, LEDs, and the like. Since I will need to do a bunch of PWM or possibly bit-banged serial protocols to drive all of the LEDs, and I want to have good real-time guarantees on input from the buttons and driving the solenoids, I'm trying to figure out what microcontroller I should use; something like a Propeller, or an FPGA, or maybe one of these, or something else entirely. Anyone have any experience with these kinds of issues? Will the GA144 be able to do some fairly timing-dependent bit-banging reliably? I notice in the docs that they say the time it takes for each instruction to execute is not fixed. How would you go about doing a timing dependent protocol on these? Is there a high-resolution timer you can poll to ensure that your transitions occur in a timely manner? Or should I bite the bullet and start learning FPGA programming?

sehugg 13y ago
Your solenoid response time is likely to be much, much slower than the bit-banging rate of any modern uC. A standard PIC or similar would do fine (assuming it has the I/Os you need).
- lambda 13y ago
  For solenoids, sure, though some of them (the flipper solenoids) need to be PWMed to vary their strength; you do a full-strength pulse at the beginning to drive the flipper with a good amount of force to hit the ball, but when you hit the end of the stroke, there's a switch that tells you to switch to PWM with a low duty cycle so you avoid overheating the solenoid but can still hold the flipper up to trap the ball. So you need at least the ability to PWM that. Sure, I could probably build a little timer circuit to do that, but it would be convenient if I could just bit-bang a GPIO pin instead of building more hardware. For driving a few dozen RGB LEDs with PWM to control brightness on each of the three channels, you're very quickly going to reach the limits of what you can do with a standard PIC. Or even if not driving the LEDs directly but using something like these: http://www.adafruit.com/datasheets/WS2812.pdf http://www.adafruit.com/datasheets/WS2812.pdf you need to be able to produce a fairly high precision 800 khz serial signal with no clock. Between the number of inputs and outputs needed (lots of switches and sensors on the playfield, lots of solenoids to kick out balls and control various toys, lots of LEDs), and the high-speed output needed to drive the LEDs, I'm not sure a standard PIC is going to cut it, though I haven't actually sat down to calculate out the precise number of I/Os and speed that I'll need so I may be wrong. I'm more looking for a ballpark of what I should get a dev board for and start playing around with, I may wind up changing my mind and switching to something else later.

rthomas6 13y ago

I'd really like to see a Verilog/VHDL design of this chip to see how it works. Does anyone know if I can get that?

Procrastes 13y ago
It doesn't work that way. This isn't a Verilog/VHDL implementation, but instead a physical chip. Also he implemented the chip design tool in FORTH as well.
- rthomas6 13y ago
  Okay, so how did he design the physical chip? Physical design starts with some kind of RTL, usually. Unless he mapped out the chip on a transistor level by hand, he used some kind of software to aid him in the design. If he didn't use Verilog/VHDL, I'd like to see whatever logic-level design he did make.
  - beagle3 13y ago
    He did design the physical chip, gates and all. He wrote the design software himself (supposedly, 500 lines of forth called OKAD). He uses a simpler model that is accurate enough for the process he is using. http://www.colorforth.com/vlsi.html http://www.colorforth.com/vlsi.html Everything he does is fascinating, but don't expect any of it to be useful unless you are, in fact, Chuck Moore (perhaps Chuck Norris also gets a pass...)

VLM 13y ago

What to do with 144 cores? I just watched a video last week about a guy doing SDR to monitor wireless tire pressure transmitters. Every car sold since 2010-ish has at least four of them, each with a unique 32 bit ID, for police tracking purposes, err, to "save the children" or whatever BS. Anyway the complaint was there are 127 or 121 or some prime number of different algorithms from different mfgrs so you need to run 120-something decoders to completely decode each protocol. This is a pain with a single core laptop. But with a 144 core forth chip I think giving each precisely one protocol to decode in parallel would be fine.

Procrastes 13y ago

I live in Northern California near Chuck Moore. He came and spoke at our office last week and showed off the new GreenArrays architecture. Afterwards we were trying to come up with things to disrupt with a super low power / massively parallel chip like that. The problem he brought up is that in products like smart phones the power usage is in the display and the radio. So there isn't much savings in a lower power processor. But... After the discussion several of us wondered about electronic ink signage. With the Green Arrays stuff you could definitely be completely solar powered. It would also make an interesting Personal Area Network central control unit for Quantified Self stuff using harvested energy. I would support a kickstarter for either of those, but I'm not going to pursue them myself right now. Green Arrays: http://www.greenarraychips.com/ http://www.greenarraychips.com/

pointfree 13y ago

Why the change to an uninformative title from 'A CPU with 144 "tiny" computers, without clock and 5-bit instructions'?