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

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

Kilocore

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

Contents

  Kilocore Brad Eckert <hwfwguy@gmail.com> - 2016-06-22 21:56 -0700
    Re: Kilocore Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-23 03:09 -0500
    Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-23 09:59 -0400
      Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-23 14:31 +0000
        Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-23 16:22 -0400
          Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-24 10:21 +0000
            Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-24 11:37 -0400
              Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-24 15:57 +0000
                Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-24 12:26 -0400
                  Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-25 14:10 +0000
                    Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-25 14:00 -0400
                      Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-26 09:58 +0000
                        Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-26 15:17 -0400
                          Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-27 14:40 +0000
                            Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-27 12:39 -0400
                              Re: Kilocore Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-27 14:50 -0500
                                Re: Kilocore Paul Rubin <no.email@nospam.invalid> - 2016-06-27 12:59 -0700
                                Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-27 16:05 -0400
                                  Re: Kilocore Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-27 15:17 -0500
                        Re: Kilocore hughaguilar96@gmail.com - 2016-06-26 15:46 -0700
    Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-23 14:15 +0000
      Re: Kilocore Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-23 11:57 -0500
      Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-23 16:25 -0400
    Re: Kilocore Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-24 04:18 -0700
      Re: Kilocore Brad Eckert <hwfwguy@gmail.com> - 2016-06-24 21:48 -0700
    Re: Kilocore endlessboomcapitalism@gmail.com - 2016-06-23 22:32 -0700
    Re: Kilocore darek.maksimiuk@gmail.com - 2016-06-26 13:12 -0700
    Re: Kilocore Mat <dambere@web.de> - 2016-06-26 16:36 -0700
    Re: Kilocore endlessboomcapitalism@gmail.com - 2016-06-27 11:05 -0700

Page 1 of 2  [1] 2  Next page →

#48461 — Kilocore

https://www.ucdavis.edu/news/worlds-first-1000-processor-chip

This chip borrows a lot of ideas from GreenArrays and most likely includes a lot of "lessons learned" that made the GA144 difficult to use in real world applications. Apparently it was funded by several grants from the DOD and NSF. It's nice to see Chuck's ideas making into real research labs.

I think Chuck made real contributions to hardware design just by shaking up paradigms. He demonstrated what could be done with simulation tools that accurately modeled silicon, for instance. Nowadays the tools have caught up so that they match the real silicon to within a few percent.

[toc] | [next] | [standalone]

#48462

Brad Eckert <hwfwguy@gmail.com> wrote:
> https://www.ucdavis.edu/news/worlds-first-1000-processor-chip
> 
> This chip borrows a lot of ideas from GreenArrays and most likely
> includes a lot of "lessons learned" that made the GA144 difficult to
> use in real world applications. Apparently it was funded by several
> grants from the DOD and NSF. It's nice to see Chuck's ideas making
> into real research labs.

http://vcl.ece.ucdavis.edu/pubs/2016.06.vlsi.symp.kiloCore/2016.vlsi.symp.kiloCore.with.note.pdf

It does all sound very familiar.  :-)

> I think Chuck made real contributions to hardware design just by
> shaking up paradigms. He demonstrated what could be done with
> simulation tools that accurately modeled silicon, for
> instance.

Yep.

Andrew.

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

#48468

On 6/23/2016 12:56 AM, Brad Eckert wrote:
> https://www.ucdavis.edu/news/worlds-first-1000-processor-chip
>
> This chip borrows a lot of ideas from GreenArrays and most likely includes a lot of "lessons learned" that made the GA144 difficult to use in real world applications. Apparently it was funded by several grants from the DOD and NSF. It's nice to see Chuck's ideas making into real research labs.
>
> I think Chuck made real contributions to hardware design just by shaking up paradigms. He demonstrated what could be done with simulation tools that accurately modeled silicon, for instance. Nowadays the tools have caught up so that they match the real silicon to within a few percent.

I may have mentioned this before, but some years ago, (about 10 I think) 
I was working for a DoD radio manufacturer and the government made 
available some amount of IRAD money to the hand held radio community. 
They had some suggestions for possible research topics and one of them 
was a chip with many processors.  I thought about that a bit and 
wondered if it was related at all to Chuck's designs, but I never found 
a connection.

At the time the community was shepherded by the DoD toward using a 
"standard" architecture based on a CPU like those used in cell phones 
and an FPGA.  The idea was to support a common hardware base which would 
allow radios from different makers to share code to describe "waveforms" 
(meaning modulation types, etc).  I didn't see how the use of a many 
core processor would even be usable in this environment much less 
facilitate it.  I guess that is what the research would be for.  I don't 
get why they have built a chip before they have dealt with the issues of 
programming it.

-- 

Rick C

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

#48470

rickman <gnuarm@gmail.com> writes:
>I didn't see how the use of a many 
>core processor would even be usable in this environment much less 
>facilitate it.  I guess that is what the research would be for.  I don't 
>get why they have built a chip before they have dealt with the issues of 
>programming it.

These are hardware people.  They do it all the time.  They build
something, and hope that the software people will solve the proplem of
programming it.  And not just in research chips like the KiloCore,
also in production chips like the Cell used in the PS3 (which, I hear,
is mostly unsuccessful as far as making use of the SFUs goes).  Or in
the Cray-1 (which I consider a success).

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

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

#48474

