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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#38056 — Offer + Re: What is greenarrays up to lately?

On Sat, 21 Mar 2015 21:14:28 -0400
rickman <gnuarm@gmail.com> wrote:

> On 3/21/2015 7:03 PM, Jan Coombs <Jan-54 wrote:
> > On Fri, 20 Mar 2015 00:12:44 -0400
> > rickman <gnuarm@gmail.com> wrote:
> >
> >> On 3/19/2015 7:24 AM, Jan Coombs <Jan-54 wrote:
> >>> On Tue, 17 Mar 2015 16:26:53 -0400
> >>> rickman <gnuarm@gmail.com> wrote:
> >>>
> >>>> On 3/16/2015 3:42 PM, Jan Coombs <Jan-54 wrote:
> >>>>    >
> >>>>    > It's a bit more exciting if the simulation can export
> >>>>    > the design to the FPGA tools, then you are closer to
> >>>>    > having a chip.
> >>>>
> >>>> I'm not sure what that means.  What design?  The chip or the code? 

Sorry, here's two other people's description of the MyHDL 
design flow, a pretty one [1], and a professional one [2]

Offer: 

I'd like to share stack processor designs, and would be 
happy to package these so that they can be used with no 
hardware design tool knowledge. 

These can be run in simulation on a PC, or on a cheap FPGA 
development board, provided it has a USB comm port, and I 
have the tools to target and program it. 

I need to finish some work to connect the b16 or j1 tools, 
written in gforth, to the processor, so please book early 
for next winter! 

Jan Coombs.
-- 

[1] http://old.myhdl.org/doku.php/projects:python_hardware_processor
[2] http://www.jandecaluwe.com/hdldesign/digmac.html

email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

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

#38073 — Re: Offer + Re: What is greenarrays up to lately?

On 4/8/2015 4:51 AM, Jan Coombs <Jan-54 wrote:
> On Sat, 21 Mar 2015 21:14:28 -0400
> rickman <gnuarm@gmail.com> wrote:
>
>> On 3/21/2015 7:03 PM, Jan Coombs <Jan-54 wrote:
>>> On Fri, 20 Mar 2015 00:12:44 -0400
>>> rickman <gnuarm@gmail.com> wrote:
>>>
>>>> On 3/19/2015 7:24 AM, Jan Coombs <Jan-54 wrote:
>>>>> On Tue, 17 Mar 2015 16:26:53 -0400
>>>>> rickman <gnuarm@gmail.com> wrote:
>>>>>
>>>>>> On 3/16/2015 3:42 PM, Jan Coombs <Jan-54 wrote:
>>>>>>     >
>>>>>>     > It's a bit more exciting if the simulation can export
>>>>>>     > the design to the FPGA tools, then you are closer to
>>>>>>     > having a chip.
>>>>>>
>>>>>> I'm not sure what that means.  What design?  The chip or the code?
>
> Sorry, here's two other people's description of the MyHDL
> design flow, a pretty one [1], and a professional one [2]

I'm a little unclear still.  I think there is a python program to run on 
a soft core which is compiled by a python program running on a PC. 
There is also a MyHDL program which describes the soft core which the 
first python program runs on.  It is not clear where each program runs 
and how.  Further it is not clear what is simulated and where.  I 
suppose the python program for the soft core can be loaded into the 
simulated RAM of the MyHDL soft core when simulated, but I don't know 
enough about MyHDL to know if it includes a simulator or not.

Once the simulation is running correctly the entire design is converted 
to another HDL (Verilog or VHDL) and synthesized for the target device.

I'm not at all clear why this is better than the more conventional 
method of coding the target processor application in whatever language 
you want where the executable code is loaded into the target RAM for 
simulation and/or execution.  I have simulated such code in the VHDL 
simulator.  Seems simple enough to me.

I guess I don't see a problem with the existing approach.  But then I 
don't code in C or python.  I code in assembler or Forth.


