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

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

GA144 article

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

Contents

  GA144 article Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-18 03:48 -0700
    Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-19 10:51 -0700
      Re: GA144 article Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-20 01:30 -0700
        Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-20 01:48 -0700
          Re: GA144 article Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-20 03:25 -0700
          Re: GA144 article Syd Rumpo <usenet@neonica.co.uk> - 2012-07-20 11:59 +0100
        Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-22 18:59 -0700
          Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-22 19:16 -0700
            Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-22 19:31 -0700
              Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-22 20:08 -0700
                Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-23 16:24 -0700
                  Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-23 22:33 -0700
                    Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-24 14:04 -0700
              Re: GA144 article vandys@vsta.org - 2012-07-23 03:34 +0000
              Re: GA144 article Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-23 14:11 +0200
                Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-23 16:47 -0700
                Re: GA144 article "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2012-07-24 20:11 -0700
            Re: GA144 article Richard Owlett <rowlett@pcnetinc.com> - 2012-07-23 02:04 -0500
    Re: GA144 article Daniel Kalny <dkalny@seznam.cz> - 2012-07-24 02:37 -0700
      Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-24 03:12 -0700
        Re: GA144 article stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-24 10:36 +0000
          Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-24 10:28 -0700
            Re: GA144 article Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-24 22:12 +0000
        Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-24 14:49 -0700
          Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-26 13:25 -0700
            Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-27 13:17 -0700
              Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-27 14:31 -0700
                Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-27 22:02 -0700
                  Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-28 23:03 -0700
                    Re: GA144 article marko <marko@marko.marko> - 2012-07-30 09:12 +1000
                      Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-31 01:09 -0700
                        Re: GA144 article marko <marko@marko.marko> - 2012-08-01 00:19 +1000
                          Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-31 09:59 -0700
                            Re: GA144 article marko <marko@marko.marko> - 2012-08-01 10:13 +1000
                        Re: GA144 article Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-01 00:59 +0200
                          Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-31 16:54 -0700
                            Re: GA144 article Luca Saiu <positron@gnu.org> - 2012-08-04 10:46 +0200
                              Re: GA144 article rickman <gnuarm@gmail.com> - 2012-08-05 11:04 -0700
                                Re: GA144 article Luca Saiu <positron@gnu.org> - 2012-08-06 02:02 +0200
                                Re: GA144 article Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-06 02:16 -0700
                    Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-30 08:23 -0700
                      Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-30 21:33 -0700
                        Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-31 01:51 -0700
                          Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-31 11:48 -0700
                            Re: GA144 article rickman <gnuarm@gmail.com> - 2012-07-31 14:54 -0700
                              Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-07-31 16:09 -0700
                                Re: GA144 article rickman <gnuarm@gmail.com> - 2012-08-01 12:57 -0700
                                  Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-08-01 14:16 -0700
                                    Re: GA144 article vandys@vsta.org - 2012-08-01 22:32 +0000
                                    Re: GA144 article rickman <gnuarm@gmail.com> - 2012-08-01 16:03 -0700
                                      Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-08-01 16:13 -0700
                            Re: GA144 article rickman <gnuarm@gmail.com> - 2012-08-01 16:10 -0700
                              Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-08-01 22:18 -0700
                                Re: GA144 article rickman <gnuarm@gmail.com> - 2012-08-02 11:47 -0700
                                  Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-08-02 14:32 -0700
                                    Re: GA144 article rickman <gnuarm@gmail.com> - 2012-08-02 16:01 -0700
                                      Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-08-02 16:38 -0700
                                        Re: GA144 article rickman <gnuarm@gmail.com> - 2012-08-03 08:40 -0700
                                          Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-08-03 09:19 -0700
                                            Re: GA144 article rickman <gnuarm@gmail.com> - 2012-08-03 11:15 -0700
                                              Re: GA144 article Paul Rubin <no.email@nospam.invalid> - 2012-08-05 15:50 -0700
                                                Re: GA144 article Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-06 02:21 -0700

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

#14348

On Tue, 24 Jul 2012 03:12:36 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>Have you actually tried programming it and found 64 words to be enough
>to do anything interesting?  Node to node communication is quite a pain
>after all.  

The Intellasys people found that node-to-node communication, which
they called floorplanning, took half the software time, even when
they were used to it. A corollary of this is that floorplanning may
take an even higher proportion of your time when you start serious
software for these beasts.

It is called floorplanning because every time you move a node, you
upset all the neighbours. Floorplanning is part of the design
procedure, and it is not easy.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#14350

stephenXXX@mpeforth.com (Stephen Pelc) writes:
> It is called floorplanning because every time you move a node, you
> upset all the neighbours. Floorplanning is part of the design
> procedure, and it is not easy.

Maybe a program could do it.

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

#14353

In article <7xboj5ukzg.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>stephenXXX@mpeforth.com (Stephen Pelc) writes:
>> It is called floorplanning because every time you move a node, you
>> upset all the neighbours. Floorplanning is part of the design
>> procedure, and it is not easy.
>
>Maybe a program could do it.

We did some automation of this in behalf of parpi. Then we were
punished, because the tools interfered with the next release of
Okad. Actually parpi still only works on one of the earlier
Okads.

And I totally believe it, that the througput time of operations
consists for a large part of passing data to the next node.

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]

#14354

