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

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

GA144 polyForth

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

Contents

  GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-09-27 14:16 -0700
    Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-29 01:20 -0700
      Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-09-30 11:05 -0400
        Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 09:06 -0700
          Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-09-30 14:29 -0400
            Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 19:56 -0700
      Re: GA144 polyForth Coos Haak <chforth@hccnet.nl> - 2012-09-30 21:54 +0200
      Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-01 11:18 -0700
        Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-01 23:40 -0700
          Re: GA144 polyForth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-01 21:23 -1000
            Re: GA144 polyForth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-05 19:19 +0000
          Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-04 23:04 -0700
    Re: GA144 polyForth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-01 10:28 -0500
      Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-01 11:19 -0700
        Re: GA144 polyForth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-03 10:46 -0500
          Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-04 13:46 -0700
    Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-05 22:10 -0700
      Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-05 23:17 -0700
        Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-06 05:47 -0700
          Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-07 19:31 -0400
            Re: GA144 polyForth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-08 20:10 +0200
              Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-08 16:36 -0400
            Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-08 13:31 -0700
              Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-09 13:48 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-09 13:21 -0700
                  Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-09 17:08 -0400
                    Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 07:39 -0700
                      Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 14:28 -0400
                        Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 13:37 -0700
                          Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 16:54 -0400
                            Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 14:14 -0700
                              Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 17:30 -0400
                                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-14 02:00 -0700
                                  Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-14 19:54 -0400
                                    Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-15 11:03 -0700
                                      Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-15 16:38 -0400
                                        Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-16 04:12 -0700
                                          Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-16 15:46 -0400
                                            Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-16 23:05 -0700
                                              Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-17 13:40 -0400
                                                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-17 22:54 -0700
              Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 14:53 -0400
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 15:06 -0400
                  Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 15:09 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-19 10:43 -0700
                  Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-19 17:43 -0400
    Re: GA144 polyForth Mikael Nordman <oh2aun@invalid.com> - 2012-10-06 11:29 +0300
      Re: GA144 polyForth mhx@iae.nl (Marcel Hendrix) - 2012-10-06 11:14 +0200
        Re: GA144 polyForth Mikael Nordman <oh2aun@invalid.com> - 2012-10-06 16:08 +0300
      Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-07 10:57 -0700

Page 1 of 3  [1] 2 3  Next page →

#15789 — GA144 polyForth

Hi All,

I have just downloaded the latest arrayForth and polyForth systems for the GreenArrays GA144 EV001 evaluation board, dusted down the eval board and installed it...

Back in ~1978 I accidentally came across microForth for the COSMAC computer, with a 2 MHz CDP1802 and 12K of RAM, and typed  1 1 + .  for the first time.
Since then I have used various flavours of Forth, and I use this simple test to confirm that I can interact with the computer.

So nothing new here, I still get the answer 2, and Greg's saneForth Terminal looks very DOS-like (except that it actually runs under Win7 64 bit).

But this is actually something very different :
1. There is no assembler because this is running in a few of the F18 cores in one of the GA144 chips which have a Forth instruction set.
2. There is no cross compiler because the GA144 polyForth compiles itself on the chip - the PC is only a terminal.
3. There is no "inner interpreter" AKA "address interpreter" because the F18 cores are programmed to be the polyForth virtual machine. OK, you can argue semantics here...
4. Contradicting point 1, there is a sort of assembler, in that you can define extensions to the virtual machine, and also access any of the other 100+ F18's via Ganglia and Snorkels ( whatever they are - more docs please GA guys :-)

I also ran a speed test :
: asd  1000 for 1000 for 0 drop next next ;
takes about 3 seconds. 
IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit processors are some tens of seconds.

Speed wise, the combination of GA144, SPI EEPROM and SRAM, running polyForth looks plenty fast enough for the sort of embedded apps I usually work with.
Power wise, it looks good too.
Cost wise, well maybe I can haggle with GA...
Peripherals - there are plenty of fast counters, F18's in adundance that can be programmed to do simple serial or even 10M Ethernet, or you can use the built in SERDES.

All in all it could compete with an MSP430, 8051 or a PIC except that only with the GA144 do you get so many fast cores with fast I/O to play with.

The GA144 with polyForth seems to be to good not to use...

Just sharing my excitement - well done to all the GreenArray folks!

Best regards,
Howerd





 

[toc] | [next] | [standalone]

#15813

Howerd <howerdo@yahoo.co.uk> writes:
> I have just downloaded the latest arrayForth and polyForth systems for
> the GreenArrays GA144 EV001 evaluation board, dusted down the eval
> board and installed it...

That sounds really cool.  Thanks for the post.  Had you been using
eforth on the eval board before?

> 2. There is no cross compiler because the GA144 polyForth compiles
> itself on the chip - the PC is only a terminal.

I'm just wondering but do they distribute it as source code so you can
rebuild it yourself?

> 3. There is no "inner interpreter" AKA "address interpreter" because
> the F18 cores are programmed to be the polyForth virtual machine. OK,
> you can argue semantics here...

I wish they would document how the VM works.  Greg Bailey had a plea for
someone to target a C compiler to the GA144, but I couldn't make enough
sense of the VM source listing to tell whether those VM nodes (they have
ROM code for the vm) could be a sensible C target already.

> the other 100+ F18's via Ganglia and Snorkels ( whatever they are -
> more docs please GA guys :-)

That's the stuff for routing code and data around the GA144.  It's
mentioned on some of the videos (type "greenarrays" into youtube).

> : asd  1000 for 1000 for 0 drop next next ;
> takes about 3 seconds. 

