Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #37188 > unrolled thread

What is greenarrays up to lately?

Back to article view | Back to comp.lang.forth

Contents

  What is greenarrays up to lately? polymorph self <jackvanc3@gmail.com> - 2015-03-11 21:54 -0700
    Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-15 14:08 -0700
      Re: What is greenarrays up to lately? hughaguilar96@gmail.com - 2015-03-15 19:10 -0700
        Re: What is greenarrays up to lately? polymorph self <jackvanc3@gmail.com> - 2015-03-16 21:58 -0700
          Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-17 12:19 -0700
            Re: What is greenarrays up to lately? Jason Damisch <jasondamisch@yahoo.com> - 2015-03-17 13:24 -0700
      Re: What is greenarrays up to lately? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-16 18:03 +0000
      Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-16 19:42 +0000
        Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-17 16:26 -0400
          Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-19 11:24 +0000
            Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 00:12 -0400
              Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-21 23:03 +0000
                Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-21 21:14 -0400
                  Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-22 00:38 -0700
                    Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-22 18:35 -0400
                      Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-22 16:18 -0700
                        Re: What is greenarrays up to lately? Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-23 01:06 +0100
                          Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-22 22:20 -0400
                            Re: What is greenarrays up to lately? Jason Damisch <jasondamisch@yahoo.com> - 2015-03-23 08:02 -0700
                              Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-23 16:13 -0400
                  Offer + Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-08 09:51 +0100
                    Re: Offer + Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-04-10 00:47 -0400
      Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-17 16:24 -0400
        Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-17 13:57 -0700
          Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-17 14:36 -0700
            Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-17 16:36 -0700
              Re: What is greenarrays up to lately? Dennis Ruffer <daruffer@gmail.com> - 2015-03-18 07:00 -0700
              Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-18 15:54 -0700
                Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-18 19:27 -0400
                Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-18 16:44 -0700
                  Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-18 20:24 -0400
                    Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-19 07:22 -0700
                      Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-19 22:20 +0000
                        Re: What is greenarrays up to lately? Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-20 00:14 +0100
                          Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 08:24 -0700
                            Re: What is greenarrays up to lately? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-20 15:30 +0000
                              Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 08:49 -0700
                                Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 09:04 -0700
                              Re: What is greenarrays up to lately? Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-20 20:32 +0100
                            Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 12:31 -0400
                            Re: What is greenarrays up to lately? Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-20 19:44 +0100
                        Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 08:20 -0700
                      Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 00:22 -0400
                        Re: What is greenarrays up to lately? Mark Wills <markwills1970@gmail.com> - 2015-03-20 03:07 -0700
                          Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 08:41 -0700
                            Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 12:49 -0400
                            Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-21 13:29 +0000
                          Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 12:43 -0400
                            Re: What is greenarrays up to lately? Jason Damisch <jasondamisch@yahoo.com> - 2015-03-20 09:48 -0700
                    Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-19 07:34 -0700
                      Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-19 13:23 -0700
                        Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 00:51 -0400
                          Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-20 21:05 -0700
                            Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-21 04:04 -0400
                              Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-21 09:16 -0700
                                Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-21 14:02 -0400
                      Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 00:39 -0400
                  Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-19 07:15 -0700
            Re: What is greenarrays up to lately? Howerd <howerdo@yahoo.co.uk> - 2015-03-18 00:09 -0700
              Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-18 00:23 -0700
              Re: What is greenarrays up to lately? lynx <rinkasu@kaze.void.null> - 2015-03-19 23:40 +0000
          Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-17 23:16 -0400
      Re: What is greenarrays up to lately? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-18 11:05 +0000
    Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-22 22:38 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#37488

JUERGEN wrote:
> Bernd, even if you disable gates from changing by gating them, you still
> have the complete clock system across the chip and the capacities have to
> be driven. I assume this is what is meant. And only by reducing the clock
> tree length this can be reduced - independent of what you stated I assume?

No, I don't think you understand how clock gating works.  This is not a gate 
at each flip-flop, this is a gate at the part of the clock tree which is 
turned off.  I.e. let's assume you have a 100 cores with a 100 DFFs each.  
So when everything is turned on, you have a tree with 10000 leaves.  When 
everything is turned off, you have a tree with 100 leaves (the clock gates), 
consuming in the order of 100 times less (realistically, a linear factor 
more, due to the fact that the wire length is bigger on the first nodes of 
the clock system).

In the days before clock gating was everywhere, the clock tree consumed 
about 30% of the overall power, and it was never off.  So between idle and 
full us, there was often just a factor 3.

Now we have clock gates everywhere, and significantly bigger factors between 
all-on and all-off.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

[toc] | [prev] | [next] | [standalone]

#37472

