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

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

What is greenarrays up to lately?

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

Contents

  What is greenarrays up to lately? polymorph self <jackvanc3@gmail.com> - 2015-03-11 21:54 -0700
    Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-15 14:08 -0700
      Re: What is greenarrays up to lately? hughaguilar96@gmail.com - 2015-03-15 19:10 -0700
        Re: What is greenarrays up to lately? polymorph self <jackvanc3@gmail.com> - 2015-03-16 21:58 -0700
          Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-17 12:19 -0700
            Re: What is greenarrays up to lately? Jason Damisch <jasondamisch@yahoo.com> - 2015-03-17 13:24 -0700
      Re: What is greenarrays up to lately? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-16 18:03 +0000
      Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-16 19:42 +0000
        Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-17 16:26 -0400
          Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-19 11:24 +0000
            Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 00:12 -0400
              Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-21 23:03 +0000
                Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-21 21:14 -0400
                  Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-22 00:38 -0700
                    Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-22 18:35 -0400
                      Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-22 16:18 -0700
                        Re: What is greenarrays up to lately? Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-23 01:06 +0100
                          Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-22 22:20 -0400
                            Re: What is greenarrays up to lately? Jason Damisch <jasondamisch@yahoo.com> - 2015-03-23 08:02 -0700
                              Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-23 16:13 -0400
                  Offer + Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-08 09:51 +0100
                    Re: Offer + Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-04-10 00:47 -0400
      Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-17 16:24 -0400
        Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-17 13:57 -0700
          Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-17 14:36 -0700
            Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-17 16:36 -0700
              Re: What is greenarrays up to lately? Dennis Ruffer <daruffer@gmail.com> - 2015-03-18 07:00 -0700
              Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-18 15:54 -0700
                Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-18 19:27 -0400
                Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-18 16:44 -0700
                  Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-18 20:24 -0400
                    Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-19 07:22 -0700
                      Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-19 22:20 +0000
                        Re: What is greenarrays up to lately? Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-20 00:14 +0100
                          Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 08:24 -0700
                            Re: What is greenarrays up to lately? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-20 15:30 +0000
                              Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 08:49 -0700
                                Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 09:04 -0700
                              Re: What is greenarrays up to lately? Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-20 20:32 +0100
                            Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 12:31 -0400
                            Re: What is greenarrays up to lately? Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-20 19:44 +0100
                        Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 08:20 -0700
                      Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 00:22 -0400
                        Re: What is greenarrays up to lately? Mark Wills <markwills1970@gmail.com> - 2015-03-20 03:07 -0700
                          Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-20 08:41 -0700
                            Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 12:49 -0400
                            Re: What is greenarrays up to lately? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-21 13:29 +0000
                          Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 12:43 -0400
                            Re: What is greenarrays up to lately? Jason Damisch <jasondamisch@yahoo.com> - 2015-03-20 09:48 -0700
                    Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-19 07:34 -0700
                      Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-19 13:23 -0700
                        Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 00:51 -0400
                          Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-20 21:05 -0700
                            Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-21 04:04 -0400
                              Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-21 09:16 -0700
                                Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-21 14:02 -0400
                      Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-20 00:39 -0400
                  Re: What is greenarrays up to lately? JUERGEN <epldfpga@aol.com> - 2015-03-19 07:15 -0700
            Re: What is greenarrays up to lately? Howerd <howerdo@yahoo.co.uk> - 2015-03-18 00:09 -0700
              Re: What is greenarrays up to lately? Paul Rubin <no.email@nospam.invalid> - 2015-03-18 00:23 -0700
              Re: What is greenarrays up to lately? lynx <rinkasu@kaze.void.null> - 2015-03-19 23:40 +0000
          Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-17 23:16 -0400
      Re: What is greenarrays up to lately? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-18 11:05 +0000
    Re: What is greenarrays up to lately? rickman <gnuarm@gmail.com> - 2015-03-22 22:38 -0400

Page 1 of 4  [1] 2 3 4  Next page →

#37188 — What is greenarrays up to lately?

Can anyone speak to some forth working in the field apps greenarrays has achieved?

What kind of projects are they up to?

[toc] | [next] | [standalone]

#37273

On Thursday, March 12, 2015 at 4:54:08 AM UTC, polymorph self wrote:
> Can anyone speak to some forth working in the field apps greenarrays has achieved?
> 
> What kind of projects are they up to?

It seems, not much, as the whole clf community does not know anything - and even Greenarrays does not care to give any comment. 

