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


Groups > comp.lang.forth > #48512

Re: Kilocore

From rickman <gnuarm@gmail.com>
Newsgroups comp.lang.forth
Subject Re: Kilocore
Date 2016-06-25 14:00 -0400
Organization A noiseless patient Spider
Message-ID <nkmgrt$4dg$1@dont-email.me> (permalink)
References (4 earlier) <2016Jun24.122108@mips.complang.tuwien.ac.at> <nkjk3r$9g9$1@dont-email.me> <2016Jun24.175754@mips.complang.tuwien.ac.at> <nkjmvn$kcf$1@dont-email.me> <2016Jun25.161016@mips.complang.tuwien.ac.at>

Show all headers | View raw


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

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web