On 6/23/2016 10:31 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> I didn't see how the use of a many
>> core processor would even be usable in this environment much less
>> facilitate it.  I guess that is what the research would be for.  I don't
>> get why they have built a chip before they have dealt with the issues of
>> programming it.
>
> These are hardware people.  They do it all the time.  They build
> something, and hope that the software people will solve the proplem of
> programming it.  And not just in research chips like the KiloCore,
> also in production chips like the Cell used in the PS3 (which, I hear,
> is mostly unsuccessful as far as making use of the SFUs goes).  Or in
> the Cray-1 (which I consider a success).

I don't want to offend, but I think the idea that someone would spend 
half a mil building a chip without any idea of how to program it is a 
bit of nonsense.  But then again, that seems to be the biggest problem 
with the GA144, programming, so maybe you have something there... it was 
designed by a hardware guy, right?

-- 

Rick C

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

#48479

rickman <gnuarm@gmail.com> writes:
>On 6/23/2016 10:31 AM, Anton Ertl wrote:
>> These are hardware people.  They do it all the time.  They build
>> something, and hope that the software people will solve the proplem of
>> programming it.  And not just in research chips like the KiloCore,
>> also in production chips like the Cell used in the PS3 (which, I hear,
>> is mostly unsuccessful as far as making use of the SFUs goes).  Or in
>> the Cray-1 (which I consider a success).
>
>I don't want to offend, but I think the idea that someone would spend 
>half a mil building a chip without any idea of how to program it is a 
>bit of nonsense.

Sure they have an idea how to program it.  Sometimes these ideas scale
to development of bigger software, and sometimes they don't.  Now will
you spend a few millions on software development for a hardware model
before you know that you can actually build the hardware?

>But then again, that seems to be the biggest problem 
>with the GA144, programming, so maybe you have something there... it was 
>designed by a hardware guy, right?

Chuck Moore is a hardware and a software guy, and he certainly has an
idea how to program it, but his ideas are incompatible with mainstream
software development, and in the case of his multi-cores, even with
most Forth programmers.

OTOH, I see the GA chips not as general-purpose computers, but as
another option roughly in the area that FPGAs occupy.  You can use it
for specialized functions (that can be programmed in the small program
and data memories that these cores have), and because these memories
are so small, software development for them is limited and should not
take that much effort; the question is if you can fit useful
functionality in there.  But for some kind of signal processing, why
not?

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

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

#48480

On 6/24/2016 6:21 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> On 6/23/2016 10:31 AM, Anton Ertl wrote:
>>> These are hardware people.  They do it all the time.  They build
>>> something, and hope that the software people will solve the proplem of
>>> programming it.  And not just in research chips like the KiloCore,
>>> also in production chips like the Cell used in the PS3 (which, I hear,
>>> is mostly unsuccessful as far as making use of the SFUs goes).  Or in
>>> the Cray-1 (which I consider a success).
>>
>> I don't want to offend, but I think the idea that someone would spend
>> half a mil building a chip without any idea of how to program it is a
>> bit of nonsense.
>
> Sure they have an idea how to program it.  Sometimes these ideas scale
> to development of bigger software, and sometimes they don't.  Now will
> you spend a few millions on software development for a hardware model
> before you know that you can actually build the hardware?

Where is the risk in building hardware at a process node more than five 
years old?


>> But then again, that seems to be the biggest problem
>> with the GA144, programming, so maybe you have something there... it was
>> designed by a hardware guy, right?
>
> Chuck Moore is a hardware and a software guy, and he certainly has an
> idea how to program it, but his ideas are incompatible with mainstream
> software development, and in the case of his multi-cores, even with
> most Forth programmers.
>
> OTOH, I see the GA chips not as general-purpose computers, but as
> another option roughly in the area that FPGAs occupy.  You can use it
> for specialized functions (that can be programmed in the small program
> and data memories that these cores have), and because these memories
> are so small, software development for them is limited and should not
> take that much effort; the question is if you can fit useful
> functionality in there.

Yes, I agree that the GA144 is a "specialized" chip, so specialized 
there are very few applications that can profitably use it.  The GA144 
has proven to be a nightmare to program and it is lacking a lot in the 
way of useful interfaces.  The difficulty in programming the device is 
not the issue of programming any one node, but decomposing a design into 
appropriate pieces that not only are sized for the F18A node memories, 
but also the limited communications available.

You compared the GA144 to FPGAs but they fall short of the mark there 
too.  A couple of decades ago Atmel made an FPGA which had basic cells 
which were only connected to neighbors with very little other routing. 
Turns out this was a terrible idea wasting much of the logic resources 
of the chip.  They never made the devices in a more current technology 
and the parts faded into the mist of failed ideas.

I used to say that in terms of the programming, the GA144 should be 
thought of, not as a multiprocessor chip, but as a Field Programmable 
Processor Array (FPPA).  Trying to use the devices as a multiprocessor 
quickly ran into the many limitations of memory, communications and I/O 
capability.  Thinking of it as an FPPA at least allowed you to organize 
your thoughts in a more effective way before you ran into the 
limitations of memory, communications and I/O capability.


> But for some kind of signal processing, why
> not?

I give up, why not?  Which signal processing apps has the GA144 been 
used for?

-- 

Rick C

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

#48482

rickman <gnuarm@gmail.com> writes:
>On 6/24/2016 6:21 AM, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> I don't want to offend, but I think the idea that someone would spend
>>> half a mil building a chip without any idea of how to program it is a
>>> bit of nonsense.
>>
>> Sure they have an idea how to program it.  Sometimes these ideas scale
>> to development of bigger software, and sometimes they don't.  Now will
>> you spend a few millions on software development for a hardware model
>> before you know that you can actually build the hardware?
>
>Where is the risk in building hardware at a process node more than five 
>years old?