It seems that the core used in the Green Arrays Project is not relevant to the whole CLF community.

I can understand that the HW is too expensive to try it out, 
and Greenarrays does not use any of the existing SW emulations either. 

But he existing Forth community does not take it serious, otherwise a simlation in Forth of the core would have been done.

The only guess I could have is that the military applications pay for the salaries of the people involved.

So part of the next generation star wars - or Mars?
Well just guessing - it seems too many NDAs involved?

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

#37278

On Sunday, March 15, 2015 at 2:08:14 PM UTC-7, JUERGEN wrote:
> On Thursday, March 12, 2015 at 4:54:08 AM UTC, polymorph self wrote:
> > Can anyone speak to some forth working in the field apps greenarrays has achieved?

> > What kind of projects are they up to?
> The only guess I could have is that the military applications pay for the salaries of the people involved.
> 
> So part of the next generation star wars - or Mars?
> Well just guessing - it seems too many NDAs involved?

The only application that I can think of for such a highly-parallel low-level system is code-breaking --- the number of possible keys can be narrowed down, but you still have a lot of possible keys and they just have to be exhaustively searched to find the one that works --- massive parallelism is the way to go, but each processor can be quite simple as it is just doing a simple logical operation.

GA would be terrible for "star wars" missile-defense, or a Mars mission --- both of these primarily involve fast precise motion-control (the MiniForth/RACE would be a better choice) --- there is no need for parallel processing.

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

#37322

On Sunday, March 15, 2015 at 10:10:35 PM UTC-4, hughag...@gmail.com wrote:
> On Sunday, March 15, 2015 at 2:08:14 PM UTC-7, JUERGEN wrote:
> > On Thursday, March 12, 2015 at 4:54:08 AM UTC, polymorph self wrote:
> > > Can anyone speak to some forth working in the field apps greenarrays has achieved?
> 
> > > What kind of projects are they up to?
> > The only guess I could have is that the military applications pay for the salaries of the people involved.
> > 
> > So part of the next generation star wars - or Mars?
> > Well just guessing - it seems too many NDAs involved?
> 
> The only application that I can think of for such a highly-parallel low-level system is code-breaking --- the number of possible keys can be narrowed down, but you still have a lot of possible keys and they just have to be exhaustively searched to find the one that works --- massive parallelism is the way to go, but each processor can be quite simple as it is just doing a simple logical operation.
> 
> GA would be terrible for "star wars" missile-defense, or a Mars mission --- both of these primarily involve fast precise motion-control (the MiniForth/RACE would be a better choice) --- there is no need for parallel processing.

robotic factories will set humanity free!!

esp ones building houses far apart large and cheap

and growing fruit in huge robofarms!

Id love to see a forth pc built from geenarrays shit!!  maybe bill gates would hire a hit squad tho

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

#37346

On Tuesday, March 17, 2015 at 4:58:53 AM UTC, polymorph self wrote:
> On Sunday, March 15, 2015 at 10:10:35 PM UTC-4, hughag...@gmail.com wrote:
> > On Sunday, March 15, 2015 at 2:08:14 PM UTC-7, JUERGEN wrote:
> > > On Thursday, March 12, 2015 at 4:54:08 AM UTC, polymorph self wrote:
> > > > Can anyone speak to some forth working in the field apps greenarrays has achieved?
> > 
> > > > What kind of projects are they up to?
> > > The only guess I could have is that the military applications pay for the salaries of the people involved.
> > > 
> > > So part of the next generation star wars - or Mars?
> > > Well just guessing - it seems too many NDAs involved?
> > 
> > The only application that I can think of for such a highly-parallel low-level system is code-breaking --- the number of possible keys can be narrowed down, but you still have a lot of possible keys and they just have to be exhaustively searched to find the one that works --- massive parallelism is the way to go, but each processor can be quite simple as it is just doing a simple logical operation.
> > 
> > GA would be terrible for "star wars" missile-defense, or a Mars mission --- both of these primarily involve fast precise motion-control (the MiniForth/RACE would be a better choice) --- there is no need for parallel processing.
> 
> robotic factories will set humanity free!!
> 
> esp ones building houses far apart large and cheap
> 
> and growing fruit in huge robofarms!
> 
> Id love to see a forth pc built from geenarrays shit!!  maybe bill gates would hire a hit squad tho