On Tuesday, July 24, 2012 6:12:36 AM UTC-4, Paul Rubin wrote:
> Daniel Kalny <dkalny@seznam.cz> writes:
> > The GA144 allows for up to 256 arrayForth words for one node. This
> > seems to me more than enough for a definition of a single Forth word.
> 
> Have you actually tried programming it and found 64 words to be enough
> to do anything interesting?  Node to node communication is quite a pain
> after all.  
> 
> The "up to 256 Forth words" is misleading, since the GA has 18-bit data
> words and 5-bit instructions, so a lot of the time you get just 3
> instructions per word.  Maybe even more annoyingly, any literal constant
> (like 1 or -1) takes up an entire word for the immediate data, and also
> often several instruction slots.  Writing contorted enough code lets you
> fill more of the slots than you could writing straightforwardly, but
> afterwards (at least for me) leaves me feeling dirty, rather than like
> I'd achieved something interesting.

I view these things very differently.  I am used to FPGAs where the basic unit is a 16 bit memory used as a 4 input look up table (LUT) and a FF.  The F18 nodes do a lot better than that!  I think the first FPGA from Xilinx only had 64 CLBs which at that time were likely just one LUT and one FF although I don't recall, that was some 20 odd years ago.  And yes, you had to do all your own floor planning.  The experts in FPGAs all knew the details of how the routing connected.  Now no one cares as they just write HDL and the morass of software tools gives you something good enough given the huge amount of resources available.  I have seen products shipped using only 10% of a $1500 FPGA.  

I think the word analogy to be a poor one.  Rather than thinking of a node as a Forth word, think of it as a functional element where the function is software defined.  I have written a boxcar averaging filter in some 16 instructions which will likely take around 6 or 7 words in memory, I haven't put it through the tools yet.  Actually I may have to rewrite it.  It seems the F18 instruction set does not include a swap instruction which I didn't expect.  Sort of like the way nobody expects the Spanish Inquisition.  So I need to rethink my work on this.  

Rick

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

#14437

rickman <gnuarm@gmail.com> writes:
> I think the first FPGA from Xilinx only had 64 CLBs which at that time
> were likely just one LUT and one FF although I don't recall, that was
> some 20 odd years ago.  And yes, you had to do all your own floor
> planning.  The experts in FPGAs all knew the details of how the
> routing connected.  Now no one cares as they just write HDL and the
> morass of software tools gives you something good enough given the
> huge amount of resources available.

Does saying the GA144 situation today resembles the FPGA situation of 20
years ago (that nobody wants to deal with any more) really make the
GA144 sound so attractive today?  I can accept that the GA144 would have
been an awesome product compared to other devices of that era, if it had
been shipped 20 years ago.  It's harder for me to make such a case in
the GA144's own era.

> I have seen products shipped using only 10% of a $1500 FPGA.

FPGA's come in all sorts of sizes, with cost roughly proportionate to
their size.  Couldn't they have used a $150 FPGA a tenth the size,
especially if they were shipping more than a handful of the product?

> I think the word analogy to be a poor one.  Rather than thinking of a
> node as a Forth word, think of it as a functional element where the
> function is software defined. 