Hardware with design parameters that no one has tried before?  Risks:
Do you get it to work?  Do you get it to perform?

And for the software provider: Will the hardware maker actuallt build
the thing?  Will anyone buy it?  Once they buy it, will they buy my
software?

If you want to get some idea of the issues, read what John Dallman has
written over the years about Itanium on comp.arch.

>> But for some kind of signal processing, why
>> not?
>
>I give up, why not?  Which signal processing apps has the GA144 been 
>used for?

I don't know, I have not followed this stuff.  Supposedly you can use
some cores for producing a video signal.  I could imagine that one
could use it for an oscilloscope.  I don't know how much additional
circuitry would be needed and if it has any advantages over other
potential solutions for that application.

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

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

#48483

On 6/24/2016 11:57 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> On 6/24/2016 6:21 AM, Anton Ertl wrote:
>>> rickman <gnuarm@gmail.com> writes:
>>>> I don't want to offend, but I think the idea that someone would spend
>>>> half a mil building a chip without any idea of how to program it is a
>>>> bit of nonsense.
>>>
>>> Sure they have an idea how to program it.  Sometimes these ideas scale
>>> to development of bigger software, and sometimes they don't.  Now will
>>> you spend a few millions on software development for a hardware model
>>> before you know that you can actually build the hardware?
>>
>> Where is the risk in building hardware at a process node more than five
>> years old?
>
> Hardware with design parameters that no one has tried before?  Risks:
> Do you get it to work?  Do you get it to perform?

Design parameters such as what?  The issue of performance is much more 
of a risk in the software than the hardware.


> And for the software provider: Will the hardware maker actuallt build
> the thing?  Will anyone buy it?  Once they buy it, will they buy my
> software?

What???  Who won't build a chip if you pay them?  The software and 
hardware are being designed by the same company.


> If you want to get some idea of the issues, read what John Dallman has
> written over the years about Itanium on comp.arch.

 From what I read the failure was in the software being able to be 
optimized by the software tools.  They took a leap of faith and it fell 
short.


>>> But for some kind of signal processing, why
>>> not?
>>
>> I give up, why not?  Which signal processing apps has the GA144 been
>> used for?
>
> I don't know, I have not followed this stuff.  Supposedly you can use
> some cores for producing a video signal.  I could imagine that one
> could use it for an oscilloscope.  I don't know how much additional
> circuitry would be needed and if it has any advantages over other
> potential solutions for that application.

Lol, "video signal" in the sense of a minimal resolution text display I 
think.  I haven't seen anything more sophisticated being done.  Sure, 
anything is conceivable, but getting it done is very hard with the GA144.

I looked very hard at using the GA144 for an oscilloscope and the big 
issue is the memory interface being very limited along with the very 
limited memory in the chip.  Then there is the issue of interfaces.  I 
would prefer an attached oscilloscope using a PC for the user interface. 
  But there is no high speed USB capability so it need a separate 
interface chip which would be another MCU in reality.  At some point 
adding hardware to make up for the limitations of the GA144 becomes not 
unlike the story of "stone soup".

-- 

Rick C

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

#48505

rickman <gnuarm@gmail.com> writes:
>On 6/24/2016 11:57 AM, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> On 6/24/2016 6:21 AM, Anton Ertl wrote:
>>>> rickman <gnuarm@gmail.com> writes:
>>>>> I don't want to offend, but I think the idea that someone would spend
>>>>> half a mil building a chip without any idea of how to program it is a
>>>>> bit of nonsense.
>>>>
>>>> Sure they have an idea how to program it.  Sometimes these ideas scale
>>>> to development of bigger software, and sometimes they don't.  Now will
>>>> you spend a few millions on software development for a hardware model
>>>> before you know that you can actually build the hardware?
>>>
>>> Where is the risk in building hardware at a process node more than five
>>> years old?
>>
>> Hardware with design parameters that no one has tried before?  Risks:
>> Do you get it to work?  Do you get it to perform?
>
>Design parameters such as what?

Number of cores in the example of KiloCore.  Will the interconnect
scale for real software loads with inter-core communications?

>The issue of performance is much more 
>of a risk in the software than the hardware.

Nobody cares for a word processor that's ten times faster than MS
Word.  OTOH, if your hardware is half as fast as the competition, you
are toast.  Actually, looking at how AMD has fared lately, much less
than a factor of 2 is already a big problem.

>> And for the software provider: Will the hardware maker actuallt build
>> the thing?  Will anyone buy it?  Once they buy it, will they buy my
>> software?
>
>What???  Who won't build a chip if you pay them?

Why should a software maker pay huge sums for building a new chip
based on untried principles?

>The software and 
>hardware are being designed by the same company.

There may be such hardware, but the KiloCore or GA are obviously not
among them.

>> If you want to get some idea of the issues, read what John Dallman has
>> written over the years about Itanium on comp.arch.
>
> From what I read the failure was in the software being able to be 
>optimized by the software tools.

Yes, that was part of it.  Although piecing together his postings
paints a broader picture.  E.g., this week he posted that HP suing
Oracle to force them to continue supporting the Itanium ensured that
John Dallman's company would not resume supporting it even if HP gave
them money (at least not the way the contracts were written).

>They took a leap of faith and it fell 
>short.

Yes.  And the sank billions of dollars in it, not just half a million.

The KiloCore people are also taking a leap of faith.  Given that it is
a research project, that's their job.