Polymorph, what the hell are you talking about? It does not make sense
Or are you just a Greenarrays based RLG - Random Word Generator? 
Not Forth Words in this context.

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

#37351

On Tuesday, March 17, 2015 at 12:19:58 PM UTC-7, JUERGEN wrote:

> Polymorph, what the hell are you talking about? It does not make sense
> Or are you just a Greenarrays based RLG - Random Word Generator? 
> Not Forth Words in this context.

Another name for Polymoph Self is Gavino.

Jason

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

#37301

In article <42d25675-3529-4aa7-8ff9-08f4ad256cef@googlegroups.com>,
JUERGEN  <epldfpga@aol.com> wrote:
>On Thursday, March 12, 2015 at 4:54:08 AM UTC, polymorph self wrote:
>> Can anyone speak to some forth working in the field apps greenarrays
>has achieved?
>>
>> What kind of projects are they up to?
>
>It seems, not much, as the whole clf community does not know anything -
>and even Greenarrays does not care to give any comment.
>
>It seems that the core used in the Green Arrays Project is not relevant
>to the whole CLF community.
>
>I can understand that the HW is too expensive to try it out,
>and Greenarrays does not use any of the existing SW emulations either.
>
>But he existing Forth community does not take it serious, otherwise a
>simlation in Forth of the core would have been done.

It has been done, and it is running the parpi program, where the
actual hardware doesn't. See
http://arrayfactor.org/

>
>The only guess I could have is that the military applications pay for
>the salaries of the people involved.
>
>So part of the next generation star wars - or Mars?
>Well just guessing - it seems too many NDAs involved?
>
-- 
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]

#37305

On Sun, 15 Mar 2015 14:08:11 -0700 (PDT)
JUERGEN <epldfpga@aol.com> wrote:

> On Thursday, March 12, 2015 at 4:54:08 AM UTC, polymorph self wrote:
> > Can anyone speak to some forth working in the field apps greenarrays has achieved?
> > 
> > What kind of projects are they up to?
> 
> It seems, not much, as the whole clf community does not know anything - and even Greenarrays does not care to give any comment. 
> 
> It seems that the core used in the Green Arrays Project is not relevant to the whole CLF community.
> 
> I can understand that the HW is too expensive to try it out, 
> and Greenarrays does not use any of the existing SW emulations either. 

It is possible to add link ports to the j1 or b16 processors so that 
they can be linked into an array.  

The processor can then boot from a link port. I've just started testing 
this on the j1, but the b16 is also close. 

> But he existing Forth community does not take it serious, otherwise a simlation in Forth of the core would have been done.

It's a bit more exciting if the simulation can export the design to the FPGA tools, then you are closer to having a chip.  

Jan Coombs. 
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

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

#37352

On 3/16/2015 3:42 PM, Jan Coombs <Jan-54 wrote:
 >
 > It's a bit more exciting if the simulation can export the design to 
the FPGA tools, then you are closer to having a chip.

I'm not sure what that means.  What design?  The chip or the code?  I'm 
not sure why the simulator is the right tool to be producing code.  The 
simulator is used to run the code you have produced.

-- 

Rick

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

#37430

On Tue, 17 Mar 2015 16:26:53 -0400
rickman <gnuarm@gmail.com> wrote:

> On 3/16/2015 3:42 PM, Jan Coombs <Jan-54 wrote:
>  >
>  > It's a bit more exciting if the simulation can export 
>  > the design to the FPGA tools, then you are closer to 
>  > having a chip. 
> 
> I'm not sure what that means.  What design?  The chip or the code?  

Both.  The simulator consumes the source code for the 
hardware design.  One file of which contains a simulation 
model for the target processor code ROM, and also FPGA 
chip family dependant code to initialize a matching RAM 
block on the chip. 


> I'm 
> not sure why the simulator is the right tool to be producing code.  The 
> simulator is used to run the code you have produced. 

It is right because the development is test driven, 
and good because the edit-test loop is very short.  


In more detail:

For each new feature a test is added to the test suite. 
Once a processor has grown to a certain size this might 
just mean adding a new target code fragment. 

The simulator [1] is used to perform a suite of tests 
to indicate that the last development step is not yet 
achieved, also, that achieving it has not broken the 
hardware design elsewhere. 