It seems to me that GA144 nodes are probably more efficient than FPGA
cells at doing the stuff that maps naturally to GA144 operations, but
FPGA cells are more flexible at being combined into bigger functions.
Even ignoring limitations on the number of nodes, the speed of
node-to-node communications on the GA144 is rather slow compared to
FPGA's, because you need software on each node copying the data around,
instead of just wires.  Maybe future GA processors can combine more
approaches (FGPA's, DSP slices, etc) with the basic F18 cell.

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

#14466

On Thursday, July 26, 2012 4:25:59 PM UTC-4, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
> > I think the first FPGA from Xilinx only had 64 CLBs which at that time
> > were likely just one LUT and one FF although I don't recall, that was
> > some 20 odd years ago.  And yes, you had to do all your own floor
> > planning.  The experts in FPGAs all knew the details of how the
> > routing connected.  Now no one cares as they just write HDL and the
> > morass of software tools gives you something good enough given the
> > huge amount of resources available.
> 
> Does saying the GA144 situation today resembles the FPGA situation of 20
> years ago (that nobody wants to deal with any more) really make the
> GA144 sound so attractive today?  I can accept that the GA144 would have
> been an awesome product compared to other devices of that era, if it had
> been shipped 20 years ago.  It's harder for me to make such a case in
> the GA144's own era.

People used FPGAs 20 years ago because they were useful then, just as the GA144 is useful now.  It can do things that no other chip can do. 


> > I have seen products shipped using only 10% of a $1500 FPGA.
> 
> FPGA's come in all sorts of sizes, with cost roughly proportionate to
> their size.  Couldn't they have used a $150 FPGA a tenth the size,
> especially if they were shipping more than a handful of the product?

You are missing one of the big advantages of FPGAs, that you can update the firmware and ship a product that can be expanded in the field.  

Let's look at it another way.  People want to see all of the LUTs in an FPGA used, but they don't seem to care about the routing!  A Xilinx rep once tried to make a point to me by saying, they are selling me the routing and GIVING me the LUTs for FREE!  The point was don't sweat being able to use all the LUTs as all designs have tradeoffs and they prefer to reduce the chip cost by not adding as much routing so some of their customers can't use all the LUTs.  This reduces the cost to all.  

Chuck's philosophy is the same.  The nodes are cheap, so what if you can't use all 144?  Does your app need 144 nodes?  Worry about getting your app done, not how many nodes you can utilize. 


> > I think the word analogy to be a poor one.  Rather than thinking of a
> > node as a Forth word, think of it as a functional element where the
> > function is software defined. 
> 
> It seems to me that GA144 nodes are probably more efficient than FPGA
> cells at doing the stuff that maps naturally to GA144 operations, but
> FPGA cells are more flexible at being combined into bigger functions.
> Even ignoring limitations on the number of nodes, the speed of
> node-to-node communications on the GA144 is rather slow compared to
> FPGA's, because you need software on each node copying the data around,
> instead of just wires.  Maybe future GA processors can combine more
> approaches (FGPA's, DSP slices, etc) with the basic F18 cell.

I can't think of an app where the GA144 processing is fast enough but the comms time is too slow. 

I'm not worried about what the GA144 might become.  I am interested in using it now.  There are LOTs of pipedreams which will never materialize.  The GA144 is here now and I am working to use it. 

Rick

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

#14469

rickman <gnuarm@gmail.com> writes:
> People used FPGAs 20 years ago because they were useful then, just as
> the GA144 is useful now.  It can do things that no other chip can do.

Well, I know the GA144 has unique capabilities, I'm just not so clear on
how to do anything useful with them.

>> > I have seen products shipped using only 10% of a $1500 FPGA. ...
> You are missing one of the big advantages of FPGAs, that you can
> update the firmware and ship a product that can be expanded in the
> field.

OK, they were using 10% of it for the initial delivery and the other 90%
for future expansion.  That's no problem, it's like shipping a PC with a
terabyte hard drive which is 99% empty as it will be filled up later.
If they're likely to use much of it, then great.  Otherwise maybe they
should have used a smaller part.

> A Xilinx rep once tried to make a point to me by saying, they are
> selling me the routing and GIVING me the LUTs for FREE!... they prefer
> to reduce the chip cost by not adding as much routing so some of their
> customers can't use all the LUTs.

OK, so you're using most or all of the routing, with LUTs left over.
Can you do the same with a GA144?  Maybe more relevantly, most types of
computational resources go to bottomless appetites.  Can I use a 144
core x86?  Yes.  What about 144,000 cores?  144 million?  Yes and yes.
But, an imagined 1000 core GA processor seems like even more of an
enigma than the GA144, in terms of what to use it for, unless there are
accompanying architectural updates.

> Chuck's philosophy is the same.  The nodes are cheap, so what if you
> can't use all 144?  Does your app need 144 nodes?  Worry about getting
> your app done, not how many nodes you can utilize.

The GA144's defining characteristic is the high number of nodes.  If I'm
not using them, I have to wonder whether a conventional CPU or FPGA
could have solved my problem better.

> I can't think of an app where the GA144 processing is fast enough but
> the comms time is too slow.

Think of a node using some extra nodes as ram.  If there are intervening
wire nodes that slows it down by a significant factor.

> The GA144 is here now and I am working to use it.

This is great, I'm eager to see how it comes out.  I'm not a hardware
guy so I'm sure there are many ideas that I don't think of.

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

#14478

On Friday, July 27, 2012 5:31:29 PM UTC-4, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
> 
> > People used FPGAs 20 years ago because they were useful then, just as
> > the GA144 is useful now.  It can do things that no other chip can do.
> 
> Well, I know the GA144 has unique capabilities, I'm just not so clear on
> how to do anything useful with them.
> 
> >> > I have seen products shipped using only 10% of a $1500 FPGA. ...
> > You are missing one of the big advantages of FPGAs, that you can
> > update the firmware and ship a product that can be expanded in the
> > field.
> 
> OK, they were using 10% of it for the initial delivery and the other 90%
> for future expansion.  That's no problem, it's like shipping a PC with a
> terabyte hard drive which is 99% empty as it will be filled up later.
> If they're likely to use much of it, then great.  Otherwise maybe they
> should have used a smaller part.
> 
> > A Xilinx rep once tried to make a point to me by saying, they are
> > selling me the routing and GIVING me the LUTs for FREE!... they prefer
> > to reduce the chip cost by not adding as much routing so some of their
> > customers can't use all the LUTs.
> 
> OK, so you're using most or all of the routing, with LUTs left over.

No, no FPGA I know of would allow you to use even 5% of the routing resources.  That is the point.  They have to provide routing to make the chip at all useful and most of that is wasted.  The LUTs are what you know how to use so you think in terms of counting LUT usage.  But in reality you pay for the entire chip and use a small fraction of it no matter what.  Worry not if you can use all the resources, worry if your design will fit.  It's that simple. 


> Can you do the same with a GA144?  Maybe more relevantly, most types of
> computational resources go to bottomless appetites.  Can I use a 144
> core x86?  Yes.  What about 144,000 cores?  144 million?  Yes and yes.
> But, an imagined 1000 core GA processor seems like even more of an
> enigma than the GA144, in terms of what to use it for, unless there are
> accompanying architectural updates.

They can't even keep 4 x86 CPUs supplied with data from memory so I have no idea what you would do with 144 of them on a single chip.  You are still thinking of them as x86 processors.  They aren't at all.  They are elements in an FPGA like device.  Worry about your app, not meaningless metrics that have no value. 


> > Chuck's philosophy is the same.  The nodes are cheap, so what if you
> > can't use all 144?  Does your app need 144 nodes?  Worry about getting
> > your app done, not how many nodes you can utilize.
> 
> The GA144's defining characteristic is the high number of nodes.  If I'm
> not using them, I have to wonder whether a conventional CPU or FPGA
> could have solved my problem better.

If you think the number 144 is where the magic comes from then you don't get the GA144.  How about a GA32?  Only 32 processors to occupy with all the same IO.  Does that make you any more satisfied with the GA32? 


> > I can't think of an app where the GA144 processing is fast enough but
> > the comms time is too slow.
> 
> Think of a node using some extra nodes as ram.  If there are intervening
> wire nodes that slows it down by a significant factor.

Why would you use RAM in a node that is not next to the node using the RAM?  


> > The GA144 is here now and I am working to use it.
> 
> This is great, I'm eager to see how it comes out.  I'm not a hardware
> guy so I'm sure there are many ideas that I don't think of.

So far the only thing that has tickled my imagination for this chip (other than software defined radios, SDR) is a single chip oscilloscope.  I'm still working on the details so it may not pan out, but we'll see.  An SDR is a more aggressive app in terms of development effort I think, so the o'scope is a stepping stone.  But even the o'scope will require me to build my own board as the GA eval board uses slower static RAM and I think I need faster SDRAM. 

Rick

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

#14509

rickman <gnuarm@gmail.com> writes:
> No, no FPGA I know of would allow you to use even 5% of the routing
> resources.  That is the point.

If you're using 5% of the routing and 10% of the LUT's, why did you
buy a $1500 FPGA instead of a $100 one?  What did the extra $1400 get you?

> Worry not if you can use all the resources, worry if your design will
> fit.  It's that simple.

That's the thing, if you're hoping to use a $100 FPGA but your
application won't fit, then maybe you have to use a $200 one with 2x
more CLB's.  And if it still won't fit, there's the $300 one, the $400
one, etc.  Once you hit the very biggest ones, there's still stuff that
won't fit, so you wish there were some that were even bigger, or you
wait for next year's models, etc.  It's the same with ram, hard drives,
parallel GPU units, or whatever.

By comparison it's hard to think of any applications that won't fit a
GA144, but that would fit in an imagined GA288 with 2x the nodes.  The
GA144 itself is already hard to fill, as we're finding.

>> Can I use a 144 core x86?  Yes.  What about 144,000 cores?  144
>> million?  Yes and yes.
>
> They can't even keep 4 x86 CPUs supplied with data from memory so I
> have no idea what you would do with 144 of them on a single chip.

They are making a 50+ core x86 (Knights Corner) but I was thinking more
along the lines of x86 multi-chip supercomputers with 1000's of cores.
Yes those exist and there's lots of applications for them.

> If you think the number 144 is where the magic comes from then you
> don't get the GA144.  How about a GA32?  Only 32 processors to occupy
> with all the same IO.  Does that make you any more satisfied with the
> GA32?

The GA32 makes more sense than the GA144, since it has more connectivity
and more i/o per core, so in that sense is better balanced, plus it's
smaller and therefore presumably costs less.  The GA144 is a fairly
large chip, probably larger than an ARM M3 or the like.  Of course
I can understand why GA might have come out with the flagship product
first, to make the biggest impression.  But I think the GA144 would
be better with somewhat different parameter choices.


> Why would you use RAM in a node that is not next to the node using the RAM?  

Because there's not enough connectivity between nodes to put the ram
immediately adjacent, a lot of the time.  As a trivial example, say your
algorithm needs 512 words of ram, or 8 nodes used as ram.  The 8 nodes
are no big deal, but the processing node has just 4 interconnects, so
you need a bunch of extra nodes and delays to move the data around.

Routing in an FPGA as I understand it is just wires and some gate
delays, but if you want to route stuff between GA144 nodes, it takes
software in the nodes to copy the data around, inserting significant
delays at each copying step compared to just routing with wires.

Maybe we could think of the GA144 as something like an FPGA with not
enough routing.

> So far the only thing that has tickled my imagination for this chip
> (other than software defined radios, SDR) is a single chip
> oscilloscope.

SDR is a really cool idea and it will be great if you can use a GA144
for that.

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

#14540

Paul Rubin wrote:

> rickman <gnuarm@gmail.com> writes:
>> No, no FPGA I know of would allow you to use even 5% of the routing
>> resources.  That is the point.
> 
> If you're using 5% of the routing and 10% of the LUT's, why did you
> buy a $1500 FPGA instead of a $100 one?  What did the extra $1400 get you?
> 
>> Worry not if you can use all the resources, worry if your design will
>> fit.  It's that simple.
> 
> That's the thing, if you're hoping to use a $100 FPGA but your
> application won't fit, then maybe you have to use a $200 one with 2x
> more CLB's.  And if it still won't fit, there's the $300 one, the $400
> one, etc.  Once you hit the very biggest ones, there's still stuff that
> won't fit, so you wish there were some that were even bigger, or you
> wait for next year's models, etc.  It's the same with ram, hard drives,
> parallel GPU units, or whatever.
> 
> By comparison it's hard to think of any applications that won't fit a
> GA144, but that would fit in an imagined GA288 with 2x the nodes.  The
> GA144 itself is already hard to fill, as we're finding.
> 
>>> Can I use a 144 core x86?  Yes.  What about 144,000 cores?  144
>>> million?  Yes and yes.



My thoghts were that the GA32 probably cost about the same to make as the 
144.  Since a 144 can be a 32, why make both?    


>>
>> They can't even keep 4 x86 CPUs supplied with data from memory so I
>> have no idea what you would do with 144 of them on a single chip.
> 
> They are making a 50+ core x86 (Knights Corner) but I was thinking more
> along the lines of x86 multi-chip supercomputers with 1000's of cores.
> Yes those exist and there's lots of applications for them.
> 
>> If you think the number 144 is where the magic comes from then you
>> don't get the GA144.  How about a GA32?  Only 32 processors to occupy
>> with all the same IO.  Does that make you any more satisfied with the
>> GA32?
> 
> The GA32 makes more sense than the GA144, since it has more connectivity
> and more i/o per core, so in that sense is better balanced, plus it's
> smaller and therefore presumably costs less.  The GA144 is a fairly
> large chip, probably larger than an ARM M3 or the like.  Of course
> I can understand why GA might have come out with the flagship product
> first, to make the biggest impression.  But I think the GA144 would
> be better with somewhat different parameter choices.
> 
> 
>> Why would you use RAM in a node that is not next to the node using the
>> RAM?
> 
> Because there's not enough connectivity between nodes to put the ram
> immediately adjacent, a lot of the time.  As a trivial example, say your
> algorithm needs 512 words of ram, or 8 nodes used as ram.  The 8 nodes
> are no big deal, but the processing node has just 4 interconnects, so
> you need a bunch of extra nodes and delays to move the data around.
> 
> Routing in an FPGA as I understand it is just wires and some gate
> delays, but if you want to route stuff between GA144 nodes, it takes
> software in the nodes to copy the data around, inserting significant
> delays at each copying step compared to just routing with wires.
> 
> Maybe we could think of the GA144 as something like an FPGA with not
> enough routing.
> 
>> So far the only thing that has tickled my imagination for this chip
>> (other than software defined radios, SDR) is a single chip
>> oscilloscope.
> 
> SDR is a really cool idea and it will be great if you can use a GA144
> for that.

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

#14566

On Sunday, July 29, 2012 7:12:56 PM UTC-4, marko wrote:
> 
> My thoghts were that the GA32 probably cost about the same to make as the 
> 144.  Since a 144 can be a 32, why make both?    

I have no idea why you think this.  The GA32 is less than 1/4 the size of the GA144.  I'm sure this makes a significant difference in the final price.  Certainly it would for high volumes.  With FPGAs I am told a significant determiner in the cost is the tester time required.  In this case there would be over four times the tester time required for the GA144. 

Rick

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

#14575

rickman wrote:

> On Sunday, July 29, 2012 7:12:56 PM UTC-4, marko wrote:
>> 
>> My thoghts were that the GA32 probably cost about the same to make as the
>> 144.  Since a 144 can be a 32, why make both?
> 
> I have no idea why you think this. 


> The GA32 is less than 1/4 the size of
> the GA144.  I'm sure this makes a significant difference in the final
> price.  Certainly it would for high volumes.  

I agree it would for high volumes.  Since the process used is very mature 
and fairly low tech, yield should be very good.  Correct me if I'm wrong, 
but 280nm can be done on a clean bench with resist shrink, albeit with low 
yield.  I also doubt there would be a need for grading like we see in 
amd/intel processors.  So we only have the cost of the raw silicon and the 
fab time to do more wafers, both very small compared to the cost of 
packaging, distribution and marketing.  

There were 3 planned chips - the GA4 - some samples were available.  The 
GA32, no samples and the GA144 - production.  Maybe there was a problem with 
the 32 die, but either way the decision was not to produce the GA32.     

> With FPGAs I am told a
> significant determiner in the cost is the tester time required.  In this
> case there would be over four times the tester time required for the
> GA144.

I can't comment on the testing costs of FPGA's vs the testing cost of GA144.  
I will reiterate my initial postulation that the GA32 would cost about as 
much to make as the GA144, apart from actual silicon real estate cost.

> 
> Rick


Cheers

Marko

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

#14587

On Tuesday, July 31, 2012 10:19:09 AM UTC-4, marko wrote:
> rickman wrote:
> 
> > On Sunday, July 29, 2012 7:12:56 PM UTC-4, marko wrote:
> >> 
> >> My thoghts were that the GA32 probably cost about the same to make as the
> >> 144.  Since a 144 can be a 32, why make both?
> > 
> > I have no idea why you think this. 
> 
> 
> > The GA32 is less than 1/4 the size of
> > the GA144.  I'm sure this makes a significant difference in the final
> > price.  Certainly it would for high volumes.  
> 
> 
> I agree it would for high volumes.  Since the process used is very mature 
> and fairly low tech, yield should be very good.  Correct me if I'm wrong, 
> but 280nm can be done on a clean bench with resist shrink, albeit with low 
> yield.  I also doubt there would be a need for grading like we see in 
> amd/intel processors.  So we only have the cost of the raw silicon and the 
> fab time to do more wafers, both very small compared to the cost of 
> packaging, distribution and marketing.  

I don't know what you mean about doing chip fab "on a clean bench".  Chip fab requires exposure to deadly chemicals and vapors which I am pretty sure you aren't going to want to do "on a clean bench".  What is the point of this statement anyway?  I'm pretty sure the process is 180 nm, not 280 nm.  The voltage used with a process was roughly the nm/100 in that era.  By the time they got to 90 nm the voltage had only dropped to 1.2 V IIRC and even now has not gone much below that for mainstream devices.  But in the 150 to 250 nm range the rule above for the voltage usually held. 


> There were 3 planned chips - the GA4 - some samples were available.  The 
> GA32, no samples and the GA144 - production.  Maybe there was a problem with 
> the 32 die, but either way the decision was not to produce the GA32.     

I think you are mistaken.  They did produce some test chips of the GA32.  One of the nodes was a test circuit.  


> > With FPGAs I am told a
> > significant determiner in the cost is the tester time required.  In this
> > case there would be over four times the tester time required for the
> > GA144.
> 
> I can't comment on the testing costs of FPGA's vs the testing cost of GA144.  
> I will reiterate my initial postulation that the GA32 would cost about as 
> much to make as the GA144, apart from actual silicon real estate cost.

Ok, I'll agree with that.  If you exclude the cost of the silicon and the cost of testing and any other cost that depends on the size of the design, then yes, the cost of the GA32 and the GA144 will be about the same...  ;^)

Rick

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

#14601

rickman wrote:

> On Tuesday, July 31, 2012 10:19:09 AM UTC-4, marko wrote:
>> rickman wrote:
>> 
>> > On Sunday, July 29, 2012 7:12:56 PM UTC-4, marko wrote:
>> >> 
>> >> My thoghts were that the GA32 probably cost about the same to make as
>> >> the
>> >> 144.  Since a 144 can be a 32, why make both?
>> > 
>> > I have no idea why you think this.
>> 
>> 
>> > The GA32 is less than 1/4 the size of
>> > the GA144.  I'm sure this makes a significant difference in the final
>> > price.  Certainly it would for high volumes.
>> 
>> 
>> I agree it would for high volumes.  Since the process used is very mature
>> and fairly low tech, yield should be very good.  Correct me if I'm wrong,
>> but 280nm can be done on a clean bench with resist shrink, albeit with
>> low
>> yield.  I also doubt there would be a need for grading like we see in
>> amd/intel processors.  So we only have the cost of the raw silicon and
>> the fab time to do more wafers, both very small compared to the cost of
>> packaging, distribution and marketing.
> 
> I don't know what you mean about doing chip fab "on a clean bench".  Chip
> fab requires exposure to deadly chemicals and vapors which I am pretty
> sure you aren't going to want to do "on a clean bench".  What is the point
> of this statement anyway?  

Done all the time in laboratories - I used to do it.  A "clean bench" is a 
laminar flow bench with a HEPA filter.  Gives you a clean room on a bench.  
The point is 280nm process is within the realms of optical technology mask 
aligners (actually UV to get a short enough wavelength) which when converted 
to production in a fab gives you very high yield.  280nm is not high tech at 
all.       

> I'm pretty sure the process is 180 nm, not 280

You are correct, I just checked it.  This means you need e-beam or ion 
implantation.  Not bench top, but high yeild.

> nm.  The voltage used with a process was roughly the nm/100 in that era. 
> By the time they got to 90 nm the voltage had only dropped to 1.2 V IIRC
> and even now has not gone much below that for mainstream devices.  But in
> the 150 to 250 nm range the rule above for the voltage usually held.
> 
> 
>> There were 3 planned chips - the GA4 - some samples were available.  The
>> GA32, no samples and the GA144 - production.  Maybe there was a problem
>> with the 32 die, but either way the decision was not to produce the GA32.
> 
> I think you are mistaken.  They did produce some test chips of the GA32. 
> One of the nodes was a test circuit.
> 
> 
>> > With FPGAs I am told a
>> > significant determiner in the cost is the tester time required.  In
>> > this case there would be over four times the tester time required for
>> > the GA144.
>> 
>> I can't comment on the testing costs of FPGA's vs the testing cost of
>> GA144. I will reiterate my initial postulation that the GA32 would cost
>> about as much to make as the GA144, apart from actual silicon real estate
>> cost.
> 
> Ok, I'll agree with that.  If you exclude the cost of the silicon and the
> cost of testing and any other cost that depends on the size of the design,
> then yes, the cost of the GA32 and the GA144 will be about the same... 
> ;^)

you forget the silicon cost is very small ;^)