>> Supposedly you can use
>> some cores for producing a video signal.  I could imagine that one
>> could use it for an oscilloscope.  I don't know how much additional
>> circuitry would be needed and if it has any advantages over other
>> potential solutions for that application.
>
>Lol, "video signal" in the sense of a minimal resolution text display I 
>think.  I haven't seen anything more sophisticated being done.  Sure, 
>anything is conceivable, but getting it done is very hard with the GA144.
>
>I looked very hard at using the GA144 for an oscilloscope and the big 
>issue is the memory interface being very limited along with the very 
>limited memory in the chip.

Ok, it looks like you have looked into the possibilities of this chip
quite a lot, and if you did not find an application, I am unlikely to
find them, either.  I wonder what they sold to their investors.

>  But there is no high speed USB capability so it need a separate 
>interface chip which would be another MCU in reality.  At some point 
>adding hardware to make up for the limitations of the GA144 becomes not 
>unlike the story of "stone soup".

Sure, if you use it in an FPGA (or was it FPPA?) like capacity, it
won't stand on its own.  Of course, the question is if it contributes
enough to pay for itself.  Also, in this age of SoCs, you want to be
able to integrate it with all the other stuff on one chip, and I doubt
that this is easily possible given that Chuck Moore does not use
standard tools, and probably only the last stage of standard
interchange file formats.

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

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

#48512

On 6/25/2016 10:10 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> On 6/24/2016 11:57 AM, Anton Ertl wrote:
>>> rickman <gnuarm@gmail.com> writes:
>>>> On 6/24/2016 6:21 AM, Anton Ertl wrote:
>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>> I don't want to offend, but I think the idea that someone would spend
>>>>>> half a mil building a chip without any idea of how to program it is a
>>>>>> bit of nonsense.
>>>>>
>>>>> Sure they have an idea how to program it.  Sometimes these ideas scale
>>>>> to development of bigger software, and sometimes they don't.  Now will
>>>>> you spend a few millions on software development for a hardware model
>>>>> before you know that you can actually build the hardware?
>>>>
>>>> Where is the risk in building hardware at a process node more than five
>>>> years old?
>>>
>>> Hardware with design parameters that no one has tried before?  Risks:
>>> Do you get it to work?  Do you get it to perform?
>>
>> Design parameters such as what?
>
> Number of cores in the example of KiloCore.  Will the interconnect
> scale for real software loads with inter-core communications?

That is not a risk in building the hardware.  That is a risk in 
configuration and perhaps even basic design which would all be modeled 
in software before even starting the detailed chip design.


>> The issue of performance is much more
>> of a risk in the software than the hardware.
>
> Nobody cares for a word processor that's ten times faster than MS
> Word.  OTOH, if your hardware is half as fast as the competition, you
> are toast.  Actually, looking at how AMD has fared lately, much less
> than a factor of 2 is already a big problem.

I have no idea what your point is.


>>> And for the software provider: Will the hardware maker actuallt build
>>> the thing?  Will anyone buy it?  Once they buy it, will they buy my
>>> software?
>>
>> What???  Who won't build a chip if you pay them?
>
> Why should a software maker pay huge sums for building a new chip
> based on untried principles?

Uh, that is what I've been saying.  The design would be verified by 
software simulation long before any money would be spent on building a 
chip.


>> The software and
>> hardware are being designed by the same company.
>
> There may be such hardware, but the KiloCore or GA are obviously not
> among them.

I was speaking tongue in cheek about GA.  That  was clearly a very 
speculative design that should have never been built until the issues 
with the hardware limitations and software development were dealt with. 
However, the people involved have the opinion there are no issues, so 
they built the chip.

I'm not sure what you are talking about with the Kilocore.  I am pretty 
sure the developers are designing both software and hardware, but I 
can't find much info on that.  But again, that is a research chip paid 
for by R&D funds which don't expect a direct profit return.


>>> If you want to get some idea of the issues, read what John Dallman has
>>> written over the years about Itanium on comp.arch.
>>
>> From what I read the failure was in the software being able to be
>> optimized by the software tools.
>
> Yes, that was part of it.  Although piecing together his postings
> paints a broader picture.  E.g., this week he posted that HP suing
> Oracle to force them to continue supporting the Itanium ensured that
> John Dallman's company would not resume supporting it even if HP gave
> them money (at least not the way the contracts were written).
>
>> They took a leap of faith and it fell
>> short.
>
> Yes.  And the sank billions of dollars in it, not just half a million.
>
> The KiloCore people are also taking a leap of faith.  Given that it is
> a research project, that's their job.
>
>>> Supposedly you can use
>>> some cores for producing a video signal.  I could imagine that one
>>> could use it for an oscilloscope.  I don't know how much additional
>>> circuitry would be needed and if it has any advantages over other
>>> potential solutions for that application.
>>
>> Lol, "video signal" in the sense of a minimal resolution text display I
>> think.  I haven't seen anything more sophisticated being done.  Sure,
>> anything is conceivable, but getting it done is very hard with the GA144.
>>
>> I looked very hard at using the GA144 for an oscilloscope and the big
>> issue is the memory interface being very limited along with the very
>> limited memory in the chip.
>
> Ok, it looks like you have looked into the possibilities of this chip
> quite a lot, and if you did not find an application, I am unlikely to
> find them, either.  I wonder what they sold to their investors.

The architecture of the GA144 lends itself to signal processing that can 
be deeply pipelined with limited data I/O and small memory requirements. 
  There aren't too many apps that fits that description.  They exist, 
but few and far between.


