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

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

new GA app notes

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

Contents

  new GA app notes Paul Rubin <no.email@nospam.invalid> - 2012-05-24 22:28 -0700
    Re: new GA app notes vandys@vsta.org - 2012-05-25 17:30 +0000
      Re: new GA app notes Rimas Avizienis <rimas@cnmat.berkeley.edu> - 2012-06-07 17:10 -0700
    Re: new GA app notes Mark Wills <markrobertwills@yahoo.co.uk> - 2012-06-14 06:08 -0700
      Re: new GA app notes Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-14 18:16 +0000
        Re: new GA app notes Coos Haak <chforth@hccnet.nl> - 2012-06-14 20:04 +0200
        Re: new GA app notes Mark Wills <markrobertwills@yahoo.co.uk> - 2012-06-14 11:58 -0700
          Re: new GA app notes rickman <gnuarm@gmail.com> - 2012-06-14 18:32 -0700
        Re: new GA app notes David Kuehling <dvdkhlng@gmx.de> - 2012-06-21 03:38 +0200
          Re: new GA app notes Paul Rubin <no.email@nospam.invalid> - 2012-06-20 19:27 -0700
            Re: new GA app notes rickman <gnuarm@gmail.com> - 2012-06-21 16:40 -0700
              Re: new GA app notes vandys@vsta.org - 2012-06-21 23:52 +0000
                Re: new GA app notes rickman <gnuarm@gmail.com> - 2012-06-21 17:07 -0700
                Re: new GA app notes rickman <gnuarm@gmail.com> - 2012-06-21 18:10 -0700
                  Re: new GA app notes Paul Rubin <no.email@nospam.invalid> - 2012-06-21 19:34 -0700
                    Re: new GA app notes rickman <gnuarm@gmail.com> - 2012-06-22 10:38 -0700
                      Re: new GA app notes vandys@vsta.org - 2012-06-22 18:17 +0000
                        Re: new GA app notes Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-22 22:08 +0200
                  Re: new GA app notes Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-22 11:31 +0000
          Re: new GA app notes Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-21 08:46 +0000

#12440 — new GA app notes

FYI, per the GA tech blog, I see there are a couple of new or revised
app notes on the GA site:

* http://www.greenarraychips.com/home/documents/greg/AN001-120510-MD5.pdf 

This is a revision of the earlier MD5 app note, that supplies more
detail than the old version.  That's a very welcome addition to the
scarce amount of existing GA example code, and the exposition is very
good, though this still seems like a painful way to do MD5.

* http://www.greenarraychips.com/home/documents/greg/AN008-120510-ACCEL.pdf 

This is about interfacing a 3-axis accelerometer to the GA board,
programmed using Polyforth running in a virtual machine on the GA chip.
Polyforth puts all its stack, variables, program etc. in external SRAM
controlled by GA nodes, with resulting ram cycle time of about 4 mhz.  A
Polyforth DUP uses two cycles or about 0.5 usec, very slow compared to
the GA.  The note mentions one can optimize stuff in GA native code, but
I wonder if there is enough code space for that.  The Polyforth code can
be fairly large, due to the external ram.  I wonder what happened to the
eForth which the board supposedly comes with.

A couple of other app notes are listed as not yet released:

* AN006 Pipelined SHA-256 ... Not Yet Released

This sounds interesting.  I thought about how to do this back when we
were talking about bitcoins, but the implementations I could imagine
were all pretty inefficient.  So I'm looking forward to seeing how the
experts do it.

* AN007 A Bit-Banged 10baseT NIC ... Not Yet Released

I guess that can be useful for uploading sensor readings, or if you've
got a VM-interpreted program processing data.  Otherwise even if you can
do stuff like ethernet frames and checksums in GA software, where will
the data come from that will fill actual packets?  I guess the 10baseT
speed confirms that 100 mbit is out of reach (this question came up in
some clf discussion a few weeks ago).

[toc] | [next] | [standalone]

#12454

Paul Rubin <no.email@nospam.invalid> wrote:
> This is a revision of the earlier MD5 app note, that supplies more
> detail than the old version.  That's a very welcome addition to the
> scarce amount of existing GA example code, and the exposition is very
> good, though this still seems like a painful way to do MD5.

Can somebody with an actual board run the code, verify its a correct MD5,
and give the group some performance numbers?

(Thanks in advance.)

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

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

#12765