> Offer:
>
> I'd like to share stack processor designs, and would be
> happy to package these so that they can be used with no
> hardware design tool knowledge.
>
> These can be run in simulation on a PC, or on a cheap FPGA
> development board, provided it has a USB comm port, and I
> have the tools to target and program it.
>
> I need to finish some work to connect the b16 or j1 tools,
> written in gforth, to the processor, so please book early
> for next winter!
>
> Jan Coombs.
>


-- 

Rick

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

#37350

On 3/15/2015 5:08 PM, JUERGEN wrote:
 > On Thursday, March 12, 2015 at 4:54:08 AM UTC, polymorph self wrote:
 >> Can anyone speak to some forth working in the field apps greenarrays 
has achieved?
 >>
 >> What kind of projects are they up to?
 >
 > It seems, not much, as the whole clf community does not know anything 
- and even Greenarrays does not care to give any comment.
 >
 > It seems that the core used in the Green Arrays Project is not 
relevant to the whole CLF community.
 >
 > I can understand that the HW is too expensive to try it out,
 > and Greenarrays does not use any of the existing SW emulations either.

The hardware is not expensive.  I have two or three GA144 chips on 
boards from http://www.schmartboard.com/  I haven't fired them up for 
lack of a truly interesting project...


 > But he existing Forth community does not take it serious, otherwise a 
simlation in Forth of the core would have been done.

I don't follow that reasoning.  Actually there have been several 
simulators produced.  I would expect the one by GA themselves was done 
in Forth although I don't know that for sure.  Someone else did one that 
was better in some regard, but I don't recall what it was.  They did a 
demo for the SVFIG monthly meeting once.  If you want to search through 
their videos or maybe contact someone there they might be able to point 
you to the right video.


 > The only guess I could have is that the military applications pay for 
the salaries of the people involved.

You don't need the military to pay salaries.  Last I heard no one takes 
a salary...  Trust me, there are no military projects using the GA144. 
GA as a company doesn't meet the minimum requirements for their devices 
being used in a military project.


 > So part of the next generation star wars - or Mars?
 > Well just guessing - it seems too many NDAs involved?

For sure no Mars projects without a *lot* more work.  To go on a space 
craft the chips have to be rad hardened.

Last I heard they had a project to produce a 32 bit version of the 
CPU... an F32 I suppose.  We'll see if they fix any of the many utility 
issues of the GA144.

-- 

Rick

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

#37356

On Tuesday, March 17, 2015 at 8:24:15 PM UTC, rickman wrote:
> On 3/15/2015 5:08 PM, JUERGEN wrote:
>  > On Thursday, March 12, 2015 at 4:54:08 AM UTC, polymorph self wrote:
>  >> Can anyone speak to some forth working in the field apps greenarrays 
> has achieved?
>  >>
>  >> What kind of projects are they up to?
>  >
>  > It seems, not much, as the whole clf community does not know anything 
> - and even Greenarrays does not care to give any comment.
>  >
>  > It seems that the core used in the Green Arrays Project is not 
> relevant to the whole CLF community.
>  >
>  > I can understand that the HW is too expensive to try it out,
>  > and Greenarrays does not use any of the existing SW emulations either.
> 
> The hardware is not expensive.  I have two or three GA144 chips on 
> boards from http://www.schmartboard.com/  I haven't fired them up for 
> lack of a truly interesting project...
> 
> 
>  > But he existing Forth community does not take it serious, otherwise a 
> simlation in Forth of the core would have been done.
> 
> I don't follow that reasoning.  Actually there have been several 
> simulators produced.  I would expect the one by GA themselves was done 
> in Forth although I don't know that for sure.  Someone else did one that 
> was better in some regard, but I don't recall what it was.  They did a 
> demo for the SVFIG monthly meeting once.  If you want to search through 
> their videos or maybe contact someone there they might be able to point 
> you to the right video.
> 
> 
>  > The only guess I could have is that the military applications pay for 
> the salaries of the people involved.
> 
> You don't need the military to pay salaries.  Last I heard no one takes 
> a salary...  Trust me, there are no military projects using the GA144. 
> GA as a company doesn't meet the minimum requirements for their devices 
> being used in a military project.
> 
> 
>  > So part of the next generation star wars - or Mars?
>  > Well just guessing - it seems too many NDAs involved?
> 
> For sure no Mars projects without a *lot* more work.  To go on a space 
> craft the chips have to be rad hardened.
> 
> Last I heard they had a project to produce a 32 bit version of the 
> CPU... an F32 I suppose.  We'll see if they fix any of the many utility 
> issues of the GA144.
> 
> -- 
> 
> Rick