>>  But there is no high speed USB capability so it need a separate
>> interface chip which would be another MCU in reality.  At some point
>> adding hardware to make up for the limitations of the GA144 becomes not
>> unlike the story of "stone soup".
>
> Sure, if you use it in an FPGA (or was it FPPA?) like capacity, it
> won't stand on its own.  Of course, the question is if it contributes
> enough to pay for itself.  Also, in this age of SoCs, you want to be
> able to integrate it with all the other stuff on one chip, and I doubt
> that this is easily possible given that Chuck Moore does not use
> standard tools, and probably only the last stage of standard
> interchange file formats.

SoCs only contain the circuits that can be added easily.  It is not at 
all uncommon to use separate chips for specialized functions that would 
not work well either technically or from a business perspective.  With 
such a large amount of processing the GA144 could do ok stand alone if 
it can get data in and out of it... which is hard.

-- 

Rick C

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

#48534

rickman <gnuarm@gmail.com> writes:
>On 6/25/2016 10:10 AM, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> On 6/24/2016 11:57 AM, Anton Ertl wrote:
>>>> rickman <gnuarm@gmail.com> writes:
>>>>> On 6/24/2016 6:21 AM, Anton Ertl wrote:
>>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>>> I don't want to offend, but I think the idea that someone would spend
>>>>>>> half a mil building a chip without any idea of how to program it is a
>>>>>>> bit of nonsense.
>>>>>>
>>>>>> Sure they have an idea how to program it.  Sometimes these ideas scale
>>>>>> to development of bigger software, and sometimes they don't.  Now will
>>>>>> you spend a few millions on software development for a hardware model
>>>>>> before you know that you can actually build the hardware?
>>>>>
>>>>> Where is the risk in building hardware at a process node more than five
>>>>> years old?
>>>>
>>>> Hardware with design parameters that no one has tried before?  Risks:
>>>> Do you get it to work?  Do you get it to perform?
>>>
>>> Design parameters such as what?
>>
>> Number of cores in the example of KiloCore.  Will the interconnect
>> scale for real software loads with inter-core communications?
>
>That is not a risk in building the hardware.  That is a risk in 
>configuration and perhaps even basic design which would all be modeled 
>in software before even starting the detailed chip design.

Sure, but what you can do in simulation is limited, and simulation is
not free, either.  At some point you have gone as far as practical
with simulation, and then you build it, and it can still turn out that
the interconnect is not up to the demands of real software for this
chip.

>>> The issue of performance is much more
>>> of a risk in the software than the hardware.
>>
>> Nobody cares for a word processor that's ten times faster than MS
>> Word.  OTOH, if your hardware is half as fast as the competition, you
>> are toast.  Actually, looking at how AMD has fared lately, much less
>> than a factor of 2 is already a big problem.
>
>I have no idea what your point is.

I gave an example that contradicts your claim.

>>>> And for the software provider: Will the hardware maker actuallt build
>>>> the thing?  Will anyone buy it?  Once they buy it, will they buy my
>>>> software?
>>>
>>> What???  Who won't build a chip if you pay them?
>>
>> Why should a software maker pay huge sums for building a new chip
>> based on untried principles?
>
>Uh, that is what I've been saying.  The design would be verified by 
>software simulation long before any money would be spent on building a 
>chip.

Why should a software maker invest in verifying a hardware design,
especially one based on untried principles?

>I'm not sure what you are talking about with the Kilocore.  I am pretty 
>sure the developers are designing both software and hardware, but I 
>can't find much info on that.

Sure, they write some benchmarks to show off the capabilities of their
chips, but they certainly won't be doing any multi-year software
development effort for it.  Maybe the hardware department will
cooperate with a software department which will explore software
scalability to some areas opened up by that chip, but the result will
also just be proof-of-concepts.

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

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

#48540

On 6/26/2016 5:58 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> On 6/25/2016 10:10 AM, Anton Ertl wrote:
>>> rickman <gnuarm@gmail.com> writes:
>>>> On 6/24/2016 11:57 AM, Anton Ertl wrote:
>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>> On 6/24/2016 6:21 AM, Anton Ertl wrote:
>>>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>>>> I don't want to offend, but I think the idea that someone would spend
>>>>>>>> half a mil building a chip without any idea of how to program it is a
>>>>>>>> bit of nonsense.
>>>>>>>
>>>>>>> Sure they have an idea how to program it.  Sometimes these ideas scale
>>>>>>> to development of bigger software, and sometimes they don't.  Now will
>>>>>>> you spend a few millions on software development for a hardware model
>>>>>>> before you know that you can actually build the hardware?
>>>>>>
>>>>>> Where is the risk in building hardware at a process node more than five
>>>>>> years old?
>>>>>
>>>>> Hardware with design parameters that no one has tried before?  Risks:
>>>>> Do you get it to work?  Do you get it to perform?
>>>>
>>>> Design parameters such as what?
>>>
>>> Number of cores in the example of KiloCore.  Will the interconnect
>>> scale for real software loads with inter-core communications?
>>
>> That is not a risk in building the hardware.  That is a risk in
>> configuration and perhaps even basic design which would all be modeled
>> in software before even starting the detailed chip design.
>
> Sure, but what you can do in simulation is limited, and simulation is
> not free, either.  At some point you have gone as far as practical
> with simulation, and then you build it, and it can still turn out that
> the interconnect is not up to the demands of real software for this
> chip.

None of that is relevant to the original statement above.  What is your 
point?  Besides, simulation capabilities are pretty f'ing huge these 
days.  There is not much that can't be calculated or simulated.