On Thursday, March 19, 2015 at 10:21:00 PM UTC, Jan Coombs wrote:
> On Thu, 19 Mar 2015 07:22:26 -0700 (PDT)
> JUERGEN <epldfpga@aol.com> wrote:
> > 
> > Ist seems that Wave Semiconductor is designing a product similar to Ga144 then.
> > http://www.wavesemi.com/products.html
> > A bit of competition always helps to sharpen products and ideas...
> 
> Perhaps there is a small patent gap between Chucks work and 
> Achronix's async gate array.  Google doesn't find much more:  
> 
> Clockless Programmable Logic Startup Preps Product
>   http://electronics360.globalspec.com/article/4227/clockless-programmable-logic-startup-preps-product
> 
> Leveraging FDSOI to Achieve both Low Power AND High Speed
>   http://www.soiconsortium.org/fully-depleted-soi/presentations/september-2014-fd-soi-forum/Wave%20Semi%20FDSOI%20Forum_dist.pdf
> 
> 
> 
> BTW, this claim used to be in the body of the wikipedia article at:
> 
>   http://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchronous_CPU
> 
> SEAforth Overview "... asynchronous circuit design throughout the chip. There is no central clock with billions of dumb nodes dissipating useless power. ... the processor cores are internally asynchronous themselves
> 
> Is it true?  Are Chucks chips internally asynchronous, or only asynchronous at the boundary of each processor core?
> 
> 
> Just asking, Jan Coombs. 
> -- 
> email valid, else fix dots and hyphen
> jan4clf2014@murrayhyphenmicroftdotcodotuk

Karl Fant has the patent on the asynchronous NCL, the only real world boolean logic I have seen until now.
Synthesis and technology files are there to make Boolean Logic work, as there is no time factor included, and signals through gates run at diffeent sped compared to just clock wires across the chips. I know Karl from the past at Theseus Logic. He is or was part of Wave Semiconductor. 
If I remember correctly, some of the first computers were implemented in asynchronous, so nothing new really, but difficult to test still now.
Often an asynchronous wrapper is put around some synchronous blocks to decouple them.

[toc] | [prev] | [next] | [standalone]

#37451

On 3/19/2015 10:22 AM, JUERGEN wrote:
>
> Ist seems that Wave Semiconductor is designing a product similar to Ga144 then.
> http://www.wavesemi.com/products.html
> A bit of competition always helps to sharpen products and ideas...

Lol, if you think GA gives a rat's rear about any competition, you 
haven't been paying attention.  If GA did care about competition, they 
would have paid a little attention to it when they developed the GA144. 
  In reality there is no competition when there is no market.  I don't 
know anyone who has been able to identify the market the GA144 is 
targeted to...

Also note that Wave Semi is still early on in the development process 
and is not very interested in customers like you and I.  "Deeper detail 
about Azure is available under NDA to a limited number of qualified 
customers.  Contact Wave Marketing to discuss your application and how 
it might benefit from an Azure implementation."  In other words, if you 
have *big* bucks, give us a call.  Otherwise, don't bother.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#37466

On Friday, 20 March 2015 04:22:45 UTC, rickman  wrote:
> I don't 
> know anyone who has been able to identify the market the GA144 is 
> targeted to...

I have the same problem. It seems to me that the concept is cool
but they got carried away with the number of cores. It needs:

a) Far fewer cores
b) Far more resources (ROM/RAM) per core
c) A word size that is more readily recognised (16/24/32 bit)
d) Specialised cores (or perhaps even only one core) to deal
   with getting I/O on/off the board.

8 cores would probably be enough, with, say 1K words ROM, 0.5K words RAM
and (heaven) a common memory area (multi-port) that all the cores could
access.

Oh dear. I think I just described the Parallax Propeller! Though I think
GA could probably put something together that is much faster and more
power efficient than the Propeller.

[toc] | [prev] | [next] | [standalone]

#37477

On Friday, March 20, 2015 at 10:07:47 AM UTC, Mark Wills wrote:
> On Friday, 20 March 2015 04:22:45 UTC, rickman  wrote:
> > I don't 
> > know anyone who has been able to identify the market the GA144 is 
> > targeted to...
> 
> I have the same problem. It seems to me that the concept is cool
> but they got carried away with the number of cores. It needs:
> 
> a) Far fewer cores
> b) Far more resources (ROM/RAM) per core
> c) A word size that is more readily recognised (16/24/32 bit)
> d) Specialised cores (or perhaps even only one core) to deal
>    with getting I/O on/off the board.
> 
> 8 cores would probably be enough, with, say 1K words ROM, 0.5K words RAM
> and (heaven) a common memory area (multi-port) that all the cores could
> access.
> 
> Oh dear. I think I just described the Parallax Propeller! Though I think
> GA could probably put something together that is much faster and more
> power efficient than the Propeller.

Mark, you basically describe what I was after in different words - an implementation of 8 GA1 cores in a FPGA, coupled asynchronously if you want - you are free about RAM and ROM to suit your application - even different RAM/ROM per core.

If even this will not be a good solution - why bother 

The market tells GA for a year or 2 now:  you might have an interesting chip - but in none of our applications we see an advantage using it.

If it were different, well GA would need 50 apps engs.

[toc] | [prev] | [next] | [standalone]

#37484

On 3/20/2015 11:41 AM, JUERGEN wrote:
>
> The market tells GA for a year or 2 now:  you might have an interesting chip - but...

Stop right there.  That is why they built the chip, because it was 
interesting, not because it suited any application.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#37511