I don't yet have an eval board, but I did try out the code presented in the MD5 app note, and it functions correctly (produces a correct md5 hash for the provided test message) executing in the software simulator (softsim).  

I'm not sure why GreenArrays didn't provide an image file (aka OkadWork.cf) that included the code from the app note, but I've gone ahead and put mine online here:

http://www.cs.berkeley.edu/~rimas/ga144/md5/OkadWork.cf

To run the simulation, copy OkadWork.cf into your arrayForth directory, start arrayForth and then type "softsim" to start the simulator.  Besides entering the code from the app note, I had to change a few lines to get the code loaded into softsim:

at the end of block 148, I changed: "216 load" to "902 load"
at the start of block 200, i changed "user f18 code reclaim" to "user f18 code reclaim 900 load"

Enjoy!

-rimas

On Friday, May 25, 2012 10:30:00 AM UTC-7, (unknown) wrote:
> Can somebody with an actual board run the code, verify its a correct MD5,
> and give the group some performance numbers?
> 
> (Thanks in advance.)
> 
> -- 
> Andy Valencia
> Home page: http://www.vsta.org/andy/
> To contact me: http://www.vsta.org/contact/andy.html

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

#12976

On May 25, 6:28 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> FYI, per the GA tech blog, I see there are a couple of new or revised
> app notes on the GA site:
>
> *http://www.greenarraychips.com/home/documents/greg/AN001-120510-MD5.pdf
>
> This is a revision of the earlier MD5 app note, that supplies more
> detail than the old version.  That's a very welcome addition to the
> scarce amount of existing GA example code, and the exposition is very
> good, though this still seems like a painful way to do MD5.
>
> *http://www.greenarraychips.com/home/documents/greg/AN008-120510-ACCEL...
>
> This is about interfacing a 3-axis accelerometer to the GA board,
> programmed using Polyforth running in a virtual machine on the GA chip.
> Polyforth puts all its stack, variables, program etc. in external SRAM
> controlled by GA nodes, with resulting ram cycle time of about 4 mhz.  A
> Polyforth DUP uses two cycles or about 0.5 usec, very slow compared to
> the GA.  The note mentions one can optimize stuff in GA native code, but
> I wonder if there is enough code space for that.  The Polyforth code can
> be fairly large, due to the external ram.  I wonder what happened to the
> eForth which the board supposedly comes with.
>
> A couple of other app notes are listed as not yet released:
>
> * AN006 Pipelined SHA-256 ... Not Yet Released
>
> This sounds interesting.  I thought about how to do this back when we
> were talking about bitcoins, but the implementations I could imagine
> were all pretty inefficient.  So I'm looking forward to seeing how the
> experts do it.
>
> * AN007 A Bit-Banged 10baseT NIC ... Not Yet Released
>
> I guess that can be useful for uploading sensor readings, or if you've
> got a VM-interpreted program processing data.  Otherwise even if you can
> do stuff like ethernet frames and checksums in GA software, where will
> the data come from that will fill actual packets?  I guess the 10baseT
> speed confirms that 100 mbit is out of reach (this question came up in
> some clf discussion a few weeks ago).

I note with the interest some premlininary information on the F18B on
the GA website:

http://www.greenarraychips.com/home/documents/roadmap.html

128 words of memory, which is room enough for ~512 instructions, plus
20 words of stacks.

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

#12978