>>>> The issue of performance is much more
>>>> of a risk in the software than the hardware.
>>>
>>> Nobody cares for a word processor that's ten times faster than MS
>>> Word.  OTOH, if your hardware is half as fast as the competition, you
>>> are toast.  Actually, looking at how AMD has fared lately, much less
>>> than a factor of 2 is already a big problem.
>>
>> I have no idea what your point is.
>
> I gave an example that contradicts your claim.

I have no idea what you are talking about.


>>>>> And for the software provider: Will the hardware maker actuallt build
>>>>> the thing?  Will anyone buy it?  Once they buy it, will they buy my
>>>>> software?
>>>>
>>>> What???  Who won't build a chip if you pay them?
>>>
>>> Why should a software maker pay huge sums for building a new chip
>>> based on untried principles?
>>
>> Uh, that is what I've been saying.  The design would be verified by
>> software simulation long before any money would be spent on building a
>> chip.
>
> Why should a software maker invest in verifying a hardware design,
> especially one based on untried principles?

Again you have drifted far off the original topic, a hardware design 
that should be evaluated in the context of the software that would run 
on it before being built.


>> I'm not sure what you are talking about with the Kilocore.  I am pretty
>> sure the developers are designing both software and hardware, but I
>> can't find much info on that.
>
> Sure, they write some benchmarks to show off the capabilities of their
> chips, but they certainly won't be doing any multi-year software
> development effort for it.  Maybe the hardware department will
> cooperate with a software department which will explore software
> scalability to some areas opened up by that chip, but the result will
> also just be proof-of-concepts.

If they don't write software for it, who will?

-- 

Rick C

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

#48572

rickman <gnuarm@gmail.com> writes:
>On 6/26/2016 5:58 AM, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> On 6/25/2016 10:10 AM, Anton Ertl wrote:
>>>> rickman <gnuarm@gmail.com> writes:
>>>>> On 6/24/2016 11:57 AM, Anton Ertl wrote:
>>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>>> On 6/24/2016 6:21 AM, Anton Ertl wrote:
>>>>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>>>>> I don't want to offend, but I think the idea that someone would spend
>>>>>>>>> half a mil building a chip without any idea of how to program it is a
>>>>>>>>> bit of nonsense.
>>>>>>>>
>>>>>>>> Sure they have an idea how to program it.  Sometimes these ideas scale
>>>>>>>> to development of bigger software, and sometimes they don't.  Now will
>>>>>>>> you spend a few millions on software development for a hardware model
>>>>>>>> before you know that you can actually build the hardware?
>>>>>>>
>>>>>>> Where is the risk in building hardware at a process node more than five
>>>>>>> years old?
>>>>>>
>>>>>> Hardware with design parameters that no one has tried before?  Risks:
>>>>>> Do you get it to work?  Do you get it to perform?
>>>>>
>>>>> Design parameters such as what?
>>>>
>>>> Number of cores in the example of KiloCore.  Will the interconnect
>>>> scale for real software loads with inter-core communications?
>>>
>>> That is not a risk in building the hardware.  That is a risk in
>>> configuration and perhaps even basic design which would all be modeled
>>> in software before even starting the detailed chip design.
>>
>> Sure, but what you can do in simulation is limited, and simulation is
>> not free, either.  At some point you have gone as far as practical
>> with simulation, and then you build it, and it can still turn out that
>> the interconnect is not up to the demands of real software for this
>> chip.
>
>None of that is relevant to the original statement above.  What is your 
>point?  Besides, simulation capabilities are pretty f'ing huge these 
>days.  There is not much that can't be calculated or simulated.

A cycle-accurate simulation of a 1000-core design will be several
orders of magnitude slower than the hardware even if you have 1000
cores in the simulator; especially simulating the interconnect is
likely to be slow.  And you can only simulate running software that
you have, so if you want to simulate more than just a few benchmarks,
you will have to do some serious software development.

My point is: "At some point you have gone as far as practical
with simulation, and then you build it, and it can still turn out that
the interconnect is not up to the demands of real software for this
chip."  And I think this is relevant to the discussion at hand.

>>>>> The issue of performance is much more
>>>>> of a risk in the software than the hardware.
>>>>
>>>> Nobody cares for a word processor that's ten times faster than MS
>>>> Word.  OTOH, if your hardware is half as fast as the competition, you
>>>> are toast.  Actually, looking at how AMD has fared lately, much less
>>>> than a factor of 2 is already a big problem.
>>>
>>> I have no idea what your point is.
>>
>> I gave an example that contradicts your claim.
>
>I have no idea what you are talking about.

"The issue of performance is much more of a risk in the software than
the hardware."

People often care more about other things in software, so bad
performance is not such a big problem, and performance is not such a
big risk (although that leads to the kind of don't-care-for-performace
programming that leads to problems that are big enough to make
projects fail; risk homeostatis at work).

>> Why should a software maker invest in verifying a hardware design,
>> especially one based on untried principles?
>
>Again you have drifted far off the original topic, a hardware design 
>that should be evaluated in the context of the software that would run 
>on it before being built.

That's your claim, and you tried to support it with claims about
software makers funding hardware development; I followed you there,
and now you complain about me drifting from the original topic.
Funny.

>> Sure, they write some benchmarks to show off the capabilities of their
>> chips, but they certainly won't be doing any multi-year software
>> development effort for it.  Maybe the hardware department will
>> cooperate with a software department which will explore software
>> scalability to some areas opened up by that chip, but the result will
>> also just be proof-of-concepts.
>
>If they don't write software for it, who will?