On Fri, 20 Mar 2015 08:41:37 -0700 (PDT)
JUERGEN <epldfpga@aol.com> wrote:

> On Friday, March 20, 2015 at 10:07:47 AM UTC, Mark Wills wrote:
> > On Friday, 20 March 2015 04:22:45 UTC, rickman  wrote:
> > > I don't 
> > > know anyone who has been able to identify the market the GA144 is 
> > > targeted to...
> > 
> > I have the same problem. It seems to me that the concept is cool
> > but they got carried away with the number of cores. It needs:
> > 
> > a) Far fewer cores
> > b) Far more resources (ROM/RAM) per core
> > c) A word size that is more readily recognised (16/24/32 bit)
> > d) Specialised cores (or perhaps even only one core) to deal
> >    with getting I/O on/off the board.
> > 
> > 8 cores would probably be enough, with, say 1K words ROM, 0.5K words RAM
> > and (heaven) a common memory area (multi-port) that all the cores could
> > access.
> 
> 
> Mark, you basically describe what I was after in different words
> - an implementation of 8 GA1 cores in a FPGA, coupled asynchronously 
> if you want - you are free about RAM and ROM to suit your application 
> - even different RAM/ROM per core. 

Perhaps you should try the very similar, open, and proven b16 
processor core?  

You could get eight into a X02-7000 FPGA for example, with about 
3kB RAM each, and space left for some custom peripherals. (But 
nine cores might be better for symmetry) 

I've half finished a wrapper for the b16 which adds interprocessor 
links, and modified the core so that it can execute code and boot 
from an interprocessor link. 

If you really need the 18b data width, then we could also increase 
the number of instructions in each b16 fetch from three and a bit 
to three and a half. 

Would you like me to finish it, or would you be interested in 
taking over this project? 

Jan Coombs. 
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

[toc] | [prev] | [next] | [standalone]

#37482

On 3/20/2015 6:07 AM, Mark Wills wrote:
> On Friday, 20 March 2015 04:22:45 UTC, rickman  wrote:
>> I don't
>> know anyone who has been able to identify the market the GA144 is
>> targeted to...
>
> I have the same problem. It seems to me that the concept is cool
> but they got carried away with the number of cores. It needs:
>
> a) Far fewer cores
> b) Far more resources (ROM/RAM) per core
> c) A word size that is more readily recognised (16/24/32 bit)
> d) Specialised cores (or perhaps even only one core) to deal
>     with getting I/O on/off the board.

Everyone focuses on the cores.  The cores are not the problem.  Thinking 
of the F18 core the same way you think of an ARM A9 is the problem.  The 
F18 array is not marketable because they didn't do a very good job of 
integrating it into any application.

I have said before that I think of the GA144 more like an FPGA, but with 
small, fast processors rather than logic elements as the primitive 
nodes.  No one worries in an FPGA that the LUT4 logic element is being 
used as an inverter.  Don't worry about using an F18 as a wire.

The problem with the GA144 is what it can't do because the processors 
are not fast enough and they wouldn't include a hard core to do the job. 
  USB 480 Mbps or Ethernet 100 Mbps for example.  When you ask them how 
to deal with this they say to add another chip.  What chip would that 
be???  ANOTHER MCU that was designed with real world applications in 
mind and actually support the conventional I/Os in use today.  Same 
issue with the 1.8 volt I/Os and the software driven memory interface. 
They just aren't suitable for today's needs.


> 8 cores would probably be enough, with, say 1K words ROM, 0.5K words RAM
> and (heaven) a common memory area (multi-port) that all the cores could
> access.

If you add all that memory to an F18 core it would slow down since the 
memory would run slower.  I don't have a major problem with the memory. 
  It would be nice though if there were some memory blocks on the chip, 
but Chuck was designing processors, not memory.


> Oh dear. I think I just described the Parallax Propeller! Though I think
> GA could probably put something together that is much faster and more
> power efficient than the Propeller.

There is nothing magical about either chip.  What in the Propeller do 
you want to leave out?  What in the GA144 do you want to retain?  No 
free lunches, make it more like the Propeller and it will loose the 
GA144 advantages.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#37483

On Friday, March 20, 2015 at 9:43:04 AM UTC-7, rickman wrote:

> There is nothing magical about either chip.  What in the Propeller do 
> you want to leave out?  What in the GA144 do you want to retain?  No 
> free lunches, make it more like the Propeller and it will loose the 
> GA144 advantages.

One must factor their program across multiple cores.  If you can't
think that way, get another chip and forget about it.

[toc] | [prev] | [next] | [standalone]

#37433