OK, I remember hearing something like 250ns access time to the external
ram, so each pass through the loop is doing 10-12 ram accesses (the F18
cycles probably don't use much of that 3 sec).  I guess not too bad,
figuring it's a traditional threaded interpreter.

> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit
> processors are some tens of seconds.

Hrm, do you mean recent 8 bitters?  And I wonder how something like an
MSP430 (16 bit) would do.

> Speed wise, the combination of GA144, SPI EEPROM and SRAM, running
> polyForth looks plenty fast enough for the sort of embedded apps I
> usually work with.

> Power wise, it looks good too.

Did you measure the power, running that 3 second loop?  I wonder how it
really compares with something like an MSP430, since those VM nodes are
running at 700 mhz or so.  OTOH they may be idle most of the time,
waiting for the external ram.

> All in all it could compete with an MSP430, 8051 or a PIC except that
> only with the GA144 do you get so many fast cores with fast I/O to
> play with.

Right now it sounds sort of like a somewhat unusual FPGA, as Rickman has
pointed out a few times.  It's nice that there's now a working "soft
core" using a few of its cells that can run a relatively conventional
software environment (calling Polyforth conventional just shows how far,
er, ahead of the curve GA is).

> The GA144 with polyForth seems to be to good not to use...
> Just sharing my excitement - well done to all the GreenArray folks!

Yes, it's a good development, and makes the product more "real".
Congrats GA.

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

#15827

On 9/29/2012 4:20 AM, Paul Rubin wrote:
> Howerd<howerdo@yahoo.co.uk>  writes:
>> I have just downloaded the latest arrayForth and polyForth systems for
>> the GreenArrays GA144 EV001 evaluation board, dusted down the eval
>> board and installed it...
>
>> 3. There is no "inner interpreter" AKA "address interpreter" because
>> the F18 cores are programmed to be the polyForth virtual machine. OK,
>> you can argue semantics here...
>
> I wish they would document how the VM works.  Greg Bailey had a plea for
> someone to target a C compiler to the GA144, but I couldn't make enough
> sense of the VM source listing to tell whether those VM nodes (they have
> ROM code for the vm) could be a sensible C target already.

I am a bit biased being more of a hardware designer, but I can't see a C 
compiler being all that useful.  Maybe I don't appreciate the utility or 
efficiency of such a tool, but it seems to me the VM will run a lot 
slower than many other CPUs and will end up being very energy 
inefficient.  I can see running one VM to facilitate high level control 
or UI functions but running many of them can be difficult due to memory 
access conflicts and not along the lines of the chip's strong suit... 
fast, efficient hardware.


>> the other 100+ F18's via Ganglia and Snorkels ( whatever they are -
>> more docs please GA guys :-)
>
> That's the stuff for routing code and data around the GA144.  It's
> mentioned on some of the videos (type "greenarrays" into youtube).

I don't recall seeing this anywhere.  Chuck has done his stuff on 
inter-node comms but I don't recall these names being used anywhere. 
But then he noted that this was very complex code, so I never dug into 
it.  I expect to be useful it will need clear, simple documentation of 
how to use it.