> 
> Rick

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

#14598

rickman wrote:
> I have no idea why you think this.  The GA32 is less than 1/4 the size
> of the GA144.  I'm sure this makes a significant difference in the
> final price.  Certainly it would for high volumes.  With FPGAs I am
> told a significant determiner in the cost is the tester time required.
>  In this case there would be over four times the tester time required
> for the GA144.

Depends on the testing strategy.  I can't imagine Chuck using a standard 
scan-chain tester strategy.  I would use a self-test program, which runs 
on each CPU, and collects+compare meaningful outputs.  This can be 
distributed to all CPUs, run in parallel, and then collect the outputs.  
If the chip provides the expected magic number, then it is good.

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

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

#14600

On Tuesday, July 31, 2012 6:59:44 PM UTC-4, Bernd Paysan wrote:
> rickman wrote:
> 
> > I have no idea why you think this.  The GA32 is less than 1/4 the size
> 
> > of the GA144.  I'm sure this makes a significant difference in the
> 
> > final price.  Certainly it would for high volumes.  With FPGAs I am
> 
> > told a significant determiner in the cost is the tester time required.
> 
> >  In this case there would be over four times the tester time required
> 
> > for the GA144.
> 
> 
> 
> Depends on the testing strategy.  I can't imagine Chuck using a standard 
> 
> scan-chain tester strategy.  I would use a self-test program, which runs 
> 
> on each CPU, and collects+compare meaningful outputs.  This can be 
> 
> distributed to all CPUs, run in parallel, and then collect the outputs.  
> 
> If the chip provides the expected magic number, then it is good.