On Thursday, March 19, 2015 at 12:24:09 AM UTC, rickman wrote:
> On 3/18/2015 7:44 PM, Paul Rubin wrote:
> > JUERGEN <epldfpga@aol.com> writes:
> >> [Schmartboard] Thanks Paul, found it now, but it seems just a chip, I
> >> was expecting a minimum working system.
> >
> > Yeah, there's just the GA eval board for that.  Rickman had an interest
> > in making a simpler dev board product, but I think there was not enough
> > interest to make it worth his while.  If you want to buy a lot of them
> > then you and he should talk ;-).
> 
> Now I understand what he was complaining about.  Yes, the Schmartboard 
> device is just the chip mounted on a board, not even a very good mount 
> as they don't really provide for decoupling capacitance.  I think it was 
> a compromise between a general purposes carrier for the package size of 
> the GA144 and something actually like an eval board.  Thing is I have 
> never seen another device in that package so I suspect Schmart doesn't 
> sell many of these without a GA144.  They should have at least added caps.
> 
> 
> >> This is why I wrongly assumed that this word set would have been
> >> somewhere as a GA1 - just as simple core in SW.
> >> Anybody could then link as many as necessary and run it - look at it,
> >
> > It isn't all that simple.  Besides just interpreting the instruction
> > set, you probably want debugging and monitoring capabilities to trace
> > what's happening in the cores, you have to simulate the communication
> > on-chip and off, and you probably want to be able to perturb the timings
> > of individual cores in order to check for or debug the usual race
> > conditions and other timing faults.  Overall it's a nontrivial amount of
> > programming.  It's been done a few times in various languages.
> > Arrayforth is the one I know of that's in Forth, though the dialect is
> > apparently Colorforth.
> >
> >> at least this would be my approach, simulated in a free Forth like VFX.
> >
> > VFX isn't free, unless you count the limited evaluation version.  It's
> > very full featured and high performance though, more so than any of the
> > free Forths.  There are some other Forths that are free, though less
> > fancy than VFX.
> 
> If I understand what he is asking, I think his approach might actually 
> work.  The GA144 has 144 async nodes.  So making them async in software 
> should be entirely suitable.  Comms would be programmed just as it works 
> on the chip, write to another node and stop the simulating until the 
> word is read.
> 
> I guess the idea of single stepping gets a bit messy when the processors 
> are async.  Still, that is all in the existing simulator in a limited 
> extent.
> 
> 
> >> During simulation speed is not necessary.
> >
> > The GA144 with all nodes going at once is stupendously fast, like 1000
> > GHz adding everything up.  If your simulation is 1000x slower you're
> > doing pretty good.  That drastically affects how useful it is.  You
> > probably want to use a multicore PC running a parallel simulation,
> > complicating the software even more.  I don't know if Arrayforth Softsim
> > attempts this.
> 
> Reminds me of an airplane engine I heard about near the end of the 
> propeller days.  It had a separate turbocharger on each cylinder.  The 
> total horsepower generated by all the turbos was more than the power 
> delivered to the prop!  The GA144 is a bit like that.  Lots of MIPS, but 
> they can't be harnessed quite so literally.  So I look at it like I do 
> hardware.  I don't care if a gate is only toggling at 0.1% of it's max 
> rate.  I care if it is doing the job I need it to do.
> 
> Don't call the F18s CPUs.  Call them logic and maybe people will quit 
> worrying about keeping them running at full tilt.
> 
> 
> >> How many people on here:
> >>      Have bought a chip or a system
> >>      Have done some applications or tests with it
> >>      Are using it in a design?
> >> Is this product commercially viable and why and in which application?
> >
> > I know a few people here have bought the GA144 or its predecessor, the
> > 40 core Seaforth chip, and done things with them, including the hearing
> > aid that Rick mentioned, plus various research projects.  I don't know
> > of any products with it that have actually reached the point of being
> > manufactured and sold, but some have reached various stages of
> > development and demos.
> 
> It is entirely possible that there are GA144s being sold in products. 
> If there is an NDA GA can't tell us.  A company selling a product might 
> not want anyone to know what is inside.  If I were using the GA144 in a 
> product, I wouldn't want anyone to know.  GA is not a very sturdy 
> company and the customer might have concerns about the longevity, lol
> 
> 
> > The GA144's commercial viability I guess can only be shown by products
> > around it being shipped and we can't say that has happened til it
> > happens.  A few of us have tried to figure out ways to use it, but found
> > it had too many annoying limitations for the apps that we thought of.
> > It seems like a "version 1" product that is very interesting and has
> > cool ideas, but is not really there yet.  There has been mention of a
> > 32-bit version in the works, that may be more usable.
> 
> I'm not holding my breath that the 32 bit version will be better unless 
> they listen to the complains of what is wrong with it.  I have not seen 
> an indication that anyone really recognizes the problems with the GA144. 
>   Personally, I don't think the 18 bit word size was one of them.
> 
> -- 
> 
> Rick

Any decent Dev Board nowadays has a USB to TTL chip and the min HW interface to have a working system to communicate with the PC.
Too much ?  Well a USBto TTL cable is enough 
but to put it more bluntly: 
If a company does not supply the dev system and/or has defined a suitable market for the chip - well it will probably not fly, and it is an interesting internal research project.
And it seems not even the Forth community has done anything with it.
There were not many answers for:
> >> How many people on here:
> >>      Have bought a chip or a system
> >>      Have done some applications or tests with it
> >>      Are using it in a design?
> >> Is this product commercially viable and why and in which application?

[toc] | [prev] | [next] | [standalone]

#37439