>> : asd  1000 for 1000 for 0 drop next next ;
>> takes about 3 seconds.
>
> OK, I remember hearing something like 250ns access time to the external
> ram, so each pass through the loop is doing 10-12 ram accesses (the F18
> cycles probably don't use much of that 3 sec).  I guess not too bad,
> figuring it's a traditional threaded interpreter.
>
>> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit
>> processors are some tens of seconds.
>
> Hrm, do you mean recent 8 bitters?  And I wonder how something like an
> MSP430 (16 bit) would do.

Comparing a VM on a processor node on a $15 GA144 (which also needs 
external memory, etc) to an MCU that costs next to nothing is pretty 
pointless.  The question is not, can the GA144 do a job, the question 
is, is it the best chip for the application?


>> Speed wise, the combination of GA144, SPI EEPROM and SRAM, running
>> polyForth looks plenty fast enough for the sort of embedded apps I
>> usually work with.
>
>> Power wise, it looks good too.
>
> Did you measure the power, running that 3 second loop?  I wonder how it
> really compares with something like an MSP430, since those VM nodes are
> running at 700 mhz or so.  OTOH they may be idle most of the time,
> waiting for the external ram.

If it is running one node at full speed, it will use around 5 mW.  Many 
8 bitters will use around that same power level, but this would need to 
be normalized to their computing time.  That is essentially what Greg 
Bailey does in white paper 3, "Comparison..." with an MSP430.  But they 
use an old version of the MSP and I think the results are a bit skewed 
because of that.


>> All in all it could compete with an MSP430, 8051 or a PIC except that
>> only with the GA144 do you get so many fast cores with fast I/O to
>> play with.
>
> Right now it sounds sort of like a somewhat unusual FPGA, as Rickman has
> pointed out a few times.  It's nice that there's now a working "soft
> core" using a few of its cells that can run a relatively conventional
> software environment (calling Polyforth conventional just shows how far,
> er, ahead of the curve GA is).

Yes, and I think the device could be much better served by a Verilog or 
VHDL compiler than a C compiler.  But in reality I think they just need 
to figure out how customers can best use their devices and work on 
producing more app notes and guides to help us learn these techniques. 
The last conversation I had with Greg was along the lines of I need to 
measure timing data for myself.  I think this is a bit much to expect of 
customers.


>> The GA144 with polyForth seems to be to good not to use...
>> Just sharing my excitement - well done to all the GreenArray folks!
>
> Yes, it's a good development, and makes the product more "real".
> Congrats GA.

Hmmm, I think that was intended to be "*too* good not to use".  A small 
change makes a big difference in interpretation.

Rick

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

#15829

rickman <gnuarm@gmail.com> writes:
>> Greg Bailey had a plea for someone to target a C compiler to the
>> GA144, but I couldn't make enough sense of the VM source listing to
> I can see running one VM to facilitate high level
> control or UI functions but running many of them can be difficult

Yes, the idea is to just run one VM with control and UI stuff.  The VM
is programmed into the ROM of 3 nodes that sit near the nodes programmed
to be the external SRAM controller.  I don't think anyone was talking
about running multiple ones.  Greg was looking to be able to program the
VM in C.

>>> the other 100+ F18's via Ganglia and Snorkels
>> mentioned on some of the videos (type "greenarrays" into youtube).
> I don't recall seeing this anywhere.  Chuck has done his stuff on
> inter-node comms but I don't recall these names being used

http://www.youtube.com/results?search_query=greenarrays

It's on the second page of results.

> If it is running one node at full speed, it will use around 5 mW.
> Many 8 bitters will use around that same power level, but this would
> need to be normalized to their computing time.

The computing time is on the same order as the GA running the VM.  I'm
kind of surprised to hear that modern 8 bitters use anything like 5mw if
they care about power at all, though.

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

#15832

On 9/30/2012 12:06 PM, Paul Rubin wrote:
> rickman<gnuarm@gmail.com>  writes:
>>> Greg Bailey had a plea for someone to target a C compiler to the
>>> GA144, but I couldn't make enough sense of the VM source listing to
>> I can see running one VM to facilitate high level
>> control or UI functions but running many of them can be difficult
>
> Yes, the idea is to just run one VM with control and UI stuff.  The VM
> is programmed into the ROM of 3 nodes that sit near the nodes programmed
> to be the external SRAM controller.  I don't think anyone was talking
> about running multiple ones.  Greg was looking to be able to program the
> VM in C.

Ok, I guess I got confused when Howerd referred to "a few of the F18 
cores", he means one virtual machine on three nodes.


>>>> the other 100+ F18's via Ganglia and Snorkels
>>> mentioned on some of the videos (type "greenarrays" into youtube).
>> I don't recall seeing this anywhere.  Chuck has done his stuff on
>> inter-node comms but I don't recall these names being used
>
> http://www.youtube.com/results?search_query=greenarrays
>
> It's on the second page of results.

I'll take a look when I get a chance.  Video is my least favorite way of 
getting technical info.  I find it time consuming for the amount of 
information conveyed and hard to review.  But then GA doesn't let you 
make notes on the PDF files either.  Sometimes it seems like they don't 
want you to learn about this stuff.


>> If it is running one node at full speed, it will use around 5 mW.
>> Many 8 bitters will use around that same power level, but this would
>> need to be normalized to their computing time.
>
> The computing time is on the same order as the GA running the VM.  I'm
> kind of surprised to hear that modern 8 bitters use anything like 5mw if
> they care about power at all, though.

8 bitters are just a little better on power (if at all) than 32 bitters, 
IIRC.  I seem to find a lot of parts running at around 200 uA/MHz with 
various voltages on the core.  So at 8 MHz 5 mW would be a good number 
for most CPUs.  At full speed even the good 32 bitters can get up to 
30-40 mW without too much trouble.

I don't see a lot of value in running a VM on the GA144 at the same 
speed and possibly more power than many MCUs.  Looking at the rest of 
the chip as the reason to use the GA144, what is there?  It has some 
real potential for software based IO, but this is also very limiting. 
Many MCUs have 100 Mbps Ethernet, the GA144 does 10 Mbps.  Many MCUs 
have 480 Mbps USB2.0, the GA144 doesn't have USB implemented as yet, but 
it might be able to support 12 Mbps.

There are so many things the GA144 can't do without external support 
chips, including storing more than a few kBytes of information.

I thought I had a handle on a way to use the device by looking at it as 
a processor based analog to an FPGA, but when I tried to design with it 
that way I couldn't get all the info I needed from GA.  They just didn't 
want to support any method of working other than their way.  I can't 
imagine how they would support C developers who are used to big, complex 
tools for developing C programs.

I can't see how providing a C compiler to use with a single VM running 
at similar speeds to an 8 bit MCU will be any real incentive to use the 
GA144 and it would be tons of work.  Forth is not a bad language for 
developing high level code and it is not hard to learn.  They need tools 
to let people deal with the real problems of using the GA144 which seems 
to be the floor planning.  In the short term I would think this would be 
app notes more than anything else that would take so much longer to 
develop.

Rick

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

#15839

rickman <gnuarm@gmail.com> writes:
>> http://www.youtube.com/results?search_query=greenarrays
> I'll take a look when I get a chance.  Video is my least favorite way
> of getting technical info.

Yeah, I agree with this.  I've looked at a few of the videos and they
have useful content, but I'd rather have readable documentation.

> 8 bitters are just a little better on power (if at all) than 32
> bitters, IIRC. 

Oh that's interesting, I'd figured 32 bitters have 4x as many gates
toggling on each cycle.  It takes more instructions to make stuff happen
with an 8-bitter, but for stuff like UI's that may not matter.  I've
thought 16 bits is a sweet spot for small cpu's running either Forth or C.

> I don't see a lot of value in running a VM on the GA144 at the same
> speed and possibly more power than many MCUs. 

The VM seems like a reasonable approach for complex control stuff
reaching into the GA144 instead of adding an external processor.  Of
course the GA144 makes no sense as a conventional MCU replacement.  It's
only for when there's other stuff you want to do with the rest of the
nodes.  As you know, I agree with you that finding applications for the
rest of the nodes isn't so easy.

> I can't see how providing a C compiler to use with a single VM running
> at similar speeds to an 8 bit MCU will be any real incentive to use
> the GA144 and it would be tons of work.  Forth is not a bad language
> for developing high level code and it is not hard to learn.  

If you've got a reasonable (virtual) cpu target, and if you don't care
about crappy code coming out, targeting a C compiler isn't that hard.  I
could imagine it helping with user acceptance and letting people port
some of their existing code instead of writing new code.

One issue making things harder for you may be that you were trying to
push the chip's performance to its limits.  It may be easier with
programs where the nodes are mostly idle and plenty fast, and you deal
with speed or space problems by spreading the workload over more nodes.

> They need tools to let people deal with the real problems of using the
> GA144 which seems to be the floor planning. 

Yeah, that calls for automated tools, and more inter-node connectivity
if they make a new version of the chip.

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

#15835

Op Sat, 29 Sep 2012 01:20:40 -0700 schreef Paul Rubin:

<snip>
>>: asd  1000 for 1000 for 0 drop next next ;
>> takes about 3 seconds. 
> 
> OK, I remember hearing something like 250ns access time to the external
> ram, so each pass through the loop is doing 10-12 ram accesses (the F18
> cycles probably don't use much of that 3 sec).  I guess not too bad,
> figuring it's a traditional threaded interpreter.
> 
>> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit
>> processors are some tens of seconds.
> 
> Hrm, do you mean recent 8 bitters?  And I wonder how something like an
> MSP430 (16 bit) would do.
noForth, a Dutch Forth, see
http://www.forth.hcc.nl/w/WerkgroepMSP/WerkgroepMSP
does it in just under 5 seconds.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#15853

On Saturday, September 29, 2012 10:20:47 AM UTC+2, Paul Rubin wrote:
> Howerd <how....@yahoo.co.uk> writes:
> 
> > I have just downloaded the latest arrayForth and polyForth systems for
> 
> > the GreenArrays GA144 EV001 evaluation board, dusted down the eval
> 
> > board and installed it...
> 
> 
> 
> That sounds really cool.  Thanks for the post.  Had you been using
> 
> eforth on the eval board before?
> 
> 
> 
> > 2. There is no cross compiler because the GA144 polyForth compiles
> 
> > itself on the chip - the PC is only a terminal.
> 
> 
> 
> I'm just wondering but do they distribute it as source code so you can
> 
> rebuild it yourself?
> 
> 
> 
> > 3. There is no "inner interpreter" AKA "address interpreter" because
> 
> > the F18 cores are programmed to be the polyForth virtual machine. OK,
> 
> > you can argue semantics here...
> 
> 
> 
> I wish they would document how the VM works.  Greg Bailey had a plea for
> 
> someone to target a C compiler to the GA144, but I couldn't make enough
> 
> sense of the VM source listing to tell whether those VM nodes (they have
> 
> ROM code for the vm) could be a sensible C target already.
> 
> 
> 
> > the other 100+ F18's via Ganglia and Snorkels ( whatever they are -
> 
> > more docs please GA guys :-)
> 
> 
> 
> That's the stuff for routing code and data around the GA144.  It's
> 
> mentioned on some of the videos (type "greenarrays" into youtube).
> 
> 
> 
> > : asd  1000 for 1000 for 0 drop next next ;
> 
> > takes about 3 seconds. 
> 
> 
> 
> OK, I remember hearing something like 250ns access time to the external
> 
> ram, so each pass through the loop is doing 10-12 ram accesses (the F18
> 
> cycles probably don't use much of that 3 sec).  I guess not too bad,
> 
> figuring it's a traditional threaded interpreter.
> 
> 
> 
> > IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit
> 
> > processors are some tens of seconds.
> 
> 
> 
> Hrm, do you mean recent 8 bitters?  And I wonder how something like an
> 
> MSP430 (16 bit) would do.
> 
> 
> 
> > Speed wise, the combination of GA144, SPI EEPROM and SRAM, running
> 
> > polyForth looks plenty fast enough for the sort of embedded apps I
> 
> > usually work with.
> 
> 
> 
> > Power wise, it looks good too.
> 
> 
> 
> Did you measure the power, running that 3 second loop?  I wonder how it
> 
> really compares with something like an MSP430, since those VM nodes are
> 
> running at 700 mhz or so.  OTOH they may be idle most of the time,
> 
> waiting for the external ram.
> 
> 
> 
> > All in all it could compete with an MSP430, 8051 or a PIC except that
> 
> > only with the GA144 do you get so many fast cores with fast I/O to
> 
> > play with.
> 
> 
> 
> Right now it sounds sort of like a somewhat unusual FPGA, as Rickman has
> 
> pointed out a few times.  It's nice that there's now a working "soft
> 
> core" using a few of its cells that can run a relatively conventional
> 
> software environment (calling Polyforth conventional just shows how far,
> 
> er, ahead of the curve GA is).
> 
> 
> 
> > The GA144 with polyForth seems to be to good not to use...
> 
> > Just sharing my excitement - well done to all the GreenArray folks!
> 
> 
> 
> Yes, it's a good development, and makes the product more "real".
> 
> Congrats GA.

Hi Paul,

> Had you been using eforth on the eval board before?
I got it running when I first got the board, but it lacks a multitasker, so I haven't been using it. So far I am just using the Eval board to evaluate the chip...

> I guess not too bad, figuring it's a traditional threaded interpreter.
I don't think it is a traditional threaded interpreter. The tokens have bits that determine which node they are to be sent to, and a lot of Forth primitives map directly to F18 opcodes. My mind goes fuzzy thinking about this.

> Did you measure the power, running that 3 second loop? 
I got out the soldering iron and fitted a 1 ohm resistor in place of the link for the Vcc Core, and the results are :
Reset       0.0mA ( my meter doesn't go that low )
polyForth   14.1mA
"ASD" loop  13.8mA 

So running a tight loop uses *less* current than running polyForth, presumably because some of the cores are doing less.
BTW Freezing the chip with freeze spray increases the pF idle current from 14.1 to 14.4mA, and the 3 seconds for the ASD loop goes down to about 2.5.

The conclusion is that if you want very low power consumption you may have to disable the pF VM and/or its Ganglions and Snorkels. I remember hearing about a new hardware development to allow each core to do more without polling and using current.
I would love to have a visual tool that displayed what was going on in each core, like softsim, but for the real chip. 

> It's nice that there's now a working "soft
> core" using a few of its cells that can run a relatively conventional
> software environment (calling Polyforth conventional just shows how far,
> er, ahead of the curve GA is).
This made me chuckle :-) I used polyForth though the 80's and 90's and still sometimes today, so seeing it running on tha GA144 is really sweet. I can see some interesting design decisions, such as : do I put the ADC in its own polyForth task, extend the polyForth VM to read it for me, or use another F18???

The weird power result made me realise that if you want to know how much current the GA144 uses you have to add up the current that each F18 core uses - obviously really, but there's 144 of them, and any or all of them might be doing something interesting. 

BTW I put similar ASD code on an 89C450 with a 22MHz crystal - 29 seconds compared to 11 seconds for the DO ... LOOP form on the GA144. So not far off 3 times faster, but of course the one polyForth VM is only using a handful of F18's - you cold run 20 of them, if you could find a use for this...

Summary : the GA144 is to hardware what colorForth is to software - leave all of your assumptions behind and be prepared to find new ways of doing things.
Absoultely superb, if you like that kind of thing, as I do :-)

Best regards,
Howerd

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

#15856

Howerd <howerdo@yahoo.co.uk> writes:
>> Had you been using eforth on the eval board before?
> I got it running when I first got the board, but it lacks a
> multitasker, so I haven't been using it.

But eforth has a beautiful multitasker that's just a dozen lines of code
or so, and should be pretty portable.  I wonder why the GA version
didn't include it.  Maybe it could be added on.

> I don't think it is a traditional threaded interpreter. The tokens
> have bits that determine which node they are to be sent to, and a lot
> of Forth primitives map directly to F18 opcodes. My mind goes fuzzy
> thinking about this.

Yeah, that makes sense about the primitives.  I wonder if the stacks are
in the VM or in external ram.  ANS requires 32 stack levels iirc, so
they could use an f18 node for both stacks, caching the top element
in the control node.

> polyForth   14.1mA
> "ASD" loop  13.8mA 
> So running a tight loop uses *less* current than running polyForth,...
> The conclusion is that if you want very low power consumption you may
> have to disable the pF VM and/or its Ganglions and Snorkels.

Wait, do you mean polyForth burns that much power when it's sitting
there waiting for input, polling the port or something?  They don't have
edge triggered i/o?  When an f18 node is waiting on a port it's supposed
to use almost no power; that's its whole idea.

> BTW I put similar ASD code on an 89C450 with a 22MHz crystal - 29
> seconds compared to 11 seconds for the DO ... LOOP form on the GA144.

Oh man, that's pretty about the 89C450 which I'll guess might be
comparable to an AVR.  This looks interesting:

  http://tinyurl.com/d5zef8l

a $12.95 Cortex M0+ board from element14.com, 128k flash, 16k sram, 48
mhz, various goodies on the board, shipping from stock.  Of course on
the 89C450, I'd expect a native-compiled Forth to be much faster.

I ordered a couple of the Cortex M4 Launchpads ($5 each, 10+ week
delivery) on the theory that they might increase the price once the
things are actually shipping, and ordered an MSP430 Launchpad ($4.30)
while I was at it.  I have only vague ideas of what to do with them, but
at that price they are almost free.  I may run 4e4th on it.

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

#15857

On 10/1/12 8:40 PM, Paul Rubin wrote:
> Howerd <howerdo@yahoo.co.uk> writes:
...
> Wait, do you mean polyForth burns that much power when it's sitting
> there waiting for input, polling the port or something?  They don't have
> edge triggered i/o?  When an f18 node is waiting on a port it's supposed
> to use almost no power; that's its whole idea.

The standard polyFORTH multitasker doesn't shut down when there's 
nothing to do (it was not designed for low-power operation). The SwiftX 
multitasker on processors such as MSP430 designed for low-power apps has 
a very simple mod to go to power-saving mode automatically if one lap 
around the task loop yields no active tasks. Then you add one 
instruction to any interrupt code to wake up. It would be easy to add 
that feature to the GA144 polyFORTH if they want to. Assuming, of 
course, that this is what you're observing.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#15951

In article <HoGdnUYJTP4XC_fNnZ2dnUVZ_o-dnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 10/1/12 8:40 PM, Paul Rubin wrote:
>> Howerd <howerdo@yahoo.co.uk> writes:
>...
>> Wait, do you mean polyForth burns that much power when it's sitting
>> there waiting for input, polling the port or something?  They don't have
>> edge triggered i/o?  When an f18 node is waiting on a port it's supposed
>> to use almost no power; that's its whole idea.
>
>The standard polyFORTH multitasker doesn't shut down when there's
>nothing to do (it was not designed for low-power operation). The SwiftX
>multitasker on processors such as MSP430 designed for low-power apps has
>a very simple mod to go to power-saving mode automatically if one lap
>around the task loop yields no active tasks. Then you add one
>instruction to any interrupt code to wake up. It would be easy to add
>that feature to the GA144 polyFORTH if they want to. Assuming, of
>course, that this is what you're observing.

Look! If it is waiting for the keyboard it is consuming 700 nano Amperes!

From the point of marketing not spending this effort is a first rate
blooper. The power consumption is the single most important marketing
asset of the GA144.

In this competitive world a company that makes such marketing
mistakes doesn't deserve to live...

(Unless of course it would consume little but way more than a Launchpad.
Then they are wise not to draw attention to the fact.)

>
>Cheers,
>Elizabeth

Groetjes Albert

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

#15940

On Tuesday, October 2, 2012 8:40:15 AM UTC+2, Paul Rubin wrote:
> Howerd <how....@yahoo.co.uk> writes:
> 
> >> Had you been using eforth on the eval board before?
> 
> > I got it running when I first got the board, but it lacks a
> 
> > multitasker, so I haven't been using it.
> 
> 
> 
> But eforth has a beautiful multitasker that's just a dozen lines of code
> 
> or so, and should be pretty portable.  I wonder why the GA version
> 
> didn't include it.  Maybe it could be added on.
> 
> 
> 
> > I don't think it is a traditional threaded interpreter. The tokens
> 
> > have bits that determine which node they are to be sent to, and a lot
> 
> > of Forth primitives map directly to F18 opcodes. My mind goes fuzzy
> 
> > thinking about this.
> 
> 
> 
> Yeah, that makes sense about the primitives.  I wonder if the stacks are
> 
> in the VM or in external ram.  ANS requires 32 stack levels iirc, so
> 
> they could use an f18 node for both stacks, caching the top element
> 
> in the control node.
> 
> 
> 
> > polyForth   14.1mA
> 
> > "ASD" loop  13.8mA 
> 
> > So running a tight loop uses *less* current than running polyForth,...
> 
> > The conclusion is that if you want very low power consumption you may
> 
> > have to disable the pF VM and/or its Ganglions and Snorkels.
> 
> 
> 
> Wait, do you mean polyForth burns that much power when it's sitting
> 
> there waiting for input, polling the port or something?  They don't have
> 
> edge triggered i/o?  When an f18 node is waiting on a port it's supposed
> 
> to use almost no power; that's its whole idea.
> 
> 
> 
> > BTW I put similar ASD code on an 89C450 with a 22MHz crystal - 29
> 
> > seconds compared to 11 seconds for the DO ... LOOP form on the GA144.
> 
> 
> 
> Oh man, that's pretty about the 89C450 which I'll guess might be
> 
> comparable to an AVR.  This looks interesting:
> 
> 
> 
>   http://tinyurl.com/d5zef8l
> 
> 
> 
> a $12.95 Cortex M0+ board from element14.com, 128k flash, 16k sram, 48
> 
> mhz, various goodies on the board, shipping from stock.  Of course on
> 
> the 89C450, I'd expect a native-compiled Forth to be much faster.
> 
> 
> 
> I ordered a couple of the Cortex M4 Launchpads ($5 each, 10+ week
> 
> delivery) on the theory that they might increase the price once the
> 
> things are actually shipping, and ordered an MSP430 Launchpad ($4.30)
> 
> while I was at it.  I have only vague ideas of what to do with them, but
> 
> at that price they are almost free.  I may run 4e4th on it.

Hi Paul,

> But eforth has a beautiful multitasker
Yes - somehow I had missed this. I think I didn't use eForth because it did not come with source code...

It occured to me that the polyForth VM is loaded mostly by "hi" so its in high level polyForth, so it should be easy to follow what is spinning and using power. I will take a look, when I get time.

Best regards,
Howerd

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

#15848

Howerd <howerdo@yahoo.co.uk> wrote:

> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8
  bit processors are some tens of seconds.

Erm, 16MHz?  IIRC we never got it running past 6.  :-)