Of course, but it still takes longer to run the test on more processors.  The program has to be downloaded to each processor serially.  Chuck talks about this somewhat in the blog, but I don't recall seeing any timing data.  

I suppose there are ways to optimize this.  Chuck is currently downloading serially, but it could be done by fanning out the code to multiple ports.  The problem is that the comms code has to be custom for each node, in on left, out on up and down - in or down, out on right and up, etc.  So the code can't just be copied to each node, it all has to be downloaded.  

BTW, anyone know why he arrayed the nodes with left/right and up/down alternately mirrored?  I can't think of any advantage to this and the clear disadvantage is that there has to be two mirrored images of the nodes.  
  
Rick

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

#14719

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-08-01 at 01:54, rickman wrote:

> Of course, but it still takes longer to run the test on more
> processors.  The program has to be downloaded to each processor
> serially.  Chuck talks about this somewhat in the blog, but I don't
> recall seeing any timing data.

This was before testing was actually performed.  From
http://colorforth.com/blog.htm :

- --8<---------------cut here---------------start------------->8---
GreenArrays has received 1100 packaged chips; 150,000 Forth
computers. More on the way. They work fine. Efforts are now to get the
boards and software to test them. We have exhaustive tests planned that
will take up to a second/chip.
- --8<---------------cut here---------------end--------------->8---