JUERGEN <epldfpga@aol.com> writes:
> If a company does not supply the dev system and/or has defined a
> suitable market for the chip - well it will probably not fly, and it
> is an interesting internal research project.

GA sells a dev board that is priced commensurately with other
professional dev boards from the pre-Raspberry-Pi era, and that has the
features you mention.  It's certainly affordable to the engineers the
company sees as working on serious products, and I suspect some of the
cost is because of an expected support load that the user would probably
create for GA's own engineers.  The interest in an alternative board is
because the GA board is too expensive for typical hobbyists who are now
used to Arduinos and Launchpads.

>> >> How many people on here:
>> >>      Have bought a chip or a system
>> >>      Have done some applications or tests with it
>> >>      Are using it in a design?

I think the answer for the first two questions is "very few but
definitely not zero".  For the third question it might be zero: we don't
know for sure.

I myself have spent some time studying the GA documentation and writing
some untested code for it, but haven't bought hardware or run the
Windows simulator.

>> >> Is this product commercially viable and why and in which application?

There's definitely been at least one commercial project (the hearing
aid) that reached advanced development, but I don't know if it has
actually entered production or shipped to customers (or if it is even
still alive).  As Rick says, it's possible that the chip is being used
in other applications where the info isn't public or hasn't reached CLF.

Rick mentioned a potential digital oscilloscope application, and might
be interested in this:

https://www.picotech.com/support/topic14347.html