During a test run the simulator also exports Verilog 
and/or VHDL files for the chip tools.  This adds 
confidence that the hardware source is valid. 

By occasionally running the FPGA tools it can be seen 
that the code is still synthesizable, and that chip 
dependent features are catered for, for example, RAM 
initialisation to hold the target code.  

That's why I feel "closer to having a chip"  

Test driven development for hardware is still new to 
me; I understand the theory, but still fiddle... :) 

[1] http://www.myhdl.org/start/why.html

Jan Coombs. 
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

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

#37450

On 3/19/2015 7:24 AM, Jan Coombs <Jan-54 wrote:
> On Tue, 17 Mar 2015 16:26:53 -0400
> rickman <gnuarm@gmail.com> wrote:
>
>> On 3/16/2015 3:42 PM, Jan Coombs <Jan-54 wrote:
>>   >
>>   > It's a bit more exciting if the simulation can export
>>   > the design to the FPGA tools, then you are closer to
>>   > having a chip.
>>
>> I'm not sure what that means.  What design?  The chip or the code?
>
> Both.  The simulator consumes the source code for the
> hardware design.  One file of which contains a simulation
> model for the target processor code ROM, and also FPGA
> chip family dependant code to initialize a matching RAM
> block on the chip.

This is not clear to me at all.


>> I'm
>> not sure why the simulator is the right tool to be producing code.  The
>> simulator is used to run the code you have produced.
>
> It is right because the development is test driven,
> and good because the edit-test loop is very short.
>
>
> In more detail:
>
> For each new feature a test is added to the test suite.
> Once a processor has grown to a certain size this might
> just mean adding a new target code fragment.
>
> The simulator [1] is used to perform a suite of tests
> to indicate that the last development step is not yet
> achieved, also, that achieving it has not broken the
> hardware design elsewhere.
>
> During a test run the simulator also exports Verilog
> and/or VHDL files for the chip tools.  This adds
> confidence that the hardware source is valid.
>
> By occasionally running the FPGA tools it can be seen
> that the code is still synthesizable, and that chip
> dependent features are catered for, for example, RAM
> initialisation to hold the target code.
>
> That's why I feel "closer to having a chip"
>
> Test driven development for hardware is still new to
> me; I understand the theory, but still fiddle... :)
>
> [1] http://www.myhdl.org/start/why.html

You are talking about code describing the operation of the chip, not a 
simulator to test your software.  If you were designing a chip you would 
use an HDL like Verilog, VHDL or one of the others.  Otherwise you would 
be writing a whole lot more than just the code for the chip, you would 
be writing the simulator and synthesis engine too.

I can't say I follow what you are trying to say really.  You seem to be 
saying you would run a simulation on your code which is the test suite 
to test the HDL?  I think that would be most easily done in the HDL 
simulator, no?  That is what I did when I designed a CPU.  So in that 
sense I was *always* running the FPGA tools.

What tools are you talking about exactly?

-- 

Rick

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

#37527

On Fri, 20 Mar 2015 00:12:44 -0400
rickman <gnuarm@gmail.com> wrote:

> On 3/19/2015 7:24 AM, Jan Coombs <Jan-54 wrote:
> > On Tue, 17 Mar 2015 16:26:53 -0400
> > rickman <gnuarm@gmail.com> wrote:
> >
> >> On 3/16/2015 3:42 PM, Jan Coombs <Jan-54 wrote:
> >>   >
> >>   > It's a bit more exciting if the simulation can export
> >>   > the design to the FPGA tools, then you are closer to
> >>   > having a chip.
> >>
> >> I'm not sure what that means.  What design?  The chip or the code?
> >
> > Both.  The simulator consumes the source code for the
> > hardware design.  One file of which contains a simulation
> > model for the target processor code ROM, and also FPGA
> > chip family dependant code to initialize a matching RAM
> > block on the chip.
> 
> This is not clear to me at all. 

Anton writes a lot, it's his job.  I've only read a little of 
his work, but treasure a throwaway comment of his:

 'Some things have to be seen to be believed, but 
  Most things have to be believed to be seen'

The hardware development approach and prime tool I use are very 
different.  If you want to know how I do it, you might have to 
believe that the new methods I'm using could be good choices.

I've read our postings through quite a few times, and checked the 
link to the tools which I gave, which gives extensive details of 
the tool and rationale, but still fail to see what is not clear. 

Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

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