Andrew.

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

#15854

On Monday, October 1, 2012 5:28:08 PM UTC+2, Andrew Haley wrote:
> Howerd <how....@yahoo.co.uk> wrote:
> 
> 
> 
> > IIRC a 16 MHx Novix takes less than 1 second for this, and most 8
> 
>   bit processors are some tens of seconds.
> 
> 
> 
> Erm, 16MHz?  IIRC we never got it running past 6.  :-)
> 
> 
> 
> Andrew.

Hi Andrew,

Maybe it was 8 MHz - but this was in the 1990's at MPE, not 1980's at COMSOL, so maybe they were faster chips?

Best regards,
Howerd

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

#15881

Howerd <howerdo@yahoo.co.uk> wrote:
> On Monday, October 1, 2012 5:28:08 PM UTC+2, Andrew Haley wrote:
>> Howerd <how....@yahoo.co.uk> wrote:
>> 
>> > IIRC a 16 MHx Novix takes less than 1 second for this, and most 8
>> 
>>   bit processors are some tens of seconds.
>> 
>> Erm, 16MHz?  IIRC we never got it running past 6.  :-)
>> 
> 
> Maybe it was 8 MHz - but this was in the 1990's at MPE, not 1980's at COMSOL, so maybe they were faster chips?

Maybe, I think you could run Novix at 8MHz if you used insanely fast
SRAM for the stacks.  I thought there was only one run of Novix chips,
though.  I also thought MPE didn't use Novix, but the Harrix RTX.