Someone mentioned it to me (I think that's the product) and according to
the person's description, it uses the Beaglebone's on-chip realtime
coprocessors to implement an oscilloscope that goes up to 100 MHz.

[toc] | [prev] | [next] | [standalone]

#37453

On 3/19/2015 4:23 PM, Paul Rubin wrote:
>
> Rick mentioned a potential digital oscilloscope application, and might
> be interested in this:
>
> https://www.picotech.com/support/topic14347.html
>
> Someone mentioned it to me (I think that's the product) and according to
> the person's description, it uses the Beaglebone's on-chip realtime
> coprocessors to implement an oscilloscope that goes up to 100 MHz.

Is that 100 MHz bandwidth or 100 MHz sample rate?  Most often any MHz 
number on such a scope project is sample rate while commercial scopes 
cite the usable bandwidth.

I believe it was when I was trying to determine the feasibility of the 
scope project that I gave up on the GA144 in general.  There are some 
gaping holes in the timing data provided for the GA144 and when I tried 
to dig a bit deeper into it I was told the info was "confidential" or 
something to that effect.  Seems if you learn the details of the timing 
it might enable you to reverse engineer the comms port design or 
something.  So you can't get detailed timing on I/O operations and so 
you can't use the I/O at close to it's max capabilities.  I was told to 
write my app and measure the performance...  lol   I guess GA 
understands the concept of shooting from the hip and if it doesn't work, 
just scrapping the design.

I shouldn't say I've given up entirely on the GA144.  As I believe I 
mentioned before there are still two projects I might try the GA144 in. 
  One is a DDS design where the GA144 could provide 5 simultaneous 
outputs which could be related signals or completely independent.  The 5 
DAC inputs could be used for clocking, synchronization or other related 
features.

The other project is a receiver app, rather an SDR (software defined 
radio) for low frequency signals.  This could be a direct to antenna 
design if I can get the input threshold stable enough.  In theory this 
could run from a very low power source such as a single AA battery or 
even scavenge power from the environment.  The GA144 might be low power 
enough to pull this off.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#37498

rickman <gnuarm@gmail.com> writes:
> Is that 100 MHz bandwidth or 100 MHz sample rate?

Hmm, I don't have any more info than what I wrote, but yeah, 100 mhz
sample rate sounds more plausible.

> there are still two projects I might try the GA144 in. One is a DDS
> design...  The other project is a receiver app, rather an SDR
> (software defined radio) for low frequency signals. 

I wonder if the BBB PRU's could be used for those.  The BBB has two
realtime coprocessors that are 32-bit RISC cores running at 200 mhz.
They have some DSP-like instructions including MAC, and have 4k of
dedicated sram per PRU plus another 4k shared between the two of them.
It's one of the BBB's attractions over the raspberry pi.

[toc] | [prev] | [next] | [standalone]

#37502

On 3/21/2015 12:05 AM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Is that 100 MHz bandwidth or 100 MHz sample rate?
>
> Hmm, I don't have any more info than what I wrote, but yeah, 100 mhz
> sample rate sounds more plausible.
>
>> there are still two projects I might try the GA144 in. One is a DDS
>> design...  The other project is a receiver app, rather an SDR
>> (software defined radio) for low frequency signals.
>
> I wonder if the BBB PRU's could be used for those.  The BBB has two
> realtime coprocessors that are 32-bit RISC cores running at 200 mhz.
> They have some DSP-like instructions including MAC, and have 4k of
> dedicated sram per PRU plus another 4k shared between the two of them.
> It's one of the BBB's attractions over the raspberry pi.

There is no reason why the BBB couldn't be used.  But that will never be 
a low power design.  Heck, I burnt out a phone charger I was using to 
power an rPi.  0.7 Amps is not enough... or more likely the phone 
charger wasn't really capable of 0.7 Amps continuously even though it 
says so.

Also, the BBB and rPi only have one analog output if I remember 
correctly.  That would require an add on card drawing more power.  A DDS 
is one of the few apps the GA144 is nearly a complete solution.  The 
only thing needed is a rate clock, a user interface and analog buffering 
for the outputs.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#37512

rickman <gnuarm@gmail.com> writes:
> There is no reason why the BBB couldn't be used.  But that will never
> be a low power design.  Heck, I burnt out a phone charger I was using
> to power an rPi.  0.7 Amps is not enough... 

Oh I see.  Yes, true.  Here are some beefier ones.  I'd probably get the
2 amp since they recommend it for the BBB.

http://www.adafruit.com/products/501    1 amp
http://www.adafruit.com/products/1995   2 amp
http://www.adafruit.com/products/1466   4 amp

> Also, the BBB and rPi only have one analog output if I remember
> correctly.  That would require an add on card drawing more power. 

Oh that's interesting.  I vaguely thought there were quite a lot of them
on the BBB and on the more recent rPi's (model B+ etc).  Could that
limitation only have been on the original Pi models?

[toc] | [prev] | [next] | [standalone]

#37517

On 3/21/2015 12:16 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> There is no reason why the BBB couldn't be used.  But that will never
>> be a low power design.  Heck, I burnt out a phone charger I was using
>> to power an rPi.  0.7 Amps is not enough...
>
> Oh I see.  Yes, true.  Here are some beefier ones.  I'd probably get the
> 2 amp since they recommend it for the BBB.
>
> http://www.adafruit.com/products/501    1 amp
> http://www.adafruit.com/products/1995   2 amp
> http://www.adafruit.com/products/1466   4 amp
>
>> Also, the BBB and rPi only have one analog output if I remember
>> correctly.  That would require an add on card drawing more power.
>
> Oh that's interesting.  I vaguely thought there were quite a lot of them
> on the BBB and on the more recent rPi's (model B+ etc).  Could that
> limitation only have been on the original Pi models?

Don't quote me on that.  I'm trying to remember, but too lazy to look it 
up.  I know the BBB has one ADC input, but I don't recall any DAC 
outputs actually.  It may have a PWM output which would not be suitable 
at all.  Or maybe the video outputs could be usurped, but I'm not sure 
they are analog either.

The point is that the GA144 has 5 ADC and 5 DAC built in which is one of 
the very nice features.  There are 5 edge cores, each with one ADC and 
one DAC built in.  I believe Chuck has said he should have put the ADC 
and the DAC in separate cores so they may do that in the next version of 
the GAxxx.

When it comes to power consumption, the GA144 can be right up there with 
any of the high end ARM processors.  But that is only with all 144 cores 
running full tilt and in any app I can think of that would never happen. 
  With the cores loafing most of the time and running full tilt only 
when needed it can be a very low power chip.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#37452

On 3/19/2015 10:34 AM, JUERGEN wrote:
> On Thursday, March 19, 2015 at 12:24:09 AM UTC, rickman wrote:
>> On 3/18/2015 7:44 PM, Paul Rubin wrote:
>>> JUERGEN <epldfpga@aol.com> writes:
>>>> [Schmartboard] Thanks Paul, found it now, but it seems just a chip, I
>>>> was expecting a minimum working system.
>>>
>>> Yeah, there's just the GA eval board for that.  Rickman had an interest
>>> in making a simpler dev board product, but I think there was not enough
>>> interest to make it worth his while.  If you want to buy a lot of them
>>> then you and he should talk ;-).
>>
>> Now I understand what he was complaining about.  Yes, the Schmartboard
>> device is just the chip mounted on a board, not even a very good mount
>> as they don't really provide for decoupling capacitance.  I think it was
>> a compromise between a general purposes carrier for the package size of
>> the GA144 and something actually like an eval board.  Thing is I have
>> never seen another device in that package so I suspect Schmart doesn't
>> sell many of these without a GA144.  They should have at least added caps.
>>
>>
>>>> This is why I wrongly assumed that this word set would have been
>>>> somewhere as a GA1 - just as simple core in SW.
>>>> Anybody could then link as many as necessary and run it - look at it,
>>>
>>> It isn't all that simple.  Besides just interpreting the instruction
>>> set, you probably want debugging and monitoring capabilities to trace
>>> what's happening in the cores, you have to simulate the communication
>>> on-chip and off, and you probably want to be able to perturb the timings
>>> of individual cores in order to check for or debug the usual race
>>> conditions and other timing faults.  Overall it's a nontrivial amount of
>>> programming.  It's been done a few times in various languages.
>>> Arrayforth is the one I know of that's in Forth, though the dialect is
>>> apparently Colorforth.
>>>
>>>> at least this would be my approach, simulated in a free Forth like VFX.
>>>
>>> VFX isn't free, unless you count the limited evaluation version.  It's
>>> very full featured and high performance though, more so than any of the
>>> free Forths.  There are some other Forths that are free, though less
>>> fancy than VFX.
>>
>> If I understand what he is asking, I think his approach might actually
>> work.  The GA144 has 144 async nodes.  So making them async in software
>> should be entirely suitable.  Comms would be programmed just as it works
>> on the chip, write to another node and stop the simulating until the
>> word is read.
>>
>> I guess the idea of single stepping gets a bit messy when the processors
>> are async.  Still, that is all in the existing simulator in a limited
>> extent.
>>
>>
>>>> During simulation speed is not necessary.
>>>
>>> The GA144 with all nodes going at once is stupendously fast, like 1000
>>> GHz adding everything up.  If your simulation is 1000x slower you're
>>> doing pretty good.  That drastically affects how useful it is.  You
>>> probably want to use a multicore PC running a parallel simulation,
>>> complicating the software even more.  I don't know if Arrayforth Softsim
>>> attempts this.
>>
>> Reminds me of an airplane engine I heard about near the end of the
>> propeller days.  It had a separate turbocharger on each cylinder.  The
>> total horsepower generated by all the turbos was more than the power
>> delivered to the prop!  The GA144 is a bit like that.  Lots of MIPS, but
>> they can't be harnessed quite so literally.  So I look at it like I do
>> hardware.  I don't care if a gate is only toggling at 0.1% of it's max
>> rate.  I care if it is doing the job I need it to do.
>>
>> Don't call the F18s CPUs.  Call them logic and maybe people will quit
>> worrying about keeping them running at full tilt.
>>
>>
>>>> How many people on here:
>>>>       Have bought a chip or a system
>>>>       Have done some applications or tests with it
>>>>       Are using it in a design?
>>>> Is this product commercially viable and why and in which application?
>>>
>>> I know a few people here have bought the GA144 or its predecessor, the
>>> 40 core Seaforth chip, and done things with them, including the hearing
>>> aid that Rick mentioned, plus various research projects.  I don't know
>>> of any products with it that have actually reached the point of being
>>> manufactured and sold, but some have reached various stages of
>>> development and demos.
>>
>> It is entirely possible that there are GA144s being sold in products.
>> If there is an NDA GA can't tell us.  A company selling a product might
>> not want anyone to know what is inside.  If I were using the GA144 in a
>> product, I wouldn't want anyone to know.  GA is not a very sturdy
>> company and the customer might have concerns about the longevity, lol
>>
>>
>>> The GA144's commercial viability I guess can only be shown by products
>>> around it being shipped and we can't say that has happened til it
>>> happens.  A few of us have tried to figure out ways to use it, but found
>>> it had too many annoying limitations for the apps that we thought of.
>>> It seems like a "version 1" product that is very interesting and has
>>> cool ideas, but is not really there yet.  There has been mention of a
>>> 32-bit version in the works, that may be more usable.
>>
>> I'm not holding my breath that the 32 bit version will be better unless
>> they listen to the complains of what is wrong with it.  I have not seen
>> an indication that anyone really recognizes the problems with the GA144.
>>    Personally, I don't think the 18 bit word size was one of them.
>>
>> --
>>
>> Rick
>
> Any decent Dev Board nowadays has a USB to TTL chip and the min HW interface to have a working system to communicate with the PC.
> Too much ?  Well a USBto TTL cable is enough

Sometimes I really don't understand what you are saying and I don't 
think it is a language barrier.  I think you write your thoughts without 
enough background for others (well, me anyway) to understand what is 
behind them.

I have several USB to TTL UART converters that only cost about $5 on 
ebay.  I can't see the issue with using one of these rather than 
demanding it be on the eval board.  The Schmartboard adapter is not 
really intended to be an "eval" board, it is just an adapter to let you 
use the GA144 in a circuit of your own design.  The point is that if you 
want to do something with the chip for a much lower cost than the GA 
eval board you can use this to cobble your own system together.

Heck, the type of board you were looking for to support an MSP430 a few 
months back was not much more than a CPU on a board with I/O pins.  That 
is what the Schmartboard product is.  If that doesn't suit you, then sorry.


> but to put it more bluntly:
> If a company does not supply the dev system and/or has defined a suitable market for the chip - well it will probably not fly, and it is an interesting internal research project.
> And it seems not even the Forth community has done anything with it.

It is not a Forth chip, why would the Forth community care about it?  It 
is an embedded processor which is being ignored by the embedded 
processing community.  It does have some potential in signal processing 
applications.  Many DSP chips are a bit limited in peripheral support 
like the GA144, but they often have much more memory.  Many DSP apps 
need lots of memory.


> There were not many answers for:
>>>> How many people on here:
>>>>       Have bought a chip or a system
>>>>       Have done some applications or tests with it
>>>>       Are using it in a design?
>>>> Is this product commercially viable and why and in which application?

Yep, not many answers... did you really expect much more?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#37431

On Wednesday, March 18, 2015 at 11:44:50 PM UTC, Paul Rubin wrote:
> JUERGEN <epldfpga@aol.com> writes:
> > [Schmartboard] Thanks Paul, found it now, but it seems just a chip, I
> > was expecting a minimum working system.
> 
> Yeah, there's just the GA eval board for that.  Rickman had an interest
> in making a simpler dev board product, but I think there was not enough
> interest to make it worth his while.  If you want to buy a lot of them
> then you and he should talk ;-).  
> 
> > This is why I wrongly assumed that this word set would have been
> > somewhere as a GA1 - just as simple core in SW.
> > Anybody could then link as many as necessary and run it - look at it,
> 
> It isn't all that simple.  Besides just interpreting the instruction
> set, you probably want debugging and monitoring capabilities to trace
> what's happening in the cores, you have to simulate the communication
> on-chip and off, and you probably want to be able to perturb the timings
> of individual cores in order to check for or debug the usual race
> conditions and other timing faults.  Overall it's a nontrivial amount of
> programming.  It's been done a few times in various languages.
> Arrayforth is the one I know of that's in Forth, though the dialect is
> apparently Colorforth.
> 
> > at least this would be my approach, simulated in a free Forth like VFX.
> 
> VFX isn't free, unless you count the limited evaluation version.  It's
> very full featured and high performance though, more so than any of the
> free Forths.  There are some other Forths that are free, though less
> fancy than VFX.
> 
> > During simulation speed is not necessary. 
> 
> The GA144 with all nodes going at once is stupendously fast, like 1000
> GHz adding everything up.  If your simulation is 1000x slower you're
> doing pretty good.  That drastically affects how useful it is.  You
> probably want to use a multicore PC running a parallel simulation,
> complicating the software even more.  I don't know if Arrayforth Softsim
> attempts this.
> 
> > How many people on here:
> >     Have bought a chip or a system
> >     Have done some applications or tests with it
> >     Are using it in a design?
> > Is this product commercially viable and why and in which application?
> 
> I know a few people here have bought the GA144 or its predecessor, the
> 40 core Seaforth chip, and done things with them, including the hearing
> aid that Rick mentioned, plus various research projects.  I don't know
> of any products with it that have actually reached the point of being
> manufactured and sold, but some have reached various stages of
> development and demos.
> 
> The GA144's commercial viability I guess can only be shown by products
> around it being shipped and we can't say that has happened til it
> happens.  A few of us have tried to figure out ways to use it, but found
> it had too many annoying limitations for the apps that we thought of.
> It seems like a "version 1" product that is very interesting and has
> cool ideas, but is not really there yet.  There has been mention of a
> 32-bit version in the works, that may be more usable.