Sorry Rick, Is there a link that works? I used yours and it got me nowhere useful, sorry. No GA, no price. 

Which Simulators in Forth are there - sorry - no links again  - no info. 
If you comment - please add helpful info - no grey area. 
I was asking the whole CLF community - and it seems there no relevant info.

So you are just supporting my assumption - no known projects.

As I assumed we are all guessing - no official information. Possibly NDA covered projects.

Thanks for the feedback. 
Or do we rather wait for the F64, F128 ...

My ASIC background tells me 3-6 months for masks sets, another 3 - 6 moths for chips - so we are talking 2016 / 2017.

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

#37359

JUERGEN <epldfpga@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

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

#37364

Paul Rubin <no.email@nospam.invalid> writes:
> 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

Actually the source may be here:

https://github.com/DRuffer/arrayForth

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

#37393

On Tuesday, March 17, 2015 at 4:37:01 PM UTC-7, Paul Rubin wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
> > 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
> 
> Actually the source may be here:
> 
> https://github.com/DRuffer/arrayForth

That's mine, but it's an unfinished attempt at moving arrayForth into GForth's vmgen.

Nothing to see there yet. ;(

DaR

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

#37414

On Tuesday, March 17, 2015 at 11:37:01 PM UTC, Paul Rubin wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
> > 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
> 
> Actually the source may be here:
> 
> https://github.com/DRuffer/arrayForth

Thanks Paul, found it now, but it seems just a chip, I was expecting a minimum working system. 

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,
at least this would be my approach, simulated in a free Forth like VFX.
During simulation speed is not necessary. 

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]

#37415

On 3/18/2015 6:54 PM, JUERGEN wrote:
> On Tuesday, March 17, 2015 at 11:37:01 PM UTC, Paul Rubin wrote:
>> Paul Rubin <no.email@nospam.invalid> writes:
>>> 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
>>
>> Actually the source may be here:
>>
>> https://github.com/DRuffer/arrayForth
>
> Thanks Paul, found it now, but it seems just a chip, I was expecting a minimum working system.

I can't say I understand what you are asking about.  You are asking 
about a simulator for the GA144, no?  What do you mean a "working system"?


> 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,
> at least this would be my approach, simulated in a free Forth like VFX.
> During simulation speed is not necessary.
>
> 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 have bought the GA144 soldered on a board from Schmartboard.  I have 
done nothing with it.  I thought it might make a good DDS and will 
explore that when I get around to it.  I also am interested in seeing 
just how low power I can get in a digital receiver design for a very low 
frequency, low bandwidth signal.  Two apps, no progress on either.

At one time I thought it might do a good job in a design I am currently 
using an FPGA for.  But the same reason other MCUs are not viable 
candidates excludes this chip.  It can't bit bang the 30 MHz serial port 
that is easy to do in the FPGA.  The GA144 with 144 - 700 MIPS 
processors is too slow to handle a peripheral interface.

-- 

Rick

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

#37416

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.

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

#37418

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

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

#37432

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

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...

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

#37445

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

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

#37446

 wrote:

> On Thu, 19 Mar 2015 07:22:26 -0700 (PDT)
> Is it true?  Are Chucks chips internally asynchronous, or only
> asynchronous at the boundary of each processor core?

There are a few different delay elements within each core to determine the 
speed of different operations.  So it's not a single clock per core, either.