#37529

On 3/21/2015 7:03 PM, Jan Coombs <Jan-54 wrote:
> On Fri, 20 Mar 2015 00:12:44 -0400
> rickman <gnuarm@gmail.com> wrote:
>
>> On 3/19/2015 7:24 AM, Jan Coombs <Jan-54 wrote:
>>> On Tue, 17 Mar 2015 16:26:53 -0400
>>> rickman <gnuarm@gmail.com> wrote:
>>>
>>>> On 3/16/2015 3:42 PM, Jan Coombs <Jan-54 wrote:
>>>>    >
>>>>    > It's a bit more exciting if the simulation can export
>>>>    > the design to the FPGA tools, then you are closer to
>>>>    > having a chip.
>>>>
>>>> I'm not sure what that means.  What design?  The chip or the code?
>>>
>>> Both.  The simulator consumes the source code for the
>>> hardware design.  One file of which contains a simulation
>>> model for the target processor code ROM, and also FPGA
>>> chip family dependant code to initialize a matching RAM
>>> block on the chip.
>>
>> This is not clear to me at all.
>
> Anton writes a lot, it's his job.  I've only read a little of
> his work, but treasure a throwaway comment of his:
>
>   'Some things have to be seen to be believed, but
>    Most things have to be believed to be seen'
>
> The hardware development approach and prime tool I use are very
> different.  If you want to know how I do it, you might have to
> believe that the new methods I'm using could be good choices.
>
> I've read our postings through quite a few times, and checked the
> link to the tools which I gave, which gives extensive details of
> the tool and rationale, but still fail to see what is not clear.

The statements I was replying to and are quoted above are not clear to 
me.  I have no idea what is meant by "The simulator consumes the source 
code for the hardware design."  "Consuming" is not a term I often use 
with the design process.  Input is more common and is clear to me.  Is 
that what you mean?

Your description of what I think are the input files to the design 
process is not at all clear to me.  I have never thought of the design 
files as being separated by RAM and ROM.  I just don't understand what 
you are describing.  Are you trying to say there is an HDL file for the 
processor and there is a separate file which contains the instruction 
opcodes that are to be loaded into the program memory?  Perhaps you are 
describing a process where the program RAM can be loaded separately from 
the processor design to prevent having to change the bitstream file each 
time the program changes?

The original remark I didn't understand is:

 > It's a bit more exciting if the simulation can export the design to 
the FPGA tools, then you are closer to having a chip.

Here I don't understand the idea that a simulator would export a design. 
  A simulator has a design as its input.  The FPGA tools would use that 
same design to generate the bitstream for the FPGA.  Simulation is just 
a way to verifying the design does what you want before you program it 
into a chip.

I think you have an image in your mind of what you are talking about and 
I can't reconstruct that from what you write.

I thought we were talking about a simulator that is for testing code 
written for a given processor.  You seem to be talking about a simulator 
for the HDL that describes a processor.  The former is often much more 
efficient at running code while the latter is useful for debugging the 
processor design itself.

Are you describing a different development model?  Can you be a little 
more clear in your use of terms?

BTW, your quote from Anton did not help me understand any of this at all.

-- 

Rick

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

#37534

