[HN Gopher] Getting Started with the GA144 and ArrayForth (2014)
___________________________________________________________________
Getting Started with the GA144 and ArrayForth (2014)
Author : todsacerdoti
Score : 58 points
Date : 2022-02-05 15:21 UTC (7 hours ago)
(HTM) web link (bitlog.it)
(TXT) w3m dump (bitlog.it)
| akkartik wrote:
| I don't see a link to the simulator at the bottom, and there's no
| mention of a simulator at
| http://www.greenarraychips.com/home/products/index.html. Do I
| need to order an evaluation kit?
| [deleted]
| vitiral wrote:
| 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.
| buescher wrote:
| > How do the chips not have clocks?
|
| That's a very good question. Asynchronous design is really
| cool, but has never gone anywhere that I know of.
|
| https://authors.library.caltech.edu/43698/1/25YearsAgo.pdf
|
| "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"
| throwaway81523 wrote:
| 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
| buescher wrote:
| I didn't know that about the KA PDP-10 nor had I looked
| that deeply into the GA144. Thanks.
| nmz wrote:
| if you change forth in any way then it probably stops being
| forth. modern forth is factor or maybe even retro.
| vitiral wrote:
| Right, hence why fngi is "in it's spirit."
|
| 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 :)
| gaze wrote:
| 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.
| vitiral wrote:
| 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.
| chj wrote:
| Is it possible to do this trick in a FPGA?
| bumbledraven wrote:
| (2014)
| dang wrote:
| Year added. Thanks!
| gaze wrote:
| 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.
| avodonosov wrote:
| 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.
| gaze wrote:
| Yeah. I think that's right. The power figures really are
| impressive. Perhaps the right point of comparison is the
| MSP430, as is done in this article http://www.greenarraychips
| .com/home/documents/greg/WP003-100...
| avodonosov wrote:
| Have you considered implementing parallel processing
| instead of the loop for your processing?
| gaze wrote:
| I've considered it. But why bother. Why work so hard to
| apply the wrong tool for the job
| daniel-cussen wrote:
| > 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?
| mikewarot wrote:
| 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.
| throwaway81523 wrote:
| It was possible (maybe still is) to buy a ga144 on a breakout
| board for $35.
|
| https://schmartboard.com/schmartboard-ez-qfn-88-pins-0-4mm-p...
| happycube wrote:
| 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.
___________________________________________________________________
(page generated 2022-02-05 23:01 UTC)