In article <e887b111-30f1-4240-b4cf-de619ebf053e@cu1g2000vbb.googlegroups.com>,
Mark Wills  <markrobertwills@yahoo.co.uk> wrote:
>On May 25, 6:28=A0am, Paul Rubin <no.em...@nospam.invalid> wrote:
>> FYI, per the GA tech blog, I see there are a couple of new or revised
>> app notes on the GA site:
>>
>> *http://www.greenarraychips.com/home/documents/greg/AN001-120510-MD5.pdf
>>
>> This is a revision of the earlier MD5 app note, that supplies more
>> detail than the old version. =A0That's a very welcome addition to the
>> scarce amount of existing GA example code, and the exposition is very
>> good, though this still seems like a painful way to do MD5.
>>
>> *http://www.greenarraychips.com/home/documents/greg/AN008-120510-ACCEL...
>>
>> This is about interfacing a 3-axis accelerometer to the GA board,
>> programmed using Polyforth running in a virtual machine on the GA chip.
>> Polyforth puts all its stack, variables, program etc. in external SRAM
>> controlled by GA nodes, with resulting ram cycle time of about 4 mhz. =A0=
>A
>> Polyforth DUP uses two cycles or about 0.5 usec, very slow compared to
>> the GA. =A0The note mentions one can optimize stuff in GA native code, bu=
>t
>> I wonder if there is enough code space for that. =A0The Polyforth code ca=
>n
>> be fairly large, due to the external ram. =A0I wonder what happened to th=
>e
>> eForth which the board supposedly comes with.
>>
>> A couple of other app notes are listed as not yet released:
>>
>> * AN006 Pipelined SHA-256 ... Not Yet Released
>>
>> This sounds interesting. =A0I thought about how to do this back when we
>> were talking about bitcoins, but the implementations I could imagine
>> were all pretty inefficient. =A0So I'm looking forward to seeing how the
>> experts do it.
>>
>> * AN007 A Bit-Banged 10baseT NIC ... Not Yet Released
>>
>> I guess that can be useful for uploading sensor readings, or if you've
>> got a VM-interpreted program processing data. =A0Otherwise even if you ca=
>n
>> do stuff like ethernet frames and checksums in GA software, where will
>> the data come from that will fill actual packets? =A0I guess the 10baseT
>> speed confirms that 100 mbit is out of reach (this question came up in
>> some clf discussion a few weeks ago).
>
>I note with the interest some premlininary information on the F18B on
>the GA website:
>
>http://www.greenarraychips.com/home/documents/roadmap.html
>
>128 words of memory, which is room enough for ~512 instructions, plus
>20 words of stacks.

How is that different from F18A?
64 instructions in RAM
64 instructions in ROM
10 items on data stack
10 items on data return stack

(And the chip could not be claimed upwards compatible, if the size
of the circular stack would change)

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#12979

Op 14 Jun 2012 18:16:46 GMT schreef Albert van der Horst:

> In article <e887b111-30f1-4240-b4cf-de619ebf053e@cu1g2000vbb.googlegroups.com>,
> Mark Wills  <markrobertwills@yahoo.co.uk> wrote:
>>On May 25, 6:28=A0am, Paul Rubin <no.em...@nospam.invalid> wrote:
>>> FYI, per the GA tech blog, I see there are a couple of new or revised
>>> app notes on the GA site:
>>>
>>> *http://www.greenarraychips.com/home/documents/greg/AN001-120510-MD5.pdf
>>>
>>> This is a revision of the earlier MD5 app note, that supplies more
>>> detail than the old version. =A0That's a very welcome addition to the
>>> scarce amount of existing GA example code, and the exposition is very
>>> good, though this still seems like a painful way to do MD5.
>>>
>>> *http://www.greenarraychips.com/home/documents/greg/AN008-120510-ACCEL...
>>>
>>> This is about interfacing a 3-axis accelerometer to the GA board,
>>> programmed using Polyforth running in a virtual machine on the GA chip.
>>> Polyforth puts all its stack, variables, program etc. in external SRAM
>>> controlled by GA nodes, with resulting ram cycle time of about 4 mhz. =A0=
>>A
>>> Polyforth DUP uses two cycles or about 0.5 usec, very slow compared to
>>> the GA. =A0The note mentions one can optimize stuff in GA native code, bu=
>>t
>>> I wonder if there is enough code space for that. =A0The Polyforth code ca=
>>n
>>> be fairly large, due to the external ram. =A0I wonder what happened to th=
>>e
>>> eForth which the board supposedly comes with.
>>>
>>> A couple of other app notes are listed as not yet released:
>>>
>>> * AN006 Pipelined SHA-256 ... Not Yet Released
>>>
>>> This sounds interesting. =A0I thought about how to do this back when we
>>> were talking about bitcoins, but the implementations I could imagine
>>> were all pretty inefficient. =A0So I'm looking forward to seeing how the
>>> experts do it.
>>>
>>> * AN007 A Bit-Banged 10baseT NIC ... Not Yet Released
>>>
>>> I guess that can be useful for uploading sensor readings, or if you've
>>> got a VM-interpreted program processing data. =A0Otherwise even if you ca=
>>n
>>> do stuff like ethernet frames and checksums in GA software, where will
>>> the data come from that will fill actual packets? =A0I guess the 10baseT
>>> speed confirms that 100 mbit is out of reach (this question came up in
>>> some clf discussion a few weeks ago).
>>
>>I note with the interest some premlininary information on the F18B on
>>the GA website:
>>
>>http://www.greenarraychips.com/home/documents/roadmap.html
>>
>>128 words of memory, which is room enough for ~512 instructions, plus
>>20 words of stacks.
> 
> How is that different from F18A?
> 64 instructions in RAM
> 64 instructions in ROM
> 10 items on data stack
> 10 items on data return stack
> 
> (And the chip could not be claimed upwards compatible, if the size
> of the circular stack would change)
> 
> Groetjes Albert
> 
> --