On Sunday, March 22, 2015 at 1:14:29 AM UTC, rickman wrote:
> On 3/21/2015 7:03 PM, Jan Coombs <Jan-54 wrote:
> > On Fri, 20 Mar 2015 00:12:44 -0400
> > rickman <gnuarm@gmail.com> wrote:
> >
> >> On 3/19/2015 7:24 AM, Jan Coombs <Jan-54 wrote:
> >>> On Tue, 17 Mar 2015 16:26:53 -0400
> >>> rickman <gnuarm@gmail.com> wrote:
> >>>
> >>>> On 3/16/2015 3:42 PM, Jan Coombs <Jan-54 wrote:
> >>>>    >
> >>>>    > It's a bit more exciting if the simulation can export
> >>>>    > the design to the FPGA tools, then you are closer to
> >>>>    > having a chip.
> >>>>
> >>>> I'm not sure what that means.  What design?  The chip or the code?
> >>>
> >>> Both.  The simulator consumes the source code for the
> >>> hardware design.  One file of which contains a simulation
> >>> model for the target processor code ROM, and also FPGA
> >>> chip family dependant code to initialize a matching RAM
> >>> block on the chip.
> >>
> >> This is not clear to me at all.
> >
> > Anton writes a lot, it's his job.  I've only read a little of
> > his work, but treasure a throwaway comment of his:
> >
> >   'Some things have to be seen to be believed, but
> >    Most things have to be believed to be seen'
> >
> > The hardware development approach and prime tool I use are very
> > different.  If you want to know how I do it, you might have to
> > believe that the new methods I'm using could be good choices.
> >
> > I've read our postings through quite a few times, and checked the
> > link to the tools which I gave, which gives extensive details of
> > the tool and rationale, but still fail to see what is not clear.
> 
> The statements I was replying to and are quoted above are not clear to 
> me.  I have no idea what is meant by "The simulator consumes the source 
> code for the hardware design."  "Consuming" is not a term I often use 
> with the design process.  Input is more common and is clear to me.  Is 
> that what you mean?
> 
> Your description of what I think are the input files to the design 
> process is not at all clear to me.  I have never thought of the design 
> files as being separated by RAM and ROM.  I just don't understand what 
> you are describing.  Are you trying to say there is an HDL file for the 
> processor and there is a separate file which contains the instruction 
> opcodes that are to be loaded into the program memory?  Perhaps you are 
> describing a process where the program RAM can be loaded separately from 
> the processor design to prevent having to change the bitstream file each 
> time the program changes?
> 
> The original remark I didn't understand is:
> 
>  > It's a bit more exciting if the simulation can export the design to 
> the FPGA tools, then you are closer to having a chip.
> 
> Here I don't understand the idea that a simulator would export a design. 
>   A simulator has a design as its input.  The FPGA tools would use that 
> same design to generate the bitstream for the FPGA.  Simulation is just 
> a way to verifying the design does what you want before you program it 
> into a chip.
> 
> I think you have an image in your mind of what you are talking about and 
> I can't reconstruct that from what you write.
> 
> I thought we were talking about a simulator that is for testing code 
> written for a given processor.  You seem to be talking about a simulator 
> for the HDL that describes a processor.  The former is often much more 
> efficient at running code while the latter is useful for debugging the 
> processor design itself.
> 
> Are you describing a different development model?  Can you be a little 
> more clear in your use of terms?
> 
> BTW, your quote from Anton did not help me understand any of this at all.
> 
> -- 
> 
> Rick

Rick, I would have to assume you allow for some slack in language.

Simulator written in SW ( any language - even Forth ) then the same running model transferred to the FPGA.

You could use Impulse with C to Fpga, or rewrite in VHDL/Verilog.

On the PC is running what is required.
- or you partition the design and move it to the FPGA in slices/blocks, the rest on the PC.

Has anybody done a Forth that compiles to FPGA? 
C to FPGA has been done a few times - see Impulse and Celoxica.

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

#37557

