I recently went back over this chip because I really want to love it. They overhauled the software so now there's no colorforth. I'm not sure that the newer software is easier to use, though! That said, the hard pill to swallow is the philosophy. Once you buy into the philosophy, the software is right in line with it. It's not a bad philosophy -- that is, that most software does more than it needs and one should just start from first principles and write the software that solves the problem and nothing else. It's just a hard one to adopt.
My objective was to make a low-cost lock-in amplifier for low temperature physics experiments. Usually you'd just buy a mid-range FPGA to do the signal processing but I was feeling spicy. We usually process signals up to 12 MHz or so, and to obey fs=fmax*4, you need to ingest 48 MSPS. I found that to multiply two words, you'd need 30 nanoseconds -- the multiply instruction implements one step of a multiply, so you need to run it in a loop. Anyway, that limits me to 1/(30 ns) = 33 MSPS of data ingestion, and almost surely it's less due to overhead. For an ICE40UP5K, a device that's $5.90 in qty 1, features DSP cells that can be clocked up to 50 MHz.
I think this may just not be the kind of problem that these processors work well on. It may be that they're optimized for instructions per joule or something. Either way, cool CPU/architecture, I love self-clocked stuff, but I just couldn't find a way to justify it for the kinds of problems I deal with.
The company itself I think is having trouble with funding. It's a bit of a chicken and egg problem -- if they could make the chip on a more modern process node, they might be able to develop something much faster, and thus more competitive with MPUs/MCUs/FPGAs. But, they admirably keep chugging along in their FORTH compound in Wyoming. I eagerly look forward to what they come up with next.
Very low energy consuption is one of the advertized features and as I understood the primary reason for no clock. When the chip is waiting for input and executes no instructions, no energy is spent, except for transistor leakage, acoording to Chuck Moore.
In his talk about this chip, he said said the future of computing is very small, very energy devices. "Computing dust", I think he said.
> I found that to multiply two words, you'd need 30 nanoseconds -- the multiply instruction implements one step of a multiply, so you need to run it in a loop. Anyway, that limits me to 1/(30 ns) = 33 MSPS of data ingestion, and almost surely it's less due to overhead.
What? While it actually takes about 100 nanoseconds, not 30 nanoseconds, for an 18-by-18-bit multiply, you can do hundreds in parallel, so it should be fine for your purposes. Am I missing something with how your numbers square up?
It’s 18 bits and 1.5 nanoseconds per +* plus overhead using a micronext. What did I miss? Also you’re assuming what I want to do is trivially parallelizable.
Roughly 1.5 nanoseconds, right, plus 2.4 for the micronext. So that's 3.8 ns * 18 is 68.4 ns, plus the time to set up the multiplication, which is about 30 ns.
Oh maybe it was that I had just unrolled it. I suppose there’s some setup involved though that I hadn’t accounted for. Either way, it’s a bit slow when it comes to DSP stuff unless you can avoid multiplications.
I've never heard of this chip or GreenArrays. It seems a bit like what Parallella was trying to go for - but again it was a situation where they just didn't get the funding. I've got a couple of the 16-core parallella boards from the same era as this article. They were hoping to have a 1024-core chip after that, but they folded. Funding is a very difficult problem for small companies in this alternative CPU space.
I've long been intrigued by Forth[1], and this chip. The $500 price for the dev board, and the $200 minimum to get the chip have long been a no-go. It's a shame that they didn't have something affordable to the average hobbyist.
[1] - I wrote Forth/2 for OS/2 long, long ago. Brian Mathewson wrote a great manual to go with it, and helped extend it.
Agreed... it's interesting but the eval board isn't $500 interesting.
Looking at rough numbers, it seems to be possible to do anywhere from a 2x2 to 5x5 grid of small RISC-V cores (with at least 2-4K of sysMEM) on an ECP5 FPGA, depending on model and softcore size, and the programming model would have a wider audience.
How do the chips not have clocks?
I really like the design of the chips only communicating with neighbors.
I love GreenArray and everything about Chuck Moore and associates. I definitely think it can be taken too far though, FORTH could use some modernization. I'm making a language in it's spirit and also trying to think what a custom hardware solution would be GitHub.com/civboot/fngi.
"One interesting experiment was using a hair
dryer to heat up the chip. As the temperature
rose, one could see the oscillation period stretch
on the oscilloscope, and then shrink again as the
dryer was removed"
In the old days there were some substantial asynchronous computers including the original (KA) PDP-10. I think the method is not used much these days. The GA144 is not really asynchronous. Each core is clocked by its own little ring oscillator, if I understand it right
The entire cpu itself _is_ the oscillator -- is one way to think of it. Calculating some boolean logic takes no clock, you just put the outputs on, and the outputs come out after some delay. If you connect 3 not gates in a ring, they will oscillate as the updated edge information propagates through each gate at some speed. Hopefully you see where this is going.
But if it takes more cycles to calculate the output than input it into the system, wouldn't you have a problem?
Others mentioned that they each have their own ring oscillator and that makes more sense. There is no _central_ clock, and each core has it's own memory. This also would mean there's no central bus. It's an intriguing design, I'm not totally sure I'm sold, but it definitely reduces some complexity.
If something stalls then everything else behind it stalls or stuff behind it diverts stuff elsewhere. There’s signals for the data being available and signals for being able to accept data and such things.
Although... you can do anything in FORTH with sufficient knowledge of the interpreter, even write C syntax which gets compiled to forth-like words inline, so I'm not really sure what _isnt_ FORTH :)
My objective was to make a low-cost lock-in amplifier for low temperature physics experiments. Usually you'd just buy a mid-range FPGA to do the signal processing but I was feeling spicy. We usually process signals up to 12 MHz or so, and to obey fs=fmax*4, you need to ingest 48 MSPS. I found that to multiply two words, you'd need 30 nanoseconds -- the multiply instruction implements one step of a multiply, so you need to run it in a loop. Anyway, that limits me to 1/(30 ns) = 33 MSPS of data ingestion, and almost surely it's less due to overhead. For an ICE40UP5K, a device that's $5.90 in qty 1, features DSP cells that can be clocked up to 50 MHz.
I think this may just not be the kind of problem that these processors work well on. It may be that they're optimized for instructions per joule or something. Either way, cool CPU/architecture, I love self-clocked stuff, but I just couldn't find a way to justify it for the kinds of problems I deal with.
The company itself I think is having trouble with funding. It's a bit of a chicken and egg problem -- if they could make the chip on a more modern process node, they might be able to develop something much faster, and thus more competitive with MPUs/MCUs/FPGAs. But, they admirably keep chugging along in their FORTH compound in Wyoming. I eagerly look forward to what they come up with next.