I see two differences between F18A and F18B:
The P incrementer in the former is described as holding 7 bits and the
latter 6. I think its 7 (2x64 adresses).
The B register in the former would hold 9 bits and the latter 8. I think
its 9 (half word).
Both are likely type mistakes.

-- 
Coos

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

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

#12980

On Jun 14, 7:16 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <e887b111-30f1-4240-b4cf-de619ebf0...@cu1g2000vbb.googlegroups.com>,
> Mark Wills  <markrobertwi...@yahoo.co.uk> wrote:
>
>
>
>
>
>
>
>
>
> >On May 25, 6:28=A0am, Paul Rubin <no.em...@nospam.invalid> wrote:
> >> FYI, per the GA tech blog, I see there are a couple of new or revised
> >> app notes on the GA site:
>
> >> *http://www.greenarraychips.com/home/documents/greg/AN001-120510-MD5.pdf
>
> >> This is a revision of the earlier MD5 app note, that supplies more
> >> detail than the old version. =A0That's a very welcome addition to the
> >> scarce amount of existing GA example code, and the exposition is very
> >> good, though this still seems like a painful way to do MD5.
>
> >> *http://www.greenarraychips.com/home/documents/greg/AN008-120510-ACCEL...
>
> >> This is about interfacing a 3-axis accelerometer to the GA board,
> >> programmed using Polyforth running in a virtual machine on the GA chip.
> >> Polyforth puts all its stack, variables, program etc. in external SRAM
> >> controlled by GA nodes, with resulting ram cycle time of about 4 mhz. =A0=
> >A
> >> Polyforth DUP uses two cycles or about 0.5 usec, very slow compared to
> >> the GA. =A0The note mentions one can optimize stuff in GA native code, bu=
> >t
> >> I wonder if there is enough code space for that. =A0The Polyforth code ca=
> >n
> >> be fairly large, due to the external ram. =A0I wonder what happened to th=
> >e
> >> eForth which the board supposedly comes with.
>
> >> A couple of other app notes are listed as not yet released:
>
> >> * AN006 Pipelined SHA-256 ... Not Yet Released
>
> >> This sounds interesting. =A0I thought about how to do this back when we
> >> were talking about bitcoins, but the implementations I could imagine
> >> were all pretty inefficient. =A0So I'm looking forward to seeing how the
> >> experts do it.
>
> >> * AN007 A Bit-Banged 10baseT NIC ... Not Yet Released
>
> >> I guess that can be useful for uploading sensor readings, or if you've
> >> got a VM-interpreted program processing data. =A0Otherwise even if you ca=
> >n
> >> do stuff like ethernet frames and checksums in GA software, where will
> >> the data come from that will fill actual packets? =A0I guess the 10baseT
> >> speed confirms that 100 mbit is out of reach (this question came up in
> >> some clf discussion a few weeks ago).
>
> >I note with the interest some premlininary information on the F18B on
> >the GA website:
>
> >http://www.greenarraychips.com/home/documents/roadmap.html
>
> >128 words of memory, which is room enough for ~512 instructions, plus
> >20 words of stacks.
>
> How is that different from F18A?
> 64 instructions in RAM
> 64 instructions in ROM
> 10 items on data stack
> 10 items on data return stack
>
> (And the chip could not be claimed upwards compatible, if the size
> of the circular stack would change)
>
> Groetjes Albert
>
> --
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=nhttp://home.hccnet.nl/a.w.m.van.der.horst

Hmmm... I was under the impression it had twice the memory. Could be
wrong. So, er, what *is* the difference then?

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

#12985