Who knows.  They have their paper published (or probably several).
Mission accomplished.  Maybe there will be papers about programming
the thing, maybe not.

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

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

#48574

On 6/27/2016 10:40 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> On 6/26/2016 5:58 AM, Anton Ertl wrote:
>>> rickman <gnuarm@gmail.com> writes:
>>>> On 6/25/2016 10:10 AM, Anton Ertl wrote:
>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>> On 6/24/2016 11:57 AM, Anton Ertl wrote:
>>>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>>>> On 6/24/2016 6:21 AM, Anton Ertl wrote:
>>>>>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>>>>>> I don't want to offend, but I think the idea that someone would spend
>>>>>>>>>> half a mil building a chip without any idea of how to program it is a
>>>>>>>>>> bit of nonsense.
>>>>>>>>>
>>>>>>>>> Sure they have an idea how to program it.  Sometimes these ideas scale
>>>>>>>>> to development of bigger software, and sometimes they don't.  Now will
>>>>>>>>> you spend a few millions on software development for a hardware model
>>>>>>>>> before you know that you can actually build the hardware?
>>>>>>>>
>>>>>>>> Where is the risk in building hardware at a process node more than five
>>>>>>>> years old?
>>>>>>>
>>>>>>> Hardware with design parameters that no one has tried before?  Risks:
>>>>>>> Do you get it to work?  Do you get it to perform?
>>>>>>
>>>>>> Design parameters such as what?
>>>>>
>>>>> Number of cores in the example of KiloCore.  Will the interconnect
>>>>> scale for real software loads with inter-core communications?
>>>>
>>>> That is not a risk in building the hardware.  That is a risk in
>>>> configuration and perhaps even basic design which would all be modeled
>>>> in software before even starting the detailed chip design.
>>>
>>> Sure, but what you can do in simulation is limited, and simulation is
>>> not free, either.  At some point you have gone as far as practical
>>> with simulation, and then you build it, and it can still turn out that
>>> the interconnect is not up to the demands of real software for this
>>> chip.
>>
>> None of that is relevant to the original statement above.  What is your
>> point?  Besides, simulation capabilities are pretty f'ing huge these
>> days.  There is not much that can't be calculated or simulated.
>
> A cycle-accurate simulation of a 1000-core design will be several
> orders of magnitude slower than the hardware even if you have 1000
> cores in the simulator; especially simulating the interconnect is
> likely to be slow.  And you can only simulate running software that
> you have, so if you want to simulate more than just a few benchmarks,
> you will have to do some serious software development.
>
> My point is: "At some point you have gone as far as practical
> with simulation, and then you build it, and it can still turn out that
> the interconnect is not up to the demands of real software for this
> chip."  And I think this is relevant to the discussion at hand.

You have your opinion and the industry has theirs.  CPU manufacturers 
spend gazillions of CPU cycles simulating bazillions of CPU cycles. 
Yes, there is always a limitation to how much you can do but you provide 
no evidence to show that limit is below of level of utility.  On the 
other hand, most CPUs are made with very few errors in spite of the many 
millions of transistors used.


>>>>>> The issue of performance is much more
>>>>>> of a risk in the software than the hardware.
>>>>>
>>>>> Nobody cares for a word processor that's ten times faster than MS
>>>>> Word.  OTOH, if your hardware is half as fast as the competition, you
>>>>> are toast.  Actually, looking at how AMD has fared lately, much less
>>>>> than a factor of 2 is already a big problem.
>>>>
>>>> I have no idea what your point is.
>>>
>>> I gave an example that contradicts your claim.
>>
>> I have no idea what you are talking about.
>
> "The issue of performance is much more of a risk in the software than
> the hardware."
>
> People often care more about other things in software, so bad
> performance is not such a big problem, and performance is not such a
> big risk (although that leads to the kind of don't-care-for-performace
> programming that leads to problems that are big enough to make
> projects fail; risk homeostatis at work).
>
>>> Why should a software maker invest in verifying a hardware design,
>>> especially one based on untried principles?
>>
>> Again you have drifted far off the original topic, a hardware design
>> that should be evaluated in the context of the software that would run
>> on it before being built.
>
> That's your claim, and you tried to support it with claims about
> software makers funding hardware development; I followed you there,
> and now you complain about me drifting from the original topic.
> Funny.

I have no idea what you are talking about.  I never said software makers 
would fund hardware development.  Read up ^^^^


>>> Sure, they write some benchmarks to show off the capabilities of their
>>> chips, but they certainly won't be doing any multi-year software
>>> development effort for it.  Maybe the hardware department will
>>> cooperate with a software department which will explore software
>>> scalability to some areas opened up by that chip, but the result will
>>> also just be proof-of-concepts.
>>
>> If they don't write software for it, who will?
>
> Who knows.  They have their paper published (or probably several).
> Mission accomplished.  Maybe there will be papers about programming
> the thing, maybe not.

There is a reason why they used 32 nm process, lower cost.  This is not 
a real chip, it is a research vehicle which is not constrained by the 
usual cost/benefit tradeoffs.  They don't plan to make any money from it 
either way.  They got someone else to pay for it.

This isn't done "all the time".  It is rare that such a chip is built 
without a clear understanding of how it will be used and how it will be 
programmed.  I only know of two examples of this, the kilocore and the 
GA144.  Where are the others.

-- 

Rick C

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

#48582