Is the test time per chip really important?  I suppose chips are not
swapped manually, so one second or ten seconds per chip look about in
the same ballpark for me.

- -- 
Luca Saiu
Home page:   http://www-lipn.univ-paris13.fr/~saiu
My blog:     http://ageinghacker.net/blog
GNU epsilon: http://www.gnu.org/software/epsilon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlAc4VIACgkQvzOavibF0oafowCfSnpQhnQnlRGH3SJXRPrYi3xW
eIgAn1Os8oHUkY++Cf6fJ1tELewBYzVh
=BelS
-----END PGP SIGNATURE-----

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

#14745

On Saturday, August 4, 2012 4:46:10 AM UTC-4, Luca Saiu wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2012-08-01 at 01:54, rickman wrote:
> 
> > Of course, but it still takes longer to run the test on more
> > processors.  The program has to be downloaded to each processor
> > serially.  Chuck talks about this somewhat in the blog, but I don't
> > recall seeing any timing data.
> 
> This was before testing was actually performed.  From
> http://colorforth.com/blog.htm :
> - --8<---------------cut here---------------start------------->8---
> GreenArrays has received 1100 packaged chips; 150,000 Forth
> computers. More on the way. They work fine. Efforts are now to get the
> boards and software to test them. We have exhaustive tests planned that
> will take up to a second/chip.
> - --8<---------------cut here---------------end--------------->8---
> 
> Is the test time per chip really important?  I suppose chips are not
> swapped manually, so one second or ten seconds per chip look about in
> the same ballpark for me.
> 
> - -- 
> Luca Saiu