What's clearly wrong is that a synchronous device has "billions of dumb 
nodes which dissipate useless power"; if you do synthesize your Verilog to 
save power, you'll enable the clock gating option, and then, only those 
nodes who need to actually get the clock.  Sleeping cores wouldn't.

All CPUs now, including the performance-optimized, are done that way, as 
power dissipation is the main problem with modern processes: you have to get 
that down to a reasonable value.

Chuck stopped using mainstream EDA tools in the early 90s, and his 
statements are all true for the EDA situation 20 years ago.

-- 
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]

#37473

On Thursday, March 19, 2015 at 11:14:25 PM UTC, Bernd Paysan wrote:
> wrote:
> 
> > On Thu, 19 Mar 2015 07:22:26 -0700 (PDT)
> > Is it true?  Are Chucks chips internally asynchronous, or only
> > asynchronous at the boundary of each processor core?
> 
> There are a few different delay elements within each core to determine the 
> speed of different operations.  So it's not a single clock per core, either.
> 
> What's clearly wrong is that a synchronous device has "billions of dumb 
> nodes which dissipate useless power"; if you do synthesize your Verilog to 
> save power, you'll enable the clock gating option, and then, only those 
> nodes who need to actually get the clock.  Sleeping cores wouldn't.
> 
> All CPUs now, including the performance-optimized, are done that way, as 
> power dissipation is the main problem with modern processes: you have to get 
> that down to a reasonable value.
> 
> Chuck stopped using mainstream EDA tools in the early 90s, and his 
> statements are all true for the EDA situation 20 years ago.
> 
> -- 
> 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*

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?

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

#37475

JUERGEN <epldfpga@aol.com> writes:
>Bernd, even if you disable gates from changing by gating them, you still ha=
>ve the complete clock system across the chip and the capacities have to be =
>driven.

They used that approach for the first Alpha (21064) in 1992, and the
clock used up IIRC 30% of the power of the chip, and it ran only at
200MHz.  This approach did not scale, so they introduced clock
domains, each domain with its own clock generation, fed by a common
clock, but with some possible skew wrt the clock in the next domain;
therefore pushing data across clock domains loses a cycle for every
boundary crossed.  At least that's what I gather from the explanations
why shift an multiply are slow on the original Pentium 4 (from 2001).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#37478

On Friday, March 20, 2015 at 3:37:43 PM UTC, Anton Ertl wrote:
> JUERGEN <epldfpga@aol.com> writes:
> >Bernd, even if you disable gates from changing by gating them, you still ha=
> >ve the complete clock system across the chip and the capacities have to be =
> >driven.
> 
> They used that approach for the first Alpha (21064) in 1992, and the
> clock used up IIRC 30% of the power of the chip, and it ran only at
> 200MHz.  This approach did not scale, so they introduced clock
> domains, each domain with its own clock generation, fed by a common
> clock, but with some possible skew wrt the clock in the next domain;
> therefore pushing data across clock domains loses a cycle for every
> boundary crossed.  At least that's what I gather from the explanations
> why shift an multiply are slow on the original Pentium 4 (from 2001).
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2014: http://www.euroforth.org/ef14/

There was a comparison of the sych and the asynch DLX implementation at http://www.ics.forth.gr/carv/async/demo/dlx_asic.html
It seems now to have disappeared unfortunately

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

#37479

On Friday, March 20, 2015 at 3:49:12 PM UTC, JUERGEN wrote:
> On Friday, March 20, 2015 at 3:37:43 PM UTC, Anton Ertl wrote:
> > JUERGEN <epldfpga@aol.com> writes:
> > >Bernd, even if you disable gates from changing by gating them, you still ha=
> > >ve the complete clock system across the chip and the capacities have to be =
> > >driven.
> > 
> > They used that approach for the first Alpha (21064) in 1992, and the
> > clock used up IIRC 30% of the power of the chip, and it ran only at
> > 200MHz.  This approach did not scale, so they introduced clock
> > domains, each domain with its own clock generation, fed by a common
> > clock, but with some possible skew wrt the clock in the next domain;
> > therefore pushing data across clock domains loses a cycle for every
> > boundary crossed.  At least that's what I gather from the explanations
> > why shift an multiply are slow on the original Pentium 4 (from 2001).
> > 
> > - anton
> > -- 
> > M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> >      New standard: http://www.forth200x.org/forth200x.html
> >    EuroForth 2014: http://www.euroforth.org/ef14/
> 
> There was a comparison of the sych and the asynch DLX implementation at http://www.ics.forth.gr/carv/async/demo/dlx_asic.html
> It seems now to have disappeared unfortunately