I think I just give up for 2015. Thanks for all the inputs.

[toc] | [prev] | [next] | [standalone]

#37374

On Tuesday, 17 March 2015 21:36:54 UTC, Paul Rubin  wrote:
> JUERGEN <epld....@aol.com> writes:
> >> The hardware is not expensive.  I have two or three GA144 chips on 
> >> boards from http://www.schmartboard.com/ 
> > Sorry Rick, Is there a link that works? I used yours and it got me
> > nowhere useful, sorry. No GA, no price.
> 
> http://www.schmartboard.com/index.asp?page=products_csp&id=532
> 
> > Which Simulators in Forth are there - sorry - no links again  - no
> > info. 
> 
> I believe the arrayforth simulator is written in forth, but its source
> code is not public.  You can download a windows binary from here:
> 
> http://www.greenarraychips.com/home/support/download-02b.html

Hi Paul,

Yes - the SoftSim GA144 simulator is written in ArrayForth.
The link you gave :
http://www.greenarraychips.com/home/support/download-02b.html
is indeed a Windows binary, but when run it installs ArrayForth, and when you run the command file Okad.bat in the C:\GreenArrays\EVB001 folder you can run the simulator by typing 
softsim 
( in normal QWERTY mode, just type  softsim  and press the Enter key )

The full source is there from block 148 - you can view it by typing 
148 edit
after which you escape the world of QWERTY and ASCII, and have to use the editor keypad commands. You can press the Escape key to exit the editor.

BTW IMHO, I think the ArrayForth Windows/Native program is superb.
The executable file  Okad2-42c-pd.exe  is 38k bytes, and is a full Windows interface to the 313k colorForth file OkadWork.cf .
The OkadWork.cf file can also be run natively, and in either case uses LZ77 to decompress 1500 or more 1K colorForth blocks.

I like the fact that the GA144 development environment has the same character as the GA144 itself - small, powerful and elegant :-)
Awesome.

Best regards,
Howerd

[toc] | [prev] | [next] | [standalone]

#37375

Howerd <howerdo@yahoo.co.uk> writes:
> The full source is there from block 148 - you can view it by typing 
> 148 edit...
> I like the fact that the GA144 development environment has the same
> character as the GA144 itself - small, powerful and elegant :-)

I don't use Windows and haven't tried running Colorforth but I've looked
at some of the html dumps (the html converter utility is also in there,
written in Colorforth) on greenarrays.com and also from that github
repo.  It's just amazing--it's as if the brains that wrote it came from
another planet.  Something like those Vikings who managed to navigate
the world using nothing but a piece of magnetized rock as a GPS ;-).

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web