How do you test a chip that is not soldered to a board?  If you solder the chip to a board you can't sell it.  I suppose they can have built special test fixture boards that use quick release sockets but that is just plain slow to manually handle chips that way, not to mention the potential for damage.  

My comments were addressing the cost of the chips in high volume which would required automated testing, typically using dedicated test equipment.  If they can use the tester for only a second per chip, that would be great.  But they are talking about functional testing, there are also performance tests that should be done to verify the output transistors all work correctly, etc.  

I can't say how Green Arrays will do testing or how much it will cost.  But it is not unusual for the cost of testing to be a significant portion of the total cost of the chip and proportional to the size of the chip.  If it is not, there is still the cost of the silicon area.  Remember all of these remarks were made in the context of whether a GA32 can be made cheaper than a GA144 which was in the further context of whether the additional processors in the GA144 are of any value or rather a hindrance.  

Rick

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

#14753

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-08-05 at 20:04, rickman wrote:

> How do you test a chip that is not soldered to a board?  If you solder
> the chip to a board you can't sell it.

Don't ask me, I'm just a spectator :-).

Can't they just place a chip onto a custom socket, keeping them in place
with a spring?  Chips would also have to be oriented the right way;
optical sensors, I suppose.  The bottom side is easy to recognize
because of the heat sink, and there should be a notch on one angle.  I'm
not *at all* a hardware expert and I'm just conjecturing here, but the
thing seems feasible by machine.