On Jun 14, 2:58 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> On Jun 14, 7:16 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> wrote:
>
>
>
>
>
>
>
>
>
> > In article <e887b111-30f1-4240-b4cf-de619ebf0...@cu1g2000vbb.googlegroups.com>,
> > Mark Wills  <markrobertwi...@yahoo.co.uk> wrote:
>
> > >On May 25, 6:28=A0am, Paul Rubin <no.em...@nospam.invalid> wrote:
> > >> FYI, per the GA tech blog, I see there are a couple of new or revised
> > >> app notes on the GA site:
>
> > >> *http://www.greenarraychips.com/home/documents/greg/AN001-120510-MD5.pdf
>
> > >> This is a revision of the earlier MD5 app note, that supplies more
> > >> detail than the old version. =A0That's a very welcome addition to the
> > >> scarce amount of existing GA example code, and the exposition is very
> > >> good, though this still seems like a painful way to do MD5.
>
> > >> *http://www.greenarraychips.com/home/documents/greg/AN008-120510-ACCEL...
>
> > >> This is about interfacing a 3-axis accelerometer to the GA board,
> > >> programmed using Polyforth running in a virtual machine on the GA chip.
> > >> Polyforth puts all its stack, variables, program etc. in external SRAM
> > >> controlled by GA nodes, with resulting ram cycle time of about 4 mhz. =A0=
> > >A
> > >> Polyforth DUP uses two cycles or about 0.5 usec, very slow compared to
> > >> the GA. =A0The note mentions one can optimize stuff in GA native code, bu=
> > >t
> > >> I wonder if there is enough code space for that. =A0The Polyforth code ca=
> > >n
> > >> be fairly large, due to the external ram. =A0I wonder what happened to th=
> > >e
> > >> eForth which the board supposedly comes with.
>
> > >> A couple of other app notes are listed as not yet released:
>
> > >> * AN006 Pipelined SHA-256 ... Not Yet Released
>
> > >> This sounds interesting. =A0I thought about how to do this back when we
> > >> were talking about bitcoins, but the implementations I could imagine
> > >> were all pretty inefficient. =A0So I'm looking forward to seeing how the
> > >> experts do it.
>
> > >> * AN007 A Bit-Banged 10baseT NIC ... Not Yet Released
>
> > >> I guess that can be useful for uploading sensor readings, or if you've
> > >> got a VM-interpreted program processing data. =A0Otherwise even if you ca=
> > >n
> > >> do stuff like ethernet frames and checksums in GA software, where will
> > >> the data come from that will fill actual packets? =A0I guess the 10baseT
> > >> speed confirms that 100 mbit is out of reach (this question came up in
> > >> some clf discussion a few weeks ago).
>
> > >I note with the interest some premlininary information on the F18B on
> > >the GA website:
>
> > >http://www.greenarraychips.com/home/documents/roadmap.html
>
> > >128 words of memory, which is room enough for ~512 instructions, plus
> > >20 words of stacks.
>
> > How is that different from F18A?
> > 64 instructions in RAM
> > 64 instructions in ROM
> > 10 items on data stack
> > 10 items on data return stack
>
> > (And the chip could not be claimed upwards compatible, if the size
> > of the circular stack would change)
>
> > Groetjes Albert
>
> > --
> > --
> > Albert van der Horst, UTRECHT,THE NETHERLANDS
> > Economic growth -- being exponential -- ultimately falters.
> > albert@spe&ar&c.xs4all.nl &=nhttp://home.hccnet.nl/a.w.m.van.der.horst
>
> Hmmm... I was under the impression it had twice the memory. Could be
> wrong. So, er, what *is* the difference then?

From the F18B data sheet...

IMPROVEMENTS in F18B
 Faster instructions
 Faster memory and port operations
 New addressing scheme allows slot 1 instructions to reach all
destinations
 Read of pin returns an instruction
 Additional improvements in I/O

OVERVIEW
The F18B is an evolutionary improvement of the F18A, offering higher
speed and shorter code.

So the difference is mostly transparent to the user but it works a
little better.

Rick

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

#13120

>>>>> "Albert" == Albert van der Horst <albert@spenarnc.xs4all.nl> writes:

>> 
>> I note with the interest some premlininary information on the F18B on
>> the GA website:
>> 
>> http://www.greenarraychips.com/home/documents/roadmap.html
>> 
>> 128 words of memory, which is room enough for ~512 instructions, plus
>> 20 words of stacks.

> How is that different from F18A?  64 instructions in RAM 64
> instructions in ROM 10 items on data stack 10 items on data return
> stack

Shouldn't that read

64 words of RAM (up to 256 instructions)
64 words in ROM (up to 256 instructions)