Andrew.

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

#15926

On Wednesday, October 3, 2012 5:46:03 PM UTC+2, Andrew Haley wrote:
> Howerd <how....@yahoo.co.uk> wrote:
> 
> > On Monday, October 1, 2012 5:28:08 PM UTC+2, Andrew Haley wrote:
> 
> >> Howerd <how....@yahoo.co.uk> wrote:
> 
> >> 
> 
> >> > IIRC a 16 MHx Novix takes less than 1 second for this, and most 8
> 
> >> 
> 
> >>   bit processors are some tens of seconds.
> 
> >> 
> 
> >> Erm, 16MHz?  IIRC we never got it running past 6.  :-)
> 
> >> 
> 
> > 
> 
> > Maybe it was 8 MHz - but this was in the 1990's at MPE, not 1980's at COMSOL, so maybe they were faster chips?
> 
> 
> 
> Maybe, I think you could run Novix at 8MHz if you used insanely fast
> 
> SRAM for the stacks.  I thought there was only one run of Novix chips,
> 
> though.  I also thought MPE didn't use Novix, but the Harrix RTX.
> 
> 
> 
> Andrew.

Hi Andrew,

You are right - time has taken its toll on the wetware :-(
They were RTX 2001's I think, which I believe are very similar to the Novix.
So maybe 16MHz clock was right.
I definitely remember having to double check that the loop was actually doing something, as I thought it was way too fast...

Best regards,
Howerd

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

#15965

On Thursday, September 27, 2012 11:16:44 PM UTC+2, Howerd wrote:
> Hi All,
> 
> 
> 
> I have just downloaded the latest arrayForth and polyForth systems for the GreenArrays GA144 EV001 evaluation board, dusted down the eval board and installed it...
> 
> 
> 
> Back in ~1978 I accidentally came across microForth for the COSMAC computer, with a 2 MHz CDP1802 and 12K of RAM, and typed  1 1 + .  for the first time.
> 
> Since then I have used various flavours of Forth, and I use this simple test to confirm that I can interact with the computer.
> 
> 
> 
> So nothing new here, I still get the answer 2, and Greg's saneForth Terminal looks very DOS-like (except that it actually runs under Win7 64 bit).
> 
> 
> 
> But this is actually something very different :
> 
> 1. There is no assembler because this is running in a few of the F18 cores in one of the GA144 chips which have a Forth instruction set.
> 
> 2. There is no cross compiler because the GA144 polyForth compiles itself on the chip - the PC is only a terminal.
> 
> 3. There is no "inner interpreter" AKA "address interpreter" because the F18 cores are programmed to be the polyForth virtual machine. OK, you can argue semantics here...
> 
> 4. Contradicting point 1, there is a sort of assembler, in that you can define extensions to the virtual machine, and also access any of the other 100+ F18's via Ganglia and Snorkels ( whatever they are - more docs please GA guys :-)
> 
> 
> 
> I also ran a speed test :
> 
> : asd  1000 for 1000 for 0 drop next next ;
> 
> takes about 3 seconds. 
> 
> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit processors are some tens of seconds.
> 
> 
> 
> Speed wise, the combination of GA144, SPI EEPROM and SRAM, running polyForth looks plenty fast enough for the sort of embedded apps I usually work with.
> 
> Power wise, it looks good too.
> 
> Cost wise, well maybe I can haggle with GA...
> 
> Peripherals - there are plenty of fast counters, F18's in adundance that can be programmed to do simple serial or even 10M Ethernet, or you can use the built in SERDES.
> 
> 
> 
> All in all it could compete with an MSP430, 8051 or a PIC except that only with the GA144 do you get so many fast cores with fast I/O to play with.
> 
> 
> 
> The GA144 with polyForth seems to be to good not to use...
> 
> 
> 
> Just sharing my excitement - well done to all the GreenArray folks!
> 
> 
> 
> Best regards,
> 
> Howerd

Hi Albert,

This is the Host chip, running a high level IDE. Maybe we could add an idle instruction to the polyForth IDE, but I think that there is always going to be an overhead when you interface a GA144 to a clocked system - since the GA144 runs asynchronously it has to run a polling loop. 
OK, it could idle between characters, but a better way would be to use the on-chip SERDES instead of RS232 to communicate with the outside world, and let another interface burn the current. This would also give a 400 x speed improvement.

BTW after reset the auto-baud loop uses 8 mA, presumably on one F18. 

Best regards,
Howerd

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

#15966

Howerd <howerdo@yahoo.co.uk> writes:
> always going to be an overhead when you interface a GA144 to a clocked
> system - since the GA144 runs asynchronously it has to run a polling
> loop.  OK, it could idle between characters,

Can't it use edge or level sensitive triggering on the port pin
listening to the rs232 signal?  Then the GA node should block until the
bit actually arrives.

It also occurs to me, I don't see any way for a GA node to enter a sleep
for a given amount of time (say 100 microseconds), other than with a
full-speed busy loop and that 8 ma of power consumption.  Compare that
with microcontrollers that have very low powered counter-timers.

8 ma is more than I expected for a single node anyway.  It means over 1
amp for all 144 nodes going at once, or several watts of power.  I
didn't realize the ga144 could use that much.  Or, maybe the 8ma
includes other stuff too.

> but a better way would be to use the on-chip SERDES instead of RS232

The on-chip serdes is designed to only talk to other ga144's--do you
mean to add a third ga144 to the board?

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

#15971

On Saturday, October 6, 2012 8:17:09 AM UTC+2, Paul Rubin wrote:
> Howerd <how....@yahoo.co.uk> writes:
> 
> > always going to be an overhead when you interface a GA144 to a clocked
> 
> > system - since the GA144 runs asynchronously it has to run a polling
> 
> > loop.  OK, it could idle between characters,
> 
> 
> 
> Can't it use edge or level sensitive triggering on the port pin
> 
> listening to the rs232 signal?  Then the GA node should block until the
> 
> bit actually arrives.
> 
> 
> 
> It also occurs to me, I don't see any way for a GA node to enter a sleep
> 
> for a given amount of time (say 100 microseconds), other than with a
> 
> full-speed busy loop and that 8 ma of power consumption.  Compare that
> 
> with microcontrollers that have very low powered counter-timers.
> 
> 
> 
> 8 ma is more than I expected for a single node anyway.  It means over 1
> 
> amp for all 144 nodes going at once, or several watts of power.  I
> 
> didn't realize the ga144 could use that much.  Or, maybe the 8ma
> 
> includes other stuff too.
> 
> 
> 
> > but a better way would be to use the on-chip SERDES instead of RS232
> 
> 
> 
> The on-chip serdes is designed to only talk to other ga144's--do you
> 
> mean to add a third ga144 to the board?

Hi Paul,

> ... I don't see any way for a GA node to enter a sleep
> for a given amount of time (say 100 microseconds), other than with a
> full-speed busy loop and that 8 ma of power consumption.
Yes - being asynchronous means that it has no idea of time.
But the only reason to wait for 100 ns is to synchronise with an external synchronous device - I'm stating the obvious here, but the GA144 is best suited to a fully asynchronous environment. If only the whole world was asynchronous - maybe it should be ;-) 

> The on-chip serdes is designed to only talk to other ga144's--do you
> mean to add a third ga144 to the board?
Nope - there are already two on the eval board, one of them is already acting as the interface to the synchronous world, via USB and serial comms. The two chips communicate via serdes.
But the serdes protocol is very simple, and self clocking (as it must be!), so maybe it could be implemented in software on another chip. The auto-baud software needs at least 19200 baud to not overflow the 18 bit counter, so a reasonably fast ARM should be able to keep up.

There is a common theme here that I have noticed : The GA144 does things its own way, and it is difficult to interface it to the rest of the world which is doing things another way. 

For example :
1. It would be great, but non-trivial, to run a USB stack on a handful of F18's. Does this mean that the GA144 should have hardware USB support added, or that USB should changed for something simpler?
2. SDRAM has a synchronous interface, but runs dynamically internally. I believe there are asynchronous RAMS, but thay are rare. Should the GA144 add a fast SDRAM module, or should the SDRAM chip be modified?
3. Most software is written with the assumption of large amounts of flat addressed memory ( doesn't the 1M byte DOS limit feel really tight? ). But you can write software in very small, colorForth size chunks. If you spread these around a few F18's maybe you can create something really cool.

Going back to the original point - yes the GA144 can wait in an idle state for a pin to change state, but it must poll to get timings. Maybe a neighbouring F18 could wait for a change of state on a fixed clock signal, say at 16 * baudrate, then pass this on. This should get the power down to a minimum. Then again, maybe fixed baud rate is not the right way to talk to a GA144...

What would be interesting is to move the polyForth virtual machine to the target GA144, using serdes to communicate with it, and then measure the power.
Maybe I'll find some time over Xmas :-)

Best regards,
Howerd

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

#16030

On 10/6/2012 8:47 AM, Howerd wrote:
 > On Saturday, October 6, 2012 8:17:09 AM UTC+2, Paul Rubin wrote:
 >> Howerd<how....@yahoo.co.uk>  writes:
 >>> always going to be an overhead when you interface a GA144 to a clocked
 >>> system - since the GA144 runs asynchronously it has to run a polling
 >>> loop.  OK, it could idle between characters,
 >>
 >> Can't it use edge or level sensitive triggering on the port pin
 >> listening to the rs232 signal?  Then the GA node should block until the
 >> bit actually arrives.

That is how many MCUs time an async data stream, but they have to have a 
timer running so they can record the time of each transition.  The GA144 
is capable of implementing timers the same way by monitoring a clock 
input, but GA doesn't seem too interested in using this sort of 
operation.  Chuck's work seems to focus on no clock at all which is not 
practical.  He tried that with his video circuits and found the VGA 
signal from software loop timing was not stable enough to work with his 
monitor, and that is a *relaxed* application.


 >> It also occurs to me, I don't see any way for a GA node to enter a sleep
 >> for a given amount of time (say 100 microseconds), other than with a
 >> full-speed busy loop and that 8 ma of power consumption.  Compare that
 >> with microcontrollers that have very low powered counter-timers.

The async processor goes to sleep until an input triggers it.  So why 
not use a clock for that input?  Then the GA144 core could utilize very 
little power just waiting.


 >> 8 ma is more than I expected for a single node anyway.  It means over 1
 >> amp for all 144 nodes going at once, or several watts of power.  I
 >> didn't realize the ga144 could use that much.  Or, maybe the 8ma
 >> includes other stuff too.

8 mA is too high for a single node.  One node is about 5 mW which would 
be around 3 mA I believe.  Still it's in that ballpark.  With all 144 
nodes running the power consumption is around three quarters of a Watt. 
  But the power consumption is instruction dependent, so you need to 
qualify that.  Just like the instruction rate is not 700 MIPS, but 
depends on your code the power consumption depends on your code too.


 >>> but a better way would be to use the on-chip SERDES instead of RS232

The SERDES is useless for talking to anything other than another GA 
device.  At least it is not supported in any other mode.  I'm not sure 
what protocol they use, but the clocking rate varies widely and so is 
hard to interface to other devices.  At least this is what I got out of 
the specs and lack of other info.


 >> The on-chip serdes is designed to only talk to other ga144's--do you
 >> mean to add a third ga144 to the board?
 >
 > Hi Paul,
 >
 >> ... I don't see any way for a GA node to enter a sleep
 >> for a given amount of time (say 100 microseconds), other than with a
 >> full-speed busy loop and that 8 ma of power consumption.
 > Yes - being asynchronous means that it has no idea of time.
 > But the only reason to wait for 100 ns is to synchronise with an 
external synchronous device - I'm stating the obvious here, but the 
GA144 is best suited to a fully asynchronous environment. If only the 
whole world was asynchronous - maybe it should be ;-)

To sync with a sync device it would just wait for the clock signal. 
Sync devices always use a clock.  The reason for waiting for some amount 
of time is to reduce power when you have nothing to do.  That means you 
need a timer to start the processor again.  That can be done by a timer 
node using an external clock.

The world will become async as soon as no one cares about speeds or times.


 >> The on-chip serdes is designed to only talk to other ga144's--do you
 >> mean to add a third ga144 to the board?
 > Nope - there are already two on the eval board, one of them is 
already acting as the interface to the synchronous world, via USB and 
serial comms. The two chips communicate via serdes.
 > But the serdes protocol is very simple, and self clocking (as it must 
be!), so maybe it could be implemented in software on another chip. The 
auto-baud software needs at least 19200 baud to not overflow the 18 bit 
counter, so a reasonably fast ARM should be able to keep up.

Are you mixing the SERDES and the software UART?  ARMs and many other 
processors implement software UARTs.  The SERDES runs at 100's of MHz. 
That is too fast for any CPU I am aware of to implement in software... 
assuming you knew the protocol.


 > There is a common theme here that I have noticed : The GA144 does 
things its own way, and it is difficult to interface it to the rest of 
the world which is doing things another way.

Duh, not only other digital systems, but lots of real world applications 
are hard to interface to the GA144.  Clocks tell us time and nearly 
everything is time based.


 > For example :
 > 1. It would be great, but non-trivial, to run a USB stack on a 
handful of F18's. Does this mean that the GA144 should have hardware USB 
support added, or that USB should changed for something simpler?

"Trivial"???  If that were true, GA would have done it already and put 
the code in the cores so it could boot from USB without the support 
chips from FTDI.


 > 2. SDRAM has a synchronous interface, but runs dynamically 
internally. I believe there are asynchronous RAMS, but thay are rare. 
Should the GA144 add a fast SDRAM module, or should the SDRAM chip be 
modified?

Async RAMs are not "rare", in fact that is what is on the GA144 eval 
board.  They aren't dense and they can be expensive, but the ones GA 
picked aren't too bad at around $5.

The problem with DRAMs (the generic term for all dynamic memory) is that 
they must be operated with both minimums and maximums on the timing 
signals.  The maximums are not too hard to meet, but typically designers 
want to run the DRAMs as fast as possible.  In the old days when DRAM 
interfaces were async (meaning no clock, not lack of timing constraints) 
it could be hard to optimize this interface.  SDRAM added a clock and 
gave the interface specific timing related to that clock.  I tried to 
design an SDRAM software interface for the GA144 and the big problem is 
trying to make the processors run the interface anywhere close to full 
speed.  I think I could get it to run at 50 MHz, but I can't be sure 
because they don't provide all the timing data for this sort of design. 
  But 50 MHz is not even half speed for the old single data rate SDRAM 
and is nowhere near the rates of DDR, DDR2 or DDR3.

Don't try to turn this into a problem with the memory devices.  They 
work just fine.  The problem is that GA won't put a proper memory 
interface on the chip which will run at memory speeds.  Instead they use 
software which runs much slower than optimal.


 > 3. Most software is written with the assumption of large amounts of 
flat addressed memory ( doesn't the 1M byte DOS limit feel really tight? 
). But you can write software in very small, colorForth size chunks. If 
you spread these around a few F18's maybe you can create something 
really cool.

Yes, there are apps which will suit the GA144 small memory model, but 
they aren't the same apps that are typically running on >1MB devices. 
Remember the memory chunks are only 64 words per processor for both 
program and data.  So even with 144 of them you only have some 9 kWords 
of memory on chip.  Otherwise you have to load the programs and data 
from external memory.  Memory can be a real bottle neck unless you are 
running a pretty special app that fits the GA144.  I think digital 
receivers are one class of app that might work ok on this device, but I 
don't know of any others.


 > Going back to the original point - yes the GA144 can wait in an idle 
state for a pin to change state, but it must poll to get timings. Maybe 
a neighbouring F18 could wait for a change of state on a fixed clock 
signal, say at 16 * baudrate, then pass this on. This should get the 
power down to a minimum. Then again, maybe fixed baud rate is not the 
right way to talk to a GA144...

Yes, an external clock and a timer node is the way to get timing data. 
But to suggest that you shoudldn't talk to the GA144 with a fixed baud 
rate is not very realistic.  What part of the world is going to change 
to suit the GA144?

One way to do this is to work with a two wire interface, one wire for 
clock and one wire for data.  Whoever is sending the data sends the 
clock and the receiver has the option of slowing the clock like in I2C. 
  Or they could just add some hardware to handle this properly for 
whatever interface you don't like.


 > What would be interesting is to move the polyForth virtual machine to 
the target GA144, using serdes to communicate with it, and then measure 
the power.
 > Maybe I'll find some time over Xmas :-)
 >
 > Best regards,
 > Howerd

Rather than play with the board to measure things that don't likely 
matter to the world, what do you think you could use this device for 
that would be a better implementation than other devices?

Rick

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web