Regards,

- -- 
Luca Saiu
Home page:   http://www-lipn.univ-paris13.fr/~saiu
My blog:     http://ageinghacker.net/blog
GNU epsilon: http://www.gnu.org/software/epsilon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlAfCZoACgkQvzOavibF0obI6gCfTIJl67cwow6c4ft96+P/XGs3
sggAn3F5FczdPrvkFyZHCM0gTlYP33JF
=eWkc
-----END PGP SIGNATURE-----

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

#14763

On Aug 5, 7:04 pm, rickman <gnu...@gmail.com> wrote:
> On Saturday, August 4, 2012 4:46:10 AM UTC-4, Luca Saiu wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
>
> > On 2012-08-01 at 01:54, rickman wrote:
>
> > > Of course, but it still takes longer to run the test on more
> > > processors.  The program has to be downloaded to each processor
> > > serially.  Chuck talks about this somewhat in the blog, but I don't
> > > recall seeing any timing data.
>
> > This was before testing was actually performed.  From
> >http://colorforth.com/blog.htm:
> > - --8<---------------cut here---------------start------------->8---
> > GreenArrays has received 1100 packaged chips; 150,000 Forth
> > computers. More on the way. They work fine. Efforts are now to get the
> > boards and software to test them. We have exhaustive tests planned that
> > will take up to a second/chip.
> > - --8<---------------cut here---------------end--------------->8---
>
> > Is the test time per chip really important?  I suppose chips are not
> > swapped manually, so one second or ten seconds per chip look about in
> > the same ballpark for me.
>
> > - --
> > Luca Saiu
>
> How do you test a chip that is not soldered to a board?  If you solder the chip to a board you can't sell it.  I suppose they can have built special test fixture boards that use quick release sockets but that is just plain slow to manually handle chips that way, not to mention the potential for damage.
>
> My comments were addressing the cost of the chips in high volume which would required automated testing, typically using dedicated test equipment.  If they can use the tester for only a second per chip, that would be great.  But they are talking about functional testing, there are also performance tests that should be done to verify the output transistors all work correctly, etc.
>
> I can't say how Green Arrays will do testing or how much it will cost.  But it is not unusual for the cost of testing to be a significant portion of the total cost of the chip and proportional to the size of the chip.  If it is not, there is still the cost of the silicon area.  Remember all of these remarks were made in the context of whether a GA32 can be made cheaper than a GA144 which was in the further context of whether the additional processors in the GA144 are of any value or rather a hindrance.
>
> Rick- Hide quoted text -
>
> - Show quoted text -

From chuck's site:

2 March 11:00 Wednesday
The court date last Friday required driving thru a snowstorm; very
tiring; thanks Greg. And no decisions rendered.
GreenArrays has received 1100 packaged chips; 150,000 Forth computers.
More on the way. They work fine. Efforts are now to get the boards and
software to test them. We have exhaustive tests planned that will take
up to a second/chip.


8 April 1:00 Friday
GreenArrays just received a temperature chamber. 350 lbs wrestled to
our 2nd floor office.
Now we can properly characterize chips and boards from -70 to 180 C.
And do some accelerated life tests.

Greg's prepared a data book for the GA144; it'll be on the website
soon. It reports the measurements Greg, Maggie, Mark and Dean have
been making on the production


23 June 9:00 Thursday
Summer has come to Tahoe; beautiful, warm, clear weather. Boats on the
lake; snow still above 8,000'. Hiking season. Tourists bringing
money.
GreenArrays is preparing to test and ship chips. polyForth as well as
eForth now runs on the GA144. polyForth will run the test procedure:
pretty much a 100% test of nodes, instructions, memory and pins.


5 July 4:00 Tuesday
GreenArrays has shipped several hundred chips to customers all over
the world. The result of marathon coding and testing sessions last
week.
Testing 144 computers/chip is the most impressive application we've
coded to date. It requires testing 32 instructions, 128 words of
memory, 8 registers and many data paths for each computer. As well as
262 communication ports and 80 pins for the chip.

There are 2 chips on the test board: the test Master and the Unit
Under Test. The current configuration has Master talking to a PC and
relaying instructions to the UUT. These instructions are routed about
UUT, executed and results reported to Master. Takes about a minute for
an exhaustive test.

Next step is to store the tests in Flash and have Master sequence
them. Only results are reported to PC over a relatively slow serial
link. Will take about a second.

Ultimately another test board will test 4 chips at once on Automatic
Test Equipment at the packaging house.

This testing is of value, since we are finding bad chips. A variety of
bad bond wires, broken traces, stuck bits and slow transistors. Yield
is yet to be determined.



:-)

(the smiley was added by me, not Chuck. Chuck* doesn't do smileys)
* Chuck Moore, that is. Not Chuck Norris. Don't mess with Norris.

[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