I.e. only factor of two increase.

cheers,

David
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

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

#13121

David Kuehling <dvdkhlng@gmx.de> writes:
> 64 words of RAM (up to 256 instructions)
> 64 words in ROM (up to 256 instructions)
>
> I.e. only factor of two increase.

There is no increase at all.  It's exactly the same as the F18A.

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

#13144

On Jun 20, 10:27 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> David Kuehling <dvdkh...@gmx.de> writes:
> > 64 words of RAM (up to 256 instructions)
> > 64 words in ROM (up to 256 instructions)
>
> > I.e. only factor of two increase.
>
> There is no increase at all.  It's exactly the same as the F18A.

There was no increas in the size of the memories, what changed is the
memory map.  In the F18A both RAM and ROM map to a space that is twice
the size of the physical memory and wraps around the full 256 word
space.  In the F18B the mapped space is the same size as the physical
memory and wraps in the smaller space.  I expect this can make some
difference in programs.  If nothing else the actual addresses of ROM
and I/O change.

This is why the P register incrementer and the B register are one less
bit wide in the F18B than in the F18A.  The incrementer only
increments within the address space it is pointing to.  Since the
address spaces are half the size, the incrementer is one bit smaller.
The address of the I/O is x80 instead of x100 so the B register is
only 8 bits instead of 9.

I would love to see larger memory spaces, but alas, that is not to be
unless someone rolls their own chip.

Rick

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

#13145

rickman <gnuarm@gmail.com> wrote:
> I would love to see larger memory spaces, but alas, that is not to be
> unless someone rolls their own chip.

If I was looking for a project, I would certainly look at mapping the GA
techniques onto an FPGA CPU.  I'd be curious how many cells I could achieve
with FPGA-implemented RAM on each cell.  Perhaps a 6x6 grid with 4k per node?
100 Mhz instruction rate?  Modern FPGA's have pretty impressive density and
clock rates.

I suspect that many of GA's inventions in inter-CPU processing would be
easier to explore when every design is not entirely dominated by memory
starvation.

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

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

#13146

On Jun 21, 7:52 pm, van...@vsta.org wrote:
> rickman <gnu...@gmail.com> wrote:
> > I would love to see larger memory spaces, but alas, that is not to be
> > unless someone rolls their own chip.
>
> If I was looking for a project, I would certainly look at mapping the GA
> techniques onto an FPGA CPU.  I'd be curious how many cells I could achieve
> with FPGA-implemented RAM on each cell.  Perhaps a 6x6 grid with 4k per node?
> 100 Mhz instruction rate?  Modern FPGA's have pretty impressive density and
> clock rates.
>
> I suspect that many of GA's inventions in inter-CPU processing would be
> easier to explore when every design is not entirely dominated by memory
> starvation.
>
> --
> Andy Valencia
> Home page:http://www.vsta.org/andy/
> To contact me:http://www.vsta.org/contact/andy.html

But what you describe is "starved" in other ways.  The speed starts 7
times slower, the latency on I/O waits is orders of magnitude larger
and the cost per processor goes way up.

Heck, for most apps as they are typically written, even a 4k memory
will result in "starvation".  Look at all the articles talking about
the "memory wall" for quad core CPUs.  It is as if no one thinks there
are any other ways to design a computer.  But then this is apples to
oranges...  embedded vs. desktop.

Rick

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

#13147

On Jun 21, 7:52 pm, van...@vsta.org wrote:
> rickman <gnu...@gmail.com> wrote:
> > I would love to see larger memory spaces, but alas, that is not to be
> > unless someone rolls their own chip.
>
> If I was looking for a project, I would certainly look at mapping the GA
> techniques onto an FPGA CPU.  I'd be curious how many cells I could achieve
> with FPGA-implemented RAM on each cell.  Perhaps a 6x6 grid with 4k per node?
> 100 Mhz instruction rate?  Modern FPGA's have pretty impressive density and
> clock rates.
>
> I suspect that many of GA's inventions in inter-CPU processing would be
> easier to explore when every design is not entirely dominated by memory
> starvation.
>
> --
> Andy Valencia
> Home page:http://www.vsta.org/andy/
> To contact me:http://www.vsta.org/contact/andy.html

Oh, one thing I forgot to mention is that if you build your own
version of the F18 you need to roll your own tools.  That is the one
restriction in the tool license, using the tools with clone
processors.  It's a no-no.