Better look here now:  http://www.ics.forth.gr/carv/aspida/

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

#37489

Anton Ertl wrote:

> JUERGEN <epldfpga@aol.com> writes:
>>Bernd, even if you disable gates from changing by gating them, you still
>>ha= ve the complete clock system across the chip and the capacities have
>>to be = driven.
> 
> They used that approach for the first Alpha (21064) in 1992, and the
> clock used up IIRC 30% of the power of the chip, and it ran only at
> 200MHz.  This approach did not scale, so they introduced clock
> domains, each domain with its own clock generation, fed by a common
> clock, but with some possible skew wrt the clock in the next domain;
> therefore pushing data across clock domains loses a cycle for every
> boundary crossed.  At least that's what I gather from the explanations
> why shift an multiply are slow on the original Pentium 4 (from 2001).

Yes, these clock domains were an intermediate step between fully-synchronous 
ungated clock trees and the fully synchronous gated clock trees that are now 
used.  That intermediate step was necessary, because the clock balancing 
tools weren't up to the task at that time.

The original Pentium 4 was probably even worse, because it had that double-
pumped ALU, and this wasn't just a different clock domain, but one with 
twice the frequency.

-- 
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]

#37480

On 3/20/2015 11:24 AM, JUERGEN wrote:
> On Thursday, March 19, 2015 at 11:14:25 PM UTC, Bernd Paysan wrote:
>> wrote:
>>
>>> On Thu, 19 Mar 2015 07:22:26 -0700 (PDT)
>>> Is it true?  Are Chucks chips internally asynchronous, or only
>>> asynchronous at the boundary of each processor core?
>>
>> There are a few different delay elements within each core to determine the
>> speed of different operations.  So it's not a single clock per core, either.
>>
>> What's clearly wrong is that a synchronous device has "billions of dumb
>> nodes which dissipate useless power"; if you do synthesize your Verilog to
>> save power, you'll enable the clock gating option, and then, only those
>> nodes who need to actually get the clock.  Sleeping cores wouldn't.
>>
>> All CPUs now, including the performance-optimized, are done that way, as
>> power dissipation is the main problem with modern processes: you have to get
>> that down to a reasonable value.
>>
>> Chuck stopped using mainstream EDA tools in the early 90s, and his
>> statements are all true for the EDA situation 20 years ago.
>>
>> --
>> 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*
>
> 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?

Perhaps you don't understand where the power goes in a clock tree.  Just 
as in a real tree, there are many, many leaves and few higher level 
trunks (lower trunks in a real tree).  These main trunks do not 
dissipate most of the power, it is the branches feeding the lower level 
nodes and the nodes themselves that consume most of the power.  So when 
a section of the chip is gated from the clock, the clock line feeding 
the gate circuitry is not dissipating so much power.
   Clk --+--+--+---X----+--+--+---O
         |  |  |        |  |  +---O
         |  |  |        |  +------O
         |  |  |        +---------O
         |  |  +---X----+--+--+---O
         |  |           |  |  +---O
         |  |           |  +------O
         |  |           +---------O
         |  +------X----+--+--+---O
         |              |  |  +---O
         |              |  +------O
         |              +---------O
         +---------X----+--+--+---O
                        |  |  +---O
                        |  +------O
                        +---------O

Here the X represents the clock gate, the lines are clock routes and the 
O are FFs.  You can see how much of the routing is in the lower levels 
and how the gating will reduce power in the clock routing.

-- 

Rick

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

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

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

csiph-web