rickman <gnuarm@gmail.com> wrote:
> On 6/27/2016 10:40 AM, Anton Ertl wrote:
>> Who knows.  They have their paper published (or probably several).
>> Mission accomplished.  Maybe there will be papers about programming
>> the thing, maybe not.
> 
> There is a reason why they used 32 nm process, lower cost.  This is
> not a real chip, it is a research vehicle which is not constrained
> by the usual cost/benefit tradeoffs.  They don't plan to make any
> money from it either way.  They got someone else to pay for it.
> 
> This isn't done "all the time".  It is rare that such a chip is
> built without a clear understanding of how it will be used and how
> it will be programmed. 

It's a PhD project.  Universities do VLSI design, and they sometimes
do interesting things like this.  I don't understand why you're
complaining about it so much.  It seems like exactly the sort of
research that universities should be doing.

Andrew.

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

#48583

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> There is a reason why they used 32 nm process, lower cost.
> It's a PhD project.  Universities do VLSI design, and they sometimes
> do interesting things like this.  

But fabbing something in 32nm is still quite expensive.  They had to
have more justification to get it funded than "this sounds cool".

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

#48584

On 6/27/2016 3:50 PM, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 6/27/2016 10:40 AM, Anton Ertl wrote:
>>> Who knows.  They have their paper published (or probably several).
>>> Mission accomplished.  Maybe there will be papers about programming
>>> the thing, maybe not.
>>
>> There is a reason why they used 32 nm process, lower cost.  This is
>> not a real chip, it is a research vehicle which is not constrained
>> by the usual cost/benefit tradeoffs.  They don't plan to make any
>> money from it either way.  They got someone else to pay for it.
>>
>> This isn't done "all the time".  It is rare that such a chip is
>> built without a clear understanding of how it will be used and how
>> it will be programmed.
>
> It's a PhD project.  Universities do VLSI design, and they sometimes
> do interesting things like this.  I don't understand why you're
> complaining about it so much.  It seems like exactly the sort of
> research that universities should be doing.

What part of my posts do you see as a "complaint"?

-- 

Rick C

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

#48585

rickman <gnuarm@gmail.com> wrote:
> On 6/27/2016 3:50 PM, Andrew Haley wrote:
>> rickman <gnuarm@gmail.com> wrote:
>>> On 6/27/2016 10:40 AM, Anton Ertl wrote:
>>>> Who knows.  They have their paper published (or probably several).
>>>> Mission accomplished.  Maybe there will be papers about programming
>>>> the thing, maybe not.
>>>
>>> There is a reason why they used 32 nm process, lower cost.  This is
>>> not a real chip, it is a research vehicle which is not constrained
>>> by the usual cost/benefit tradeoffs.  They don't plan to make any
>>> money from it either way.  They got someone else to pay for it.
>>>
>>> This isn't done "all the time".  It is rare that such a chip is
>>> built without a clear understanding of how it will be used and how
>>> it will be programmed.
>>
>> It's a PhD project.  Universities do VLSI design, and they sometimes
>> do interesting things like this.  I don't understand why you're
>> complaining about it so much.  It seems like exactly the sort of
>> research that universities should be doing.
> 
> What part of my posts do you see as a "complaint"?

> I don't want to offend, but I think the idea that someone would
> spend half a mil building a chip without any idea of how to program
> it is a bit of nonsense.

Andrew,

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

#48543

On Sunday, June 26, 2016 at 3:16:03 AM UTC-7, Anton Ertl wrote:
> Sure, but what you can do in simulation is limited, and simulation is
> not free, either.  At some point you have gone as far as practical
> with simulation, and then you build it, and it can still turn out that
> the interconnect is not up to the demands of real software for this
> chip.

The MiniForth was developed entirely with a simulator. The physical hardware didn't exist until almost the end of the project. 

I wrote the assembler in such a way that it would not only generate the machine-code for the target processor, but would also generate a Forth program that ran on the host computer and simulated the target program. This results in much faster simulation than interpreting the target machine opcodes at run-time as done in most simulators.

I had a "dujour" file that described the hardware-design and which could be changed on a daily basis as the hardware-design changed, with the rest of the assembler/simulator remaining unchanged. Simulation of hardware is all about experimentation --- this is bottom-up design for hardware, similar to the bottom-up design that has always been used for software in the Forth world.

> Why should a software maker invest in verifying a hardware design,
> especially one based on untried principles?

The principles are not untried --- they are tried out in simulation, which is the point of simulation --- you are not really making any sense.

> Sure, they write some benchmarks to show off the capabilities of their
> chips, but they certainly won't be doing any multi-year software
> development effort for it.  Maybe the hardware department will
> cooperate with a software department which will explore software
> scalability to some areas opened up by that chip, but the result will
> also just be proof-of-concepts.

The idea of a "software maker" being distinct from the "chip maker" is absurd. I really get the impression that you don't have experience in real-world projects --- you just teach in the classroom.

The goal with the MiniForth was to develop a chip capable of running the motion-control program at the required speed (fast enough to significantly beat the competition who were using an MC68000 board) --- the motion-control program already existed and ran on the 80c320, but too slow. The hardware design was changed repeatedly (often on a daily basis) as needed. The software was written for the existing hardware design --- if it proved too slow, then the hardware design was modified to fix whatever the bottleneck was in performance --- this was done repeatedly until the software worked at the required speed.

The idea of building a new processor without having a specific goal in mind (a specific program that needs to run at a specific speed) seems absurd to me. If you don't have a goal, how will you know when your work is done or even if you are working in the right direction?

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web