Rick

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

#13149

rickman <gnuarm@gmail.com> writes:
> Oh, one thing I forgot to mention is that if you build your own
> version of the F18 you need to roll your own tools.  That is the one
> restriction in the tool license, using the tools with clone
> processors.  It's a no-no.

You mean the Okad tools were actually released?  I wasn't sure of that,
and it's not really obvious.  Are they released in source form, which I
guess means colorforth semi-tokenized files?

Certainly I think if someone tried building an F18 in an FPGA, they'd
just use the regular synthesis tools from the FPGA vendor.

Bernd Paysan's B16 is actually pretty close to this, I think.

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

#13166

On Jun 21, 10:34 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> rickman <gnu...@gmail.com> writes:
> > Oh, one thing I forgot to mention is that if you build your own
> > version of the F18 you need to roll your own tools.  That is the one
> > restriction in the tool license, using the tools with clone
> > processors.  It's a no-no.
>
> You mean the Okad tools were actually released?  I wasn't sure of that,
> and it's not really obvious.  Are they released in source form, which I
> guess means colorforth semi-tokenized files?
>
> Certainly I think if someone tried building an F18 in an FPGA, they'd
> just use the regular synthesis tools from the FPGA vendor.
>
> Bernd Paysan's B16 is actually pretty close to this, I think.

I'm not talking about the HDL tools, I mean the software development
tools.  They don't want you to write code for your processor using
their tools.  They say this clearly in the license and I got it
directly from Greg Bailey in an email when I asked about rolling my
own single core for apps that don't justify the GA144.  Actually he
said they would want some sort of royalty rather than just "don't do
it".

Rick

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

#13167

rickman <gnuarm@gmail.com> wrote:
> I'm not talking about the HDL tools, I mean the software development
> tools.  They don't want you to write code for your processor using
> their tools.

Heck, I'm sure if you used their CPU inventions in your FPGA design, you'd owe
them royalties anyway.  I guess if/when you got to that point, you could include
tools in the negotiation.  For such negotiations to happen implies that you
got your FPGA design to a place where it's worth the trouble.  You've thus
already invented some of your own stuff, and cross-IP licensing would
almost certainly be on the table.

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

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

#13175

vandys@vsta.org wrote:
> got your FPGA design to a place where it's worth the trouble.  You've
> thus already invented some of your own stuff, and cross-IP licensing
> would almost certainly be on the table.

Depends on how you protect your stuff.  Chuck has his strange patent 
portfolio, but I didn't patent anything in the b16, nor do I want to.  
If you like to take any idea from there, feel free.  I got inspired by 
c18, and I don't have any problems if some of my ideas went back into 
GA144 or whereever else they go.  That's the hole point of innovation: 
Copy+improve.  We live in a crazy system that presumes that innovation 
is fostered by preventing the copy step, and that giving patent trolls 
the power over this process.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#13158

In article <6cf62c02-672d-42a7-9701-fa4d6f36deae@j25g2000yqn.googlegroups.com>,
rickman  <gnuarm@gmail.com> wrote:
>
>Oh, one thing I forgot to mention is that if you build your own
>version of the F18 you need to roll your own tools.  That is the one
>restriction in the tool license, using the tools with clone
>processors.  It's a no-no.

Given the quality of the tools, that could be a blessing in disguise.
Anyway, Leon Konings has advanced well with a toolset written in factor.
It can run the parpi program under emulation.

>
>Rick


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#13124

In article <87y5nhxx3o.fsf@snail.Pool>,
David Kuehling  <dvdkhlng@gmx.de> wrote:
>>>>>> "Albert" == Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>
>>>
>>> I note with the interest some premlininary information on the F18B on
>>> the GA website:
>>>
>>> http://www.greenarraychips.com/home/documents/roadmap.html
>>>
>>> 128 words of memory, which is room enough for ~512 instructions, plus
>>> 20 words of stacks.
>
>> How is that different from F18A?  64 instructions in RAM 64
>> instructions in ROM 10 items on data stack 10 items on data return
>> stack
>
>Shouldn't that read
>
>64 words of RAM (up to 256 instructions)
>64 words in ROM (up to 256 instructions)

You're right.

>
>I.e. only factor of two increase.

Sorry, that is no increase.

>
>cheers,
>
>David
>--
>GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
>Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [standalone]

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

csiph-web