On 3/22/2015 3:38 AM, JUERGEN wrote:
> On Sunday, March 22, 2015 at 1:14:29 AM UTC, rickman wrote:
>> On 3/21/2015 7:03 PM, Jan Coombs <Jan-54 wrote:
>>> On Fri, 20 Mar 2015 00:12:44 -0400
>>> rickman <gnuarm@gmail.com> wrote:
>>>
>>>> On 3/19/2015 7:24 AM, Jan Coombs <Jan-54 wrote:
>>>>> On Tue, 17 Mar 2015 16:26:53 -0400
>>>>> rickman <gnuarm@gmail.com> wrote:
>>>>>
>>>>>> On 3/16/2015 3:42 PM, Jan Coombs <Jan-54 wrote:
>>>>>>     >
>>>>>>     > It's a bit more exciting if the simulation can export
>>>>>>     > the design to the FPGA tools, then you are closer to
>>>>>>     > having a chip.
>>>>>>
>>>>>> I'm not sure what that means.  What design?  The chip or the code?
>>>>>
>>>>> Both.  The simulator consumes the source code for the
>>>>> hardware design.  One file of which contains a simulation
>>>>> model for the target processor code ROM, and also FPGA
>>>>> chip family dependant code to initialize a matching RAM
>>>>> block on the chip.
>>>>
>>>> This is not clear to me at all.
>>>
>>> Anton writes a lot, it's his job.  I've only read a little of
>>> his work, but treasure a throwaway comment of his:
>>>
>>>    'Some things have to be seen to be believed, but
>>>     Most things have to be believed to be seen'
>>>
>>> The hardware development approach and prime tool I use are very
>>> different.  If you want to know how I do it, you might have to
>>> believe that the new methods I'm using could be good choices.
>>>
>>> I've read our postings through quite a few times, and checked the
>>> link to the tools which I gave, which gives extensive details of
>>> the tool and rationale, but still fail to see what is not clear.
>>
>> The statements I was replying to and are quoted above are not clear to
>> me.  I have no idea what is meant by "The simulator consumes the source
>> code for the hardware design."  "Consuming" is not a term I often use
>> with the design process.  Input is more common and is clear to me.  Is
>> that what you mean?
>>
>> Your description of what I think are the input files to the design
>> process is not at all clear to me.  I have never thought of the design
>> files as being separated by RAM and ROM.  I just don't understand what
>> you are describing.  Are you trying to say there is an HDL file for the
>> processor and there is a separate file which contains the instruction
>> opcodes that are to be loaded into the program memory?  Perhaps you are
>> describing a process where the program RAM can be loaded separately from
>> the processor design to prevent having to change the bitstream file each
>> time the program changes?
>>
>> The original remark I didn't understand is:
>>
>>   > It's a bit more exciting if the simulation can export the design to
>> the FPGA tools, then you are closer to having a chip.
>>
>> Here I don't understand the idea that a simulator would export a design.
>>    A simulator has a design as its input.  The FPGA tools would use that
>> same design to generate the bitstream for the FPGA.  Simulation is just
>> a way to verifying the design does what you want before you program it
>> into a chip.
>>
>> I think you have an image in your mind of what you are talking about and
>> I can't reconstruct that from what you write.
>>
>> I thought we were talking about a simulator that is for testing code
>> written for a given processor.  You seem to be talking about a simulator
>> for the HDL that describes a processor.  The former is often much more
>> efficient at running code while the latter is useful for debugging the
>> processor design itself.
>>
>> Are you describing a different development model?  Can you be a little
>> more clear in your use of terms?
>>
>> BTW, your quote from Anton did not help me understand any of this at all.
>>
>> --
>>
>> Rick
>
> Rick, I would have to assume you allow for some slack in language.

I'm not sure which language you mean, the language you are talking in or 
the language you are talking about simulating.

 > Simulator written in SW ( any language - even Forth ) then the same 
running model transferred to the FPGA.

Why do this?  The established method is to code your processor 
description in an HDL (as I said, there are several with VHDL and 
Verilog being the most popular) and simulate it using an HDL simulator. 
  At that point you have a complete description of the processor design 
which can be synthesized to bits for an FPGA or a layout for a chip design.

What is the reason for abandoning this method?  It works well and has 
lots of precedence meaning there are very usable tools available.


> You could use Impulse with C to Fpga, or rewrite in VHDL/Verilog.
>
> On the PC is running what is required.
> - or you partition the design and move it to the FPGA in slices/blocks, the rest on the PC.
>
> Has anybody done a Forth that compiles to FPGA?
> C to FPGA has been done a few times - see Impulse and Celoxica.

I have thought about Forth to generate hardware.  It would not be 
"descriptive" as in typical HDLs where you describe the behavior and let 
the tool figure out the implementation.  It would be descriptive by 
describing the logical elements and you build hierarchically like a 
Forth program.  Simulation is done by recompiling with a primitives 
library for simulation rather than synthesis.  I have not taken the 
first step in realizing this.

-- 

Rick

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

#37560

rickman <gnuarm@gmail.com> writes:
> I have thought about Forth to generate hardware.  It would not be
> "descriptive" as in typical HDLs where you describe the behavior and
> let the tool figure out the implementation.  It would be descriptive
> by describing the logical elements and you build hierarchically like a
> Forth program. 

That is basically what OKAD is, I believe.  The target is custom silicon
rather than FPGA equtions.

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

#37564

Paul Rubin wrote:

> rickman <gnuarm@gmail.com> writes:
>> I have thought about Forth to generate hardware.  It would not be
>> "descriptive" as in typical HDLs where you describe the behavior and
>> let the tool figure out the implementation.  It would be descriptive
>> by describing the logical elements and you build hierarchically like a
>> Forth program.
> 
> That is basically what OKAD is, I believe.  The target is custom silicon
> rather than FPGA equtions.

