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


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

Kilocore

Started byBrad Eckert <hwfwguy@gmail.com>
First post2016-06-22 21:56 -0700
Last post2016-06-27 11:05 -0700
Articles 9 on this page of 29 — 10 participants

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 2 of 2 — ← Prev page 1 [2]


#48469

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2016-06-23 14:15 +0000
Message-ID<2016Jun23.161542@mips.complang.tuwien.ac.at>
In reply to#48461
Brad Eckert <hwfwguy@gmail.com> writes:
>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 wor=
>ld applications. Apparently it was funded by several grants from the DOD an=
>d NSF. It's nice to see Chuck's ideas making into real research labs.

About contemporary with the seaForth chips, there were several
(research and other) CPUs with 64 or 80 (bigger than c18) cores, e.g.,
the Tilera stuff.  The stuff I have seen about the UC Davis chip looks
like being further along these lines (but I did not look closely).
What makes you think that it uses ideas from Chuck Moore?

- 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]


#48471

FromAndrew Haley <andrew29@littlepinkcloud.invalid>
Date2016-06-23 11:57 -0500
Message-ID<jtednXUPUchrifHKnZ2dnUU7-RfNnZ2d@supernews.com>
In reply to#48469
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Brad Eckert <hwfwguy@gmail.com> writes:
>>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 wor=
>>ld applications. Apparently it was funded by several grants from the DOD an=
>>d NSF. It's nice to see Chuck's ideas making into real research labs.
> 
> About contemporary with the seaForth chips, there were several
> (research and other) CPUs with 64 or 80 (bigger than c18) cores, e.g.,
> the Tilera stuff.  The stuff I have seen about the UC Davis chip looks
> like being further along these lines (but I did not look closely).
> What makes you think that it uses ideas from Chuck Moore?

Of course there's no way to know if the ideas came from there, but I
can see many similarities.  Of course, some ideas are just "in the
air" sometimes, and everyone is following the same path.  But I think
Chuck has been following it for longer.

http://vcl.ece.ucdavis.edu/pubs/theses/2015-1/

There are of course significant differences too: these aren't stack
processors AFAICS, and Chuck never used standard cells.

Andrew.

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


#48475

Fromrickman <gnuarm@gmail.com>
Date2016-06-23 16:25 -0400
Message-ID<nkhgjn$ulb$1@dont-email.me>
In reply to#48469
On 6/23/2016 10:15 AM, Anton Ertl wrote:
> Brad Eckert <hwfwguy@gmail.com> writes:
>> 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 wor=
>> ld applications. Apparently it was funded by several grants from the DOD an=
>> d NSF. It's nice to see Chuck's ideas making into real research labs.
>
> About contemporary with the seaForth chips, there were several
> (research and other) CPUs with 64 or 80 (bigger than c18) cores, e.g.,
> the Tilera stuff.  The stuff I have seen about the UC Davis chip looks
> like being further along these lines (but I did not look closely).
> What makes you think that it uses ideas from Chuck Moore?

I guess I don't really.  At that time Chuck's chips were the only ones I 
knew that used so many cores and I think the memo I read specifically 
talked about being low power as this would be used in hand held radios. 
Power consumption is a large factor in their use with over half the 
weight being the battery.  In fact, rather than being hand held 
actually, they tend to strap them on their backpack and use a cabled 
remote to control them.

-- 

Rick C

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


#48490

FromIlya Tarasov <ilya74.tarasov@gmail.com>
Date2016-06-24 04:18 -0700
Message-ID<585249be-4e3c-44d5-a128-c353e199b31c@googlegroups.com>
In reply to#48461
четверг, 23 июня 2016 г., 7:56:34 UTC+3 пользователь Brad Eckert написал:

> 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 was very interested how Moore implement his tools to model silicon. For my estimation, 1 GHz of clock speed was high enough value for that technology node. In reality, I've found no DRC in Moore's tools and no any idea of what DRC is for. Achieved clock speed for GA is about 600 MHz, and this is a kind of failure.

Silicon models are devided to several major groups. First, it is high-level modeling, which is very close to simple emulation. Having this model, programmers can evaluate future CPU characteristics and create key algorithms. Memory size, command set, peripheral etc. may be corrected here.

Next level is RTL model, based of Hardware Description Languages. Schematic is created here, and FPGA prototype is strongly recommended. Some real-world issues (like clock domain crossing) may appears and needs to be solved at this level. 

Physical model is heavily based on the silicon technology and libraries chosen. This is a completely different layer of modeling, which includes a numberous checking for physical effects on a real silicon.

Compare this to that has been done for GA.

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


#48498

FromBrad Eckert <hwfwguy@gmail.com>
Date2016-06-24 21:48 -0700
Message-ID<a8f61ff5-b257-41a7-83fe-65fa4d71a339@googlegroups.com>
In reply to#48490
On Friday, June 24, 2016 at 4:49:39 PM UTC-7, Ilya Tarasov wrote:
> четверг, 23 июня 2016 г., 7:56:34 UTC+3 пользователь Brad Eckert написал:
> 
> > 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 was very interested how Moore implement his tools to model silicon. For my estimation, 1 GHz of clock speed was high enough value for that technology node. In reality, I've found no DRC in Moore's tools and no any idea of what DRC is for. Achieved clock speed for GA is about 600 MHz, and this is a kind of failure.
> 
> Silicon models are devided to several major groups. First, it is high-level modeling, which is very close to simple emulation. Having this model, programmers can evaluate future CPU characteristics and create key algorithms. Memory size, command set, peripheral etc. may be corrected here.
> 
> Next level is RTL model, based of Hardware Description Languages. Schematic is created here, and FPGA prototype is strongly recommended. Some real-world issues (like clock domain crossing) may appears and needs to be solved at this level. 
> 
> Physical model is heavily based on the silicon technology and libraries chosen. This is a completely different layer of modeling, which includes a numberous checking for physical effects on a real silicon.
> 
> Compare this to that has been done for GA.

Yes, the difference is scalability. The industry design flow is scalable. Chuck's isn't. You could say that for many systems. Programming systems that scale up to "human ant farms" like Microsoft and Google have been the most successful. Forth is only as scalable as the programmer makes it, in the absence of the vendor adding clever features that help manage large projects.

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


#48497

Fromendlessboomcapitalism@gmail.com
Date2016-06-23 22:32 -0700
Message-ID<6ef20863-9117-4d5f-b623-6d5196af61af@googlegroups.com>
In reply to#48461
awesome!!!  when a f with usb vga and firefox?

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


#48541

Fromdarek.maksimiuk@gmail.com
Date2016-06-26 13:12 -0700
Message-ID<98fb8f21-15fb-44f3-bf40-fa7efb3337ca@googlegroups.com>
In reply to#48461
For sure these devices (http://www.xmos.com/products/silicon ) do not have 1000CPUs but there are available now. There was an attempt to port Forth to this architecture: http://www.xcore.com/projects/working-title-xs1-forth

Cheers,
 Darek 


On Thursday, 23 June 2016 06:56:34 UTC+2, 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.

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


#48545

FromMat <dambere@web.de>
Date2016-06-26 16:36 -0700
Message-ID<a76a3197-a33c-47f4-a6f0-6a47e399c71e@googlegroups.com>
In reply to#48461
The fabrication was sponsored by the Department of Defense. For relevant applications, such as image processing, encryption and data analysis,  the chip is likely a good fit.

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


#48576

Fromendlessboomcapitalism@gmail.com
Date2016-06-27 11:05 -0700
Message-ID<ab61c9fa-72f5-4ba0-b62c-8e5eb7f50dcc@googlegroups.com>
In reply to#48461
forth pc with web browser yet?

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

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


csiph-web