FPGAs have primitives like LUTs, flip-flops, and routing resources.  If you 
want to go the bottom up way on the FPGA, you would describe LUT functions, 
and build your more complex logic from assembling more LUTs.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

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

#37568

On 3/22/2015 8:06 PM, Bernd Paysan wrote:
> Paul Rubin wrote:
>
>> rickman <gnuarm@gmail.com> writes:
>>> I have thought about Forth to generate hardware.  It would not be
>>> "descriptive" as in typical HDLs where you describe the behavior and
>>> let the tool figure out the implementation.  It would be descriptive
>>> by describing the logical elements and you build hierarchically like a
>>> Forth program.
>>
>> That is basically what OKAD is, I believe.  The target is custom silicon
>> rather than FPGA equtions.
>
> FPGAs have primitives like LUTs, flip-flops, and routing resources.  If you
> want to go the bottom up way on the FPGA, you would describe LUT functions,
> and build your more complex logic from assembling more LUTs.

Back in the old days we did FPGA design using schematic drawings.  They 
were usually hierarchical.  More advanced drawings were essentially 
macros with parameters that could specify bus width, relative placement 
and other important features.  One person I knew was able to squeeze out 
the maximum performance by doing hand placement using these macros.  He 
initially resisted the change over to HDL until the FPGA apps engineers 
showed him he could do the same sort of hierarchical design in VHDL 
complete with all the Xilinx specific parameters.  He never looked back, 
lol.

I'm not crazy about logic inference (letting the compiler choose how to 
implement your code).  But that is how 99% of designs get done.  It can 
be a lot of work hand crafting FPGAs.  I can't see the benefit in 
designing your own language for FPGA design.  I expect custom chip 
design is different and for a simple chip, hand crafting can get you a 
lot.  But there is no way you could hand craft a large complex chip 
unless it was very regular like the GA144 or an FPGA.  Heck, even FPGAs 
are getting pretty complex these days with many specialized function 
blocks and hard cores.  I don't suppose they hand craft much of that.

If the GA144 had some hard macro functions like 480 Mbps USB or 100 Mbps 
Ethernet, it would be a much more useful device, but would have been 
much harder to design.

-- 

Rick

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

#37589

On Sunday, March 22, 2015 at 7:20:14 PM UTC-7, rickman wrote:

> If the GA144 had some hard macro functions like 480 Mbps USB or 100 Mbps 
> Ethernet, it would be a much more useful device, but would have been 
> much harder to design.

Gripe, Moan, Complain,

Let's see -you- create your own circuit design system, 
your own microprocessor, and then your own OS with your
own applications and then come to the realization that....

You can please some of the people most of the time, and
you can please most of the people some of the time, but
you can't please all of the people all of the time.

That is, unless you are Sun/Oracle.  Then the gods love
you and everybody just agrees.

Jason

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

#37600

On 3/23/2015 11:02 AM, Jason Damisch wrote:
> On Sunday, March 22, 2015 at 7:20:14 PM UTC-7, rickman wrote:
>
>> If the GA144 had some hard macro functions like 480 Mbps USB or 100 Mbps
>> Ethernet, it would be a much more useful device, but would have been
>> much harder to design.
>
> Gripe, Moan, Complain,
>
> Let's see -you- create your own circuit design system,
> your own microprocessor, and then your own OS with your
> own applications and then come to the realization that....
>
> You can please some of the people most of the time, and
> you can please most of the people some of the time, but
> you can't please all of the people all of the time.
>
> That is, unless you are Sun/Oracle.  Then the gods love
> you and everybody just agrees.
>
> Jason

No I didn't create my own circuit design system,
I didn't create my own microprocessor...(well actually I did, but we 
won't get into that)
I didn't create my own OS...

But the devices I build don't sit on the shelf wanting someone to use 
them either...

I think that most people discussing the GA144 in a negative light are 
really lamenting that it fell so short of what it could have been.

Sometimes I think of designing as exploring a large mansion with many, 
many rooms.  You find rooms that have no lights, some rooms have no 
furniture, some rooms have no heat.  To live in a room you need to find 
one that provides everything you need and does it well.  Exploring and 
finding a room that has some really nice artwork on the wall doesn't 
make up for the lack of running water anywhere on the hallway.  You 
can't live in it.

-- 

Rick

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web