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

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

Forth in VHDL

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

Contents

  Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-24 22:29 -0400
    Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-24 23:01 -0400
      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-24 23:05 -0400
        Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 22:25 -0500
          Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 00:08 -0400
            Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 23:57 -0500
              Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 01:22 -0400
                Re: Forth in VHDL Paul Rubin <no.email@nospam.invalid> - 2016-07-24 22:38 -0700
                  Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 01:53 -0400
                    Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 05:31 -0700
                      Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 05:36 -0700
                        Re: Forth in VHDL Richard Owlett <rowlett@cloud85.net> - 2016-07-25 08:14 -0500
                          Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 07:37 -0700
                          Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 08:01 -0700
                Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-25 14:11 -0500
                  Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 17:39 -0400
                    Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-25 18:01 -0500
                      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 19:40 -0400
                  Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-26 11:04 +0100
                    Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-26 11:13 -0400
                      Re: Forth in VHDL anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-26 16:00 +0000
                        Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-26 12:58 -0400
                          Re: Forth in VHDL anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 09:39 +0000
                            Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 10:01 -0400
                        Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-27 22:46 +0100
                    Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-26 09:43 -0700
                      Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-28 09:12 +0100
                        Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-28 05:04 -0400
                        Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-28 07:56 -0700
                          Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-28 13:04 -0400
                          Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-08-02 12:21 +0100
                        Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-28 08:02 -0700
      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 18:15 -0400
        Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-28 15:19 -0700
          Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-31 18:43 -0400
            Re: Forth in VHDL Paul Rubin <no.email@nospam.invalid> - 2016-07-31 17:10 -0700
    Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 20:08 -0700
      Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 20:33 -0700
        Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 22:58 -0500
          Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 00:17 -0400
            Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-25 10:02 -0700
              Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 14:13 -0400
                Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 14:17 -0400
                Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-25 15:04 -0700
                  Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 19:28 -0400
                    Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-25 17:20 -0700
                      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 23:07 -0400
                    Re: Forth in VHDL Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-26 03:07 -0500
                      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-26 13:05 -0400
                        Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-26 16:22 -0700
                        Re: Forth in VHDL Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 03:57 -0500
                          Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 10:34 -0400
                            Re: Forth in VHDL Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 11:15 -0500
                              Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 12:51 -0400
                                Re: Forth in VHDL Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 16:12 -0500
                                  Re: Forth in VHDL "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 12:43 -1000
                                    Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-28 00:40 -0400
                                    Re: Forth in VHDL hughaguilar96@gmail.com - 2016-08-02 22:45 -0700
                                  Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-28 00:39 -0400
    Re: Forth in VHDL wzab01@gmail.com - 2016-07-25 01:48 -0700
    Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 05:57 -0700
      Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 06:02 -0700
      Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-30 16:40 +0100
        Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-08-01 08:58 -0700
      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-31 17:10 -0400
        Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-08-01 09:02 -0700
    Re: Forth in VHDL Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-07-29 05:42 -0700

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

#49421 — Forth in VHDL

I wonder how hard it would be to write a Forth in VHDL?  It would likely 
be as easy to do in non-synthesizable code as any other language.  It 
might be a bit harder in synthesizable code.  For one, the I/O would 
need to be constructed from scratch based on some hardware interface. 
The non-synthesizable code could just read from a file... I wonder if 
you can read from the console in VHDL?  I've never tried that before.

-- 

Rick C

[toc] | [next] | [standalone]

#49422

On 7/24/2016 10:29 PM, rickman wrote:
> I wonder how hard it would be to write a Forth in VHDL?  It would likely
> be as easy to do in non-synthesizable code as any other language.  It
> might be a bit harder in synthesizable code.  For one, the I/O would
> need to be constructed from scratch based on some hardware interface.
> The non-synthesizable code could just read from a file... I wonder if
> you can read from the console in VHDL?  I've never tried that before.

I did a little digging and it looks like you *can* do console I/O in 
VHDL using the textio package.  So I can't think of anything to stop a 
vforth from being written... unless the vforth name has already been used.

-- 

Rick C

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

#49423

On 7/24/2016 11:01 PM, rickman wrote:
> On 7/24/2016 10:29 PM, rickman wrote:
>> I wonder how hard it would be to write a Forth in VHDL?  It would likely
>> be as easy to do in non-synthesizable code as any other language.  It
>> might be a bit harder in synthesizable code.  For one, the I/O would
>> need to be constructed from scratch based on some hardware interface.
>> The non-synthesizable code could just read from a file... I wonder if
>> you can read from the console in VHDL?  I've never tried that before.
>
> I did a little digging and it looks like you *can* do console I/O in
> VHDL using the textio package.  So I can't think of anything to stop a
> vforth from being written... unless the vforth name has already been used.

Looks like the name vforth has been used before... twice!  Once for a 
VIC forth and once, more recently for a VAX forth?  Really?  Do people 
still have VAX computers?  Or is this run on a VAX emulator?  Maybe 
that's a retro thing?

So it looks like nothing stands in the way of writing a Forth in VHDL 
other than free time... which I seem to have a lot of.  ;)

-- 

Rick C

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

#49425

On 7/24/2016 10:05 PM, rickman wrote:
> On 7/24/2016 11:01 PM, rickman wrote:
>> On 7/24/2016 10:29 PM, rickman wrote:
>>> I wonder how hard it would be to write a Forth in VHDL?  It would likely
>>> be as easy to do in non-synthesizable code as any other language.  It
>>> might be a bit harder in synthesizable code.  For one, the I/O would
>>> need to be constructed from scratch based on some hardware interface.
>>> The non-synthesizable code could just read from a file... I wonder if
>>> you can read from the console in VHDL?  I've never tried that before.
>>
>> I did a little digging and it looks like you *can* do console I/O in
>> VHDL using the textio package.  So I can't think of anything to stop a
>> vforth from being written... unless the vforth name has already been
>> used.
>
> Looks like the name vforth has been used before... twice!  Once for a
> VIC forth and once, more recently for a VAX forth?  Really?  Do people
> still have VAX computers?  Or is this run on a VAX emulator?  Maybe
> that's a retro thing?
>
> So it looks like nothing stands in the way of writing a Forth in VHDL
> other than free time... which I seem to have a lot of.  ;)
>
But what would you gain? It would be horribly slow and no benefit that I 
can see. Better to use VHDL to create a CPU that runs Forth natively, 
that is why I been working on some of the Forth CPUs that run in FPGAs.

Aside from the above mentioned it would be interesting to create 
hardware that runs Forth natively, not a CPU but a set of hardware that 
runs the code natively.

Are you still recovering?

-- 
Cecil - k5nwa

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

#49431

On 7/24/2016 11:25 PM, Cecil Bayona wrote:
> On 7/24/2016 10:05 PM, rickman wrote:
>> On 7/24/2016 11:01 PM, rickman wrote:
>>> On 7/24/2016 10:29 PM, rickman wrote:
>>>> I wonder how hard it would be to write a Forth in VHDL?  It would
>>>> likely
>>>> be as easy to do in non-synthesizable code as any other language.  It
>>>> might be a bit harder in synthesizable code.  For one, the I/O would
>>>> need to be constructed from scratch based on some hardware interface.
>>>> The non-synthesizable code could just read from a file... I wonder if
>>>> you can read from the console in VHDL?  I've never tried that before.
>>>
>>> I did a little digging and it looks like you *can* do console I/O in
>>> VHDL using the textio package.  So I can't think of anything to stop a
>>> vforth from being written... unless the vforth name has already been
>>> used.
>>
>> Looks like the name vforth has been used before... twice!  Once for a
>> VIC forth and once, more recently for a VAX forth?  Really?  Do people
>> still have VAX computers?  Or is this run on a VAX emulator?  Maybe
>> that's a retro thing?
>>
>> So it looks like nothing stands in the way of writing a Forth in VHDL
>> other than free time... which I seem to have a lot of.  ;)
>>
> But what would you gain? It would be horribly slow and no benefit that I
> can see. Better to use VHDL to create a CPU that runs Forth natively,
> that is why I been working on some of the Forth CPUs that run in FPGAs.
>
> Aside from the above mentioned it would be interesting to create
> hardware that runs Forth natively, not a CPU but a set of hardware that
> runs the code natively.
>
> Are you still recovering?

Recovery is going pretty well, thanks for asking.  I have regained most 
of the muscle strength lost from limping very abnormally for some years. 
  I still have swelling in the operated leg but no one is very concerned 
and it seems to be better the last week or so.  They did an ultrasound 
to rule out DVT so it should just be some more time.

The funny part is that my work no longer requires much of me other than 
pushing paper and staying on top of things.  I accept orders for 
hardware I sell and place the orders with my fabrication house.  When 
they complete testing and ship the boards I send the invoice to the 
customer and pay the fab house.  Lots of profit with very little work. 
In fact, technically I was working during my surgery (waiting for boards 
to be fabbed).  That's the main reason why I have free time.

I was thinking in terms of a Forth interpreter for use as a test bench. 
Currently I write test benches one of three ways.  Either I write ad hoc 
code that generates arbitrary signals based on the requirements of the 
object being tested - or I use another copy of the hardware being tested 
as the tester when it uses a symmetrical interface - or for interfaces 
with well parameterized functionality, I write a text interpreter which 
reads commands from a file to control the testing.

Using a Forth interpreter would allow me to handle any of the above in 
Forth directly reading and writing I/Os to the device under test - or 
connecting inputs and outputs of various modules - or reading commands 
from a file to manipulate interfaces.

You are thinking of speed in terms of something real time.  VHDL 
simulation are nowhere near real time.  But it would be nice to program 
a test bench in something other than VHDL.

As to a "directly executing" Forth CPU, what would that be exactly? 
Hardware is hardware.  To design it requires forming an idea of the 
hardware.  The only hardware I have thought of to execute Forth would be 
the same sort of stack machines I've seen many times and designed 
myself.  Not much new there.  What would a "native" Forth machine look 
like other than a dual stack CPU which is what the Forth virtual machine 
is?

-- 

Rick C

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

#49436

On 7/24/2016 11:08 PM, rickman wrote:
> On 7/24/2016 11:25 PM, Cecil Bayona wrote:
>> On 7/24/2016 10:05 PM, rickman wrote:

>> Are you still recovering?
>
> Recovery is going pretty well, thanks for asking.  I have regained most
> of the muscle strength lost from limping very abnormally for some years.
>  I still have swelling in the operated leg but no one is very concerned
> and it seems to be better the last week or so.  They did an ultrasound
> to rule out DVT so it should just be some more time.
>
> The funny part is that my work no longer requires much of me other than
> pushing paper and staying on top of things.  I accept orders for
> hardware I sell and place the orders with my fabrication house.  When
> they complete testing and ship the boards I send the invoice to the
> customer and pay the fab house.  Lots of profit with very little work.
> In fact, technically I was working during my surgery (waiting for boards
> to be fabbed).  That's the main reason why I have free time.
>
Good to hear you are doing better, it might take a while of therapy and 
exercises until you are closer to being your old self physically.

Myself tomorrow I will go to the doctor in the morning to figure out 
what to try next, I'm not responding to very expensive medicine so I 
might have to take desperate measures to bring my health under control.

>
> As to a "directly executing" Forth CPU, what would that be exactly?
> Hardware is hardware.  To design it requires forming an idea of the
> hardware.  The only hardware I have thought of to execute Forth would be
> the same sort of stack machines I've seen many times and designed
> myself.  Not much new there.  What would a "native" Forth machine look
> like other than a dual stack CPU which is what the Forth virtual machine
> is?
>
I've seen CPUs made from asynchronous random logic rather your typical 
synchronous logic like almost all standard CPUs, they tend to be a 
little faster but a nightmare to debug. You would still have the 
registers but most of the logic would be random logic versus nice state 
machines and everything running off a master clock. Not any major 
advantages other than being a little bit faster but lots of 
disadvantages, timing is a nightmare, so is debugging it.

No enough gains to justify the problems so I stick to nice synchronous 
logic, one is better off with CPUs like the ep32, five packed 
instructions to a 32 bit word, TOS an NOS on registers, single clock 
execution of instructions, a nice machine, another nice one is the J1 
capable of multiple instruction execution in one clock.


-- 
Cecil - k5nwa

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

#49441

On 7/25/2016 12:57 AM, Cecil Bayona wrote:
> On 7/24/2016 11:08 PM, rickman wrote:
>> On 7/24/2016 11:25 PM, Cecil Bayona wrote:
>>> On 7/24/2016 10:05 PM, rickman wrote:
>
>>> Are you still recovering?
>>
>> Recovery is going pretty well, thanks for asking.  I have regained most
>> of the muscle strength lost from limping very abnormally for some years.
>>  I still have swelling in the operated leg but no one is very concerned
>> and it seems to be better the last week or so.  They did an ultrasound
>> to rule out DVT so it should just be some more time.
>>
>> The funny part is that my work no longer requires much of me other than
>> pushing paper and staying on top of things.  I accept orders for
>> hardware I sell and place the orders with my fabrication house.  When
>> they complete testing and ship the boards I send the invoice to the
>> customer and pay the fab house.  Lots of profit with very little work.
>> In fact, technically I was working during my surgery (waiting for boards
>> to be fabbed).  That's the main reason why I have free time.
>>
> Good to hear you are doing better, it might take a while of therapy and
> exercises until you are closer to being your old self physically.
>
> Myself tomorrow I will go to the doctor in the morning to figure out
> what to try next, I'm not responding to very expensive medicine so I
> might have to take desperate measures to bring my health under control.

If you mentioned this before I don't recall.  Sounds like it might be 
serious.


>> As to a "directly executing" Forth CPU, what would that be exactly?
>> Hardware is hardware.  To design it requires forming an idea of the
>> hardware.  The only hardware I have thought of to execute Forth would be
>> the same sort of stack machines I've seen many times and designed
>> myself.  Not much new there.  What would a "native" Forth machine look
>> like other than a dual stack CPU which is what the Forth virtual machine
>> is?
>>
> I've seen CPUs made from asynchronous random logic rather your typical
> synchronous logic like almost all standard CPUs, they tend to be a
> little faster but a nightmare to debug. You would still have the
> registers but most of the logic would be random logic versus nice state
> machines and everything running off a master clock. Not any major
> advantages other than being a little bit faster but lots of
> disadvantages, timing is a nightmare, so is debugging it.

The speed advantage of async logic is essentially a myth in that you 
have to design for real time needs which means deadlines.  An async 
processor can be faster due to the various factors which affect timing, 
but you have to allow for all these factors being the worst possible in 
calculating if you can meet your deadlines.  Same as clocked logic, but 
rather than at the clock cycle, at the system level.

I had this discussion once and the only app anyone came up with was 
networking.  It is not uncommon for CPUs to become saturated so that 
packets fall on the floor when the CPU is slammed.  An async processor 
would be able to utilize any speed advantage it might have to process 
more packets before dropping any.


> No enough gains to justify the problems so I stick to nice synchronous
> logic, one is better off with CPUs like the ep32, five packed
> instructions to a 32 bit word, TOS an NOS on registers, single clock
> execution of instructions, a nice machine, another nice one is the J1
> capable of multiple instruction execution in one clock.

You really can't design async logic in FPGAs that I know of.  It has to 
be custom chips.  Achronix is developing async logic FPGAs, but I think 
they are intent on the really big customers only, small users need not 
apply.

I looked at what amounts to VLIW for MISC processors (sounds like an 
oxymoron, no?)  The ide was that there are three processors in any two 
stack machine.  1) the instruction processor, 2) tThe data (stack) 
processor, 3) the return (I call it the address) processor.  Each one 
could do something independent on each instruction cycle.  The 
instructions can be encoded (standard MISC instructions) or the 
instructions can be separate, one for each of the three processors 
(which is the main idea behind VLIW).  Various combinations of 
instructions give the basic primitives but many other useful 
combinations as well such as a return on any instruction that doesn't 
conflict with the hardware usage.

I only looked at this for a bit.  I believe that is how the J1 gets some 
parallelism.  My stumbling block was in writing a compiler to take 
advantage of this.  But then I don't really intend to program any of my 
apps in Forth really.  I would just code it in the stack machine 
assembly, not unlike what Chuck Moore does for the F18A.  Forth is used 
to write the macro assembler.

-- 

Rick C

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

#49442

rickman <gnuarm@gmail.com> writes:
> The speed advantage of async logic is essentially a myth in that you
> have to design for real time needs which means deadlines.  

I thought the idea was instructions could have variable latency
depending on the data, and async meant you could start the next
instruction as soon as the previous one finished.

> You really can't design async logic in FPGAs that I know of.  It has
> to be custom chips.

Hmm, I wonder what the obstacle is.  Certainly async was used in old
discrete or low-integration machines like the PDP-6 and KA10 from the
1970s.  I think it feel out of favor as machines got more complex, due
to debugging headaches etc.

> I looked at what amounts to VLIW for MISC processors

That's sort of what the Novix was, I thought.

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

#49443

On 7/25/2016 1:38 AM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> The speed advantage of async logic is essentially a myth in that you
>> have to design for real time needs which means deadlines.
>
> I thought the idea was instructions could have variable latency
> depending on the data, and async meant you could start the next
> instruction as soon as the previous one finished.

It is not really without a clock, just no single, system clock.  Each 
data path has to be timed by a parallel path of logic to create the 
clock.  In the F18A, there are a number of paths which are separately 
timed, but roughly they fall into three or four groups with the same 
delay.  This is not unlike clocked processors with multiple clock 
instructions.  The slow paths are broken into more than one clock cycle.

I shouldn't say there is "no" speedup.  But I've not seen anything that 
says it is very significant.


>> You really can't design async logic in FPGAs that I know of.  It has
>> to be custom chips.
>
> Hmm, I wonder what the obstacle is.  Certainly async was used in old
> discrete or low-integration machines like the PDP-6 and KA10 from the
> 1970s.  I think it feel out of favor as machines got more complex, due
> to debugging headaches etc.

Async logic requires very different design.  There is truly async logic 
which has no clocks at all.  This is hard to design requiring "coverage" 
of boundaries between product terms to make sure there is no glitching 
when inputs change which should result in no output changes.  But what 
is talked about in processors should be called "self timed" logic.

Self timed logic requires a lot more timing data than FPGA makers are 
willing to commit to.  It would be a PITA for them to characterize it 
and then test to it.  All for fairly marginal advantages... unless 
Achronix finds an easier way to make it all happen.


>> I looked at what amounts to VLIW for MISC processors
>
> That's sort of what the Novix was, I thought.

I don't think it is literally separate instructions for the various 
internal processors, but I haven't looked at it in depth.  It does 
provide for data movements in parallel.  But then the CPU I designed had 
very simple data paths.  I don't know so much about the Novix, but I 
think it had a lot of data path features.

-- 

Rick C

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

#49471

On Monday, July 25, 2016 at 6:53:47 AM UTC+1, rickman wrote:
> On 7/25/2016 1:38 AM, Paul Rubin wrote:
> > rickman <gnuarm@gmail.com> writes:
> >> The speed advantage of async logic is essentially a myth in that you
> >> have to design for real time needs which means deadlines.
> >
> > I thought the idea was instructions could have variable latency
> > depending on the data, and async meant you could start the next
> > instruction as soon as the previous one finished.
> 
> It is not really without a clock, just no single, system clock.  Each 
> data path has to be timed by a parallel path of logic to create the 
> clock.  In the F18A, there are a number of paths which are separately 
> timed, but roughly they fall into three or four groups with the same 
> delay.  This is not unlike clocked processors with multiple clock 
> instructions.  The slow paths are broken into more than one clock cycle.
> 
> I shouldn't say there is "no" speedup.  But I've not seen anything that 
> says it is very significant.
> 
> 
> >> You really can't design async logic in FPGAs that I know of.  It has
> >> to be custom chips.
> >
> > Hmm, I wonder what the obstacle is.  Certainly async was used in old
> > discrete or low-integration machines like the PDP-6 and KA10 from the
> > 1970s.  I think it feel out of favor as machines got more complex, due
> > to debugging headaches etc.
> 
> Async logic requires very different design.  There is truly async logic 
> which has no clocks at all.  This is hard to design requiring "coverage" 
> of boundaries between product terms to make sure there is no glitching 
> when inputs change which should result in no output changes.  But what 
> is talked about in processors should be called "self timed" logic.
> 
> Self timed logic requires a lot more timing data than FPGA makers are 
> willing to commit to.  It would be a PITA for them to characterize it 
> and then test to it.  All for fairly marginal advantages... unless 
> Achronix finds an easier way to make it all happen.
> 
> 
> >> I looked at what amounts to VLIW for MISC processors
> >
> > That's sort of what the Novix was, I thought.
> 
> I don't think it is literally separate instructions for the various 
> internal processors, but I haven't looked at it in depth.  It does 
> provide for data movements in parallel.  But then the CPU I designed had 
> very simple data paths.  I don't know so much about the Novix, but I 
> think it had a lot of data path features.
> 
> -- 
> 
> Rick C

For people who want a bit of collected asynchronous background - Theseus was good in that and you see some older info at http://www.exemark.com/asynch/articles.html
The problems are still the same: tools, the advantage is mainly less current consumption - even with the additional complexity, but synchronous is simpler.

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

#49472

On Monday, July 25, 2016 at 1:31:40 PM UTC+1, JUERGEN wrote:
> On Monday, July 25, 2016 at 6:53:47 AM UTC+1, rickman wrote:
> > On 7/25/2016 1:38 AM, Paul Rubin wrote:
> > > rickman <gnuarm@gmail.com> writes:
> > >> The speed advantage of async logic is essentially a myth in that you
> > >> have to design for real time needs which means deadlines.
> > >
> > > I thought the idea was instructions could have variable latency
> > > depending on the data, and async meant you could start the next
> > > instruction as soon as the previous one finished.
> > 
> > It is not really without a clock, just no single, system clock.  Each 
> > data path has to be timed by a parallel path of logic to create the 
> > clock.  In the F18A, there are a number of paths which are separately 
> > timed, but roughly they fall into three or four groups with the same 
> > delay.  This is not unlike clocked processors with multiple clock 
> > instructions.  The slow paths are broken into more than one clock cycle.
> > 
> > I shouldn't say there is "no" speedup.  But I've not seen anything that 
> > says it is very significant.
> > 
> > 
> > >> You really can't design async logic in FPGAs that I know of.  It has
> > >> to be custom chips.
> > >
> > > Hmm, I wonder what the obstacle is.  Certainly async was used in old
> > > discrete or low-integration machines like the PDP-6 and KA10 from the
> > > 1970s.  I think it feel out of favor as machines got more complex, due
> > > to debugging headaches etc.
> > 
> > Async logic requires very different design.  There is truly async logic 
> > which has no clocks at all.  This is hard to design requiring "coverage" 
> > of boundaries between product terms to make sure there is no glitching 
> > when inputs change which should result in no output changes.  But what 
> > is talked about in processors should be called "self timed" logic.
> > 
> > Self timed logic requires a lot more timing data than FPGA makers are 
> > willing to commit to.  It would be a PITA for them to characterize it 
> > and then test to it.  All for fairly marginal advantages... unless 
> > Achronix finds an easier way to make it all happen.
> > 
> > 
> > >> I looked at what amounts to VLIW for MISC processors
> > >
> > > That's sort of what the Novix was, I thought.
> > 
> > I don't think it is literally separate instructions for the various 
> > internal processors, but I haven't looked at it in depth.  It does 
> > provide for data movements in parallel.  But then the CPU I designed had 
> > very simple data paths.  I don't know so much about the Novix, but I 
> > think it had a lot of data path features.
> > 
> > -- 
> > 
> > Rick C
> 
> For people who want a bit of collected asynchronous background - Theseus was good in that and you see some older info at http://www.exemark.com/asynch/articles.html
> The problems are still the same: tools, the advantage is mainly less current consumption - even with the additional complexity, but synchronous is simpler.

It seems, many of the links are dead, go for the DOWNLOADS which are mostly from the exemark website - seems I have to place the old articles as scan or PDF now.

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

#49476

On 7/25/2016 7:36 AM, JUERGEN wrote:
>
>>
>> For people who want a bit of collected asynchronous background - Theseus was good in that and you see some older info at http://www.exemark.com/asynch/articles.html
>> The problems are still the same: tools, the advantage is mainly less current consumption - even with the additional complexity, but synchronous is simpler.
>
> It seems, many of the links are dead, go for the DOWNLOADS which are mostly from the exemark website - seems I have to place the old articles as scan or PDF now.
>

Have you tried the Wayback Machine.
http://web.archive.org/web/*/http://www.exemark.com/asynch/articles.html 
gives hits from 2003-2007.
HTH

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

#49477

On Monday, July 25, 2016 at 2:14:22 PM UTC+1, Richard Owlett wrote:
> On 7/25/2016 7:36 AM, JUERGEN wrote:
> >
> >>
> >> For people who want a bit of collected asynchronous background - Theseus was good in that and you see some older info at http://www.exemark.com/asynch/articles.html
> >> The problems are still the same: tools, the advantage is mainly less current consumption - even with the additional complexity, but synchronous is simpler.
> >
> > It seems, many of the links are dead, go for the DOWNLOADS which are mostly from the exemark website - seems I have to place the old articles as scan or PDF now.
> >
> 
> Have you tried the Wayback Machine.
> http://web.archive.org/web/*/http://www.exemark.com/asynch/articles.html 
> gives hits from 2003-2007.
> HTH

Thanks, I have to dig into that

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

#49478

On Monday, July 25, 2016 at 2:14:22 PM UTC+1, Richard Owlett wrote:
> On 7/25/2016 7:36 AM, JUERGEN wrote:
> >
> >>
> >> For people who want a bit of collected asynchronous background - Theseus was good in that and you see some older info at http://www.exemark.com/asynch/articles.html
> >> The problems are still the same: tools, the advantage is mainly less current consumption - even with the additional complexity, but synchronous is simpler.
> >
> > It seems, many of the links are dead, go for the DOWNLOADS which are mostly from the exemark website - seems I have to place the old articles as scan or PDF now.
> >
> 
> Have you tried the Wayback Machine.
> http://web.archive.org/web/*/http://www.exemark.com/asynch/articles.html 
> gives hits from 2003-2007.
> HTH

Richard, thanks again, nice to see history to come back to life - some of the stuff really wayback - but still true.

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

#49496

On 7/25/2016 12:22 AM, rickman wrote:
> On 7/25/2016 12:57 AM, Cecil Bayona wrote:
>> On 7/24/2016 11:08 PM, rickman wrote:

>> Myself tomorrow I will go to the doctor in the morning to figure out
>> what to try next, I'm not responding to very expensive medicine so I
>> might have to take desperate measures to bring my health under control.
>
> If you mentioned this before I don't recall.  Sounds like it might be
> serious.
>
>

It is, I'm diabetic and for the past 6 month or so I have not been 
responding very well to my medicine, the doctor has tried several 
different drugs with poor results, My A1C was 11.3 6 month ago. Slowly 
things have been improving so 3 months ago it went down to 8.3 on A1C 
test, this morning my result from lab work show that I have a A1C of 7.1 
this time around.

Unfortunately the medicine that seems to work (Victoza) is not covered 
by my insurance and I can't afford it so this morning she gave me some 
samples of 75%/25%  HumaLog Insulin which will cost $212 a month, it 
will be difficult and a strain on my budget but I have little choice. It 
will take a few weeks before I know how well its working as it will take 
a week for the older medicine to work out of my system.

The desperate measures has to do with eating, the latest research shows 
that if someone can tolerate it fasting will help a lot in bringing down 
your blood sugar, and helps you loose weight which also is a big help. I 
can tolerate fasting well and tried it out a few times and it worked 
quite well, after 2 days of fasting my blood sugar was way down into the 
really good range 85-100 in the morning, and 150 2 hours after a meal, 
that is totally normal for a non-diabetic. So a starting plan would be 
fast for three days, eat moderately for 2 days, then repeat the cycle 
again, after a month or two of this, you can't help it and you start 
loosing weight, if your weight gets down low enough you don't need to 
fast as much and you won't need the drugs a much.


>
>
>> No enough gains to justify the problems so I stick to nice synchronous
>> logic, one is better off with CPUs like the ep32, five packed
>> instructions to a 32 bit word, TOS an NOS on registers, single clock
>> execution of instructions, a nice machine, another nice one is the J1
>> capable of multiple instruction execution in one clock.
>
> You really can't design async logic in FPGAs that I know of.  It has to
> be custom chips.  Achronix is developing async logic FPGAs, but I think
> they are intent on the really big customers only, small users need not
> apply.

I have not looked into it but you might be right as the LUTS have flip 
flops on their outputs and would need to be clocked.
>
> I looked at what amounts to VLIW for MISC processors (sounds like an
> oxymoron, no?)  The ide was that there are three processors in any two
> stack machine.  1) the instruction processor, 2) tThe data (stack)
> processor, 3) the return (I call it the address) processor.  Each one
> could do something independent on each instruction cycle.  The
> instructions can be encoded (standard MISC instructions) or the
> instructions can be separate, one for each of the three processors
> (which is the main idea behind VLIW).  Various combinations of
> instructions give the basic primitives but many other useful
> combinations as well such as a return on any instruction that doesn't
> conflict with the hardware usage.
>
> I only looked at this for a bit.  I believe that is how the J1 gets some
> parallelism.  My stumbling block was in writing a compiler to take
> advantage of this.  But then I don't really intend to program any of my
> apps in Forth really.  I would just code it in the stack machine
> assembly, not unlike what Chuck Moore does for the F18A.  Forth is used
> to write the macro assembler.
>
The J1 uses micro-programming, the instructions are the control bits for 
the internal CPU units, so it can do multiple transfers and logic/math 
operations at the same time, just set the right bits. So you could do a 
math operation, save the result, and return in one instruction.

-- 
Cecil - k5nwa

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

#49498

On 7/25/2016 3:11 PM, Cecil Bayona wrote:
> On 7/25/2016 12:22 AM, rickman wrote:
>> On 7/25/2016 12:57 AM, Cecil Bayona wrote:
>>> On 7/24/2016 11:08 PM, rickman wrote:
>
>>> Myself tomorrow I will go to the doctor in the morning to figure out
>>> what to try next, I'm not responding to very expensive medicine so I
>>> might have to take desperate measures to bring my health under control.
>>
>> If you mentioned this before I don't recall.  Sounds like it might be
>> serious.
>>
>>
>
> It is, I'm diabetic and for the past 6 month or so I have not been
> responding very well to my medicine, the doctor has tried several
> different drugs with poor results, My A1C was 11.3 6 month ago. Slowly
> things have been improving so 3 months ago it went down to 8.3 on A1C
> test, this morning my result from lab work show that I have a A1C of 7.1
> this time around.
>
> Unfortunately the medicine that seems to work (Victoza) is not covered
> by my insurance and I can't afford it so this morning she gave me some
> samples of 75%/25%  HumaLog Insulin which will cost $212 a month, it
> will be difficult and a strain on my budget but I have little choice. It
> will take a few weeks before I know how well its working as it will take
> a week for the older medicine to work out of my system.
>
> The desperate measures has to do with eating, the latest research shows
> that if someone can tolerate it fasting will help a lot in bringing down
> your blood sugar, and helps you loose weight which also is a big help. I
> can tolerate fasting well and tried it out a few times and it worked
> quite well, after 2 days of fasting my blood sugar was way down into the
> really good range 85-100 in the morning, and 150 2 hours after a meal,
> that is totally normal for a non-diabetic. So a starting plan would be
> fast for three days, eat moderately for 2 days, then repeat the cycle
> again, after a month or two of this, you can't help it and you start
> loosing weight, if your weight gets down low enough you don't need to
> fast as much and you won't need the drugs a much.

Diabetes runs in my family, but so far I have avoided it.  Maybe because 
at *only* 35 lbs overweight I am a lighter member.  It's been awhile 
since I was tested so I should do that.  My last check was a doctor 
doing the blood sugar tests with the little strips in a supermarket.  I 
had something small to eat some hours before and still was in the 70 
range I seem to recall.  He said that was great!


>>> No enough gains to justify the problems so I stick to nice synchronous
>>> logic, one is better off with CPUs like the ep32, five packed
>>> instructions to a 32 bit word, TOS an NOS on registers, single clock
>>> execution of instructions, a nice machine, another nice one is the J1
>>> capable of multiple instruction execution in one clock.
>>
>> You really can't design async logic in FPGAs that I know of.  It has to
>> be custom chips.  Achronix is developing async logic FPGAs, but I think
>> they are intent on the really big customers only, small users need not
>> apply.
>
> I have not looked into it but you might be right as the LUTS have flip
> flops on their outputs and would need to be clocked.

Async clocked logic still has clocks, they just aren't a single clock 
running the whole chip.  Think of traffic with lights.  Cars arrive at a 
light and are stopped until it turns green.  Cars arrive at different 
times (different logic delays) but they all must wait until they are all 
there before the light can turn green.  The whole city is running all 
lights on the same cycle.  So obviously there will be some lights that 
could run faster.

So instead each block is timed independently.  Each light is adjusted 
for the length and speed of the street so it can cycle faster if the 
street is shorter.  But now all the lights are out of sync and more 
control signals are needed to allow the traffic to flow smoothly.  Much 
harder to organize to let traffic flow smoothly.

But there are still lights and traffic stops waiting for them...


>> I looked at what amounts to VLIW for MISC processors (sounds like an
>> oxymoron, no?)  The ide was that there are three processors in any two
>> stack machine.  1) the instruction processor, 2) tThe data (stack)
>> processor, 3) the return (I call it the address) processor.  Each one
>> could do something independent on each instruction cycle.  The
>> instructions can be encoded (standard MISC instructions) or the
>> instructions can be separate, one for each of the three processors
>> (which is the main idea behind VLIW).  Various combinations of
>> instructions give the basic primitives but many other useful
>> combinations as well such as a return on any instruction that doesn't
>> conflict with the hardware usage.
>>
>> I only looked at this for a bit.  I believe that is how the J1 gets some
>> parallelism.  My stumbling block was in writing a compiler to take
>> advantage of this.  But then I don't really intend to program any of my
>> apps in Forth really.  I would just code it in the stack machine
>> assembly, not unlike what Chuck Moore does for the F18A.  Forth is used
>> to write the macro assembler.
>>
> The J1 uses micro-programming, the instructions are the control bits for
> the internal CPU units, so it can do multiple transfers and logic/math
> operations at the same time, just set the right bits. So you could do a
> math operation, save the result, and return in one instruction.

The J1 does not use microprogramming.  Microprogramming is using 
instructions internal to the CPU which then control the operations of 
the CPU over multiple clock cycles.  The J1 instructions run in a single 
clock cycle.  I see no indication in the Verilog code this processor 
uses any internal instruction memory or that it uses more than one clock 
cycle per instruction.  I think you are misusing the term 
microprogramming to refer to the fact that the J1 instructions use 
separate fields to directly control CPU functions.  That is simply a 
matter of horizontal vs. vertical instruction format (less encoded vs. 
more encoded).  The GA144 would be a vertical format with no fields 
within the instruction, just 5 bit opcodes to control the entire CPU.

The J1 instruction format does have some unencoded fields for internal 
processor control.  But that is only for the ALU and data op 
instructions.  Other instructions usurp these fields for literal 
addresses or data.  The fields of the data op instructions include a bit 
for return and can manipulate the return stack to pop and push data, but 
that's all.  There is one bit that appears to be unused.

The only operations that can be done in parallel is to perform a return 
in an instruction also performing any data op.  With the independent T>R 
control bit an instruction can in parallel do R>PC, T>R and R>T.  This 
would be a single instruction co-routine switch.  I've never used 
coroutines and I expect few others have.

When I mentioned separate processors I was referring to the fact that in 
my CPU design the data stack and ALU operate in parallel with the return 
stack and it's ALU along with the instruction fetch.  I only explored 
the possibilities briefly, but a 16 bit instruction would have supported 
a fairly complete instruction set for each unit independently.  The 18 
bit memory of many FPGAs would support an even richer instruction set.

I expect such a VLIW type instruction format to maximize parallelism and 
also provide for multiple Forth level instructions to be executed in 
parallel or at least higher level Forth instructions to be a single 
instruction rather than multiple, not just executing a return in 
parallel with a data op.

-- 

Rick C

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

#49503

On 7/25/2016 4:39 PM, rickman wrote:
> On 7/25/2016 3:11 PM, Cecil Bayona wrote:
>> On 7/25/2016 12:22 AM, rickman wrote:

>
> Diabetes runs in my family, but so far I have avoided it.  Maybe because
> at *only* 35 lbs overweight I am a lighter member.  It's been awhile
> since I was tested so I should do that.  My last check was a doctor
> doing the blood sugar tests with the little strips in a supermarket.  I
> had something small to eat some hours before and still was in the 70
> range I seem to recall.  He said that was great!
>
>

Normal blood is 100 if you have gone without food for 4 hours or more, 
70 is too low to the point you need to eat something to bring it up so 
I'm not sure what kind of test they did. It used to be they would test 
for Ketones in your urine that was very inaccurate, the modern way is 
with a blood sample.

Weight is a major factor in preventing Diabetes so try to keep your 
weight down and close to your optimum weight. Once you have diabetes 
it's hard to loose the weight.


-- 
Cecil - k5nwa

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

#49505

On 7/25/2016 7:01 PM, Cecil Bayona wrote:
> On 7/25/2016 4:39 PM, rickman wrote:
>> On 7/25/2016 3:11 PM, Cecil Bayona wrote:
>>> On 7/25/2016 12:22 AM, rickman wrote:
>
>>
>> Diabetes runs in my family, but so far I have avoided it.  Maybe because
>> at *only* 35 lbs overweight I am a lighter member.  It's been awhile
>> since I was tested so I should do that.  My last check was a doctor
>> doing the blood sugar tests with the little strips in a supermarket.  I
>> had something small to eat some hours before and still was in the 70
>> range I seem to recall.  He said that was great!
>>
>>
>
> Normal blood is 100 if you have gone without food for 4 hours or more,
> 70 is too low to the point you need to eat something to bring it up so
> I'm not sure what kind of test they did. It used to be they would test
> for Ketones in your urine that was very inaccurate, the modern way is
> with a blood sample.
>
> Weight is a major factor in preventing Diabetes so try to keep your
> weight down and close to your optimum weight. Once you have diabetes
> it's hard to loose the weight.

This was perhaps 2 in the afternoon and I had only had some yogurt 
earlier in the morning.  I was fasting to get the blood test done as I 
had heard that is how they do it, but I slipped and ate some yogurt. 
The strips are the ones where you prick your finger, put the blood on 
the strip and slip it into the glucometer.

Web pages I found indicate blood sugar levels of 70 to 100 mg/dL are 
normal when fasting.  Below 60 and they start to worry.

-- 

Rick C

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

#49526

On Mon, 25 Jul 2016 14:11:16 -0500
Cecil Bayona <cbayona@cbayona.com> wrote:

> On 7/25/2016 12:22 AM, rickman wrote:

> > You really can't design async logic in FPGAs that I know
> > of.  It has to be custom chips.  Achronix is developing
> > async logic FPGAs, but I think they are intent on the really
> > big customers only, small users need not apply.
> 
> I have not looked into it but you might be right as the LUTS
> have flip flops on their outputs and would need to be clocked.

Yes, if a logic device uses LUTs, then it needs to latch the LUT
output when it is stable, and the longest logic propagation time
must fit between two clock edges. 

In the fine-grained Microsemi/Actel Flash FPGAs there are no
LUTs, the programmable element is either logic or a flop. There
are only eight synchronous library parts, and the majority of
the rest are purely combinatorial.  [1]

Perhaps these parts could be used to synthesize async logic
designs.   

Jan Coombs
-- 
[1] IGLOO, ProASIC3, SmartFusion and Fusion Macro Library Guide
http://www.microsemi.com/document-portal/doc_view/130886-igloo-proasic3-smartfusion-and-fusion-macro-library-guide-for-software-v9-0
[2] https://en.wikipedia.org/wiki/Asynchronous_circuit

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

#49530

On 7/26/2016 6:04 AM, Jan Coombs wrote:
> On Mon, 25 Jul 2016 14:11:16 -0500
> Cecil Bayona <cbayona@cbayona.com> wrote:
>
>> On 7/25/2016 12:22 AM, rickman wrote:
>
>>> You really can't design async logic in FPGAs that I know
>>> of.  It has to be custom chips.  Achronix is developing
>>> async logic FPGAs, but I think they are intent on the really
>>> big customers only, small users need not apply.
>>
>> I have not looked into it but you might be right as the LUTS
>> have flip flops on their outputs and would need to be clocked.
>
> Yes, if a logic device uses LUTs, then it needs to latch the LUT
> output when it is stable, and the longest logic propagation time
> must fit between two clock edges.
>
> In the fine-grained Microsemi/Actel Flash FPGAs there are no
> LUTs, the programmable element is either logic or a flop. There
> are only eight synchronous library parts, and the majority of
> the rest are purely combinatorial.  [1]
>
> Perhaps these parts could be used to synthesize async logic
> designs.

I think there is some misunderstanding of the basic LUT-FF cell design. 
The output of the LUT is always available outside the logic cell.  The 
FF can be used to register the output of the LUT or not.  It can also be 
used to register another signal from outside the logic cell.  So the 
presence of the FF in the logic cell has nothing to do with the ease of 
implementing async clocked logic in an FPGA.

The reason FPGAs are not suited for async clocked logic is because this 
design method requires the specification of both max and min delays on 
logic paths.  The logic specified by the user has a parallel path which 
is used to clock the output FF.  This parallel path must have a minimum 
delay that is longer than the maximum delay of the logic.  FPGAs are not 
specified in a way to show a design meets this requirement.

If you wish to take it on yourself to figure out appropriate 
specifications for the various logic and routing paths within an FPGA, 
you can do your own timing analysis.  Then you could design async 
clocked logic in that FPGA.  But this would be a very difficult task 
without knowing details on the variations of timing across a large 
number of chips from a large number of batches.  If the FPGA vendor 
makes any changes to the process (which do happen from time to time for 
yield purposes) your measurements are no longer valid or at least the 
margin provided by your tools is now suspect.

I don't think you will find much speed improvement over just clocking 
the design synchronously.  Yes, on the test bench you can see speed 
improvements.  But once you allow for the three basic variations in 
timing, process, voltage and temperature you will likely see no real 
advantage and my find the async logic to be worse than sync logic 
because of the margins required.

As someone pointed out, there will be power improvements.  I have been 
told the clock tree in a large chip can dissipate half the power.  That 
is pretty amazing, but when you think about the huge distributed 
capacitance and the many matched buffers required to keep the clock skew 
to a minimum across the chip, I shouldn't doubt this.

The bottom line is asynchronously clocked CPU chips have been designed 
before but have never made an impact on the market.  I recall one that 
was an 8051 I believe and I seem to recall an ARM being designed this 
way.  Of course, the GA144 is the most notable and possibly the most 
successful example so far.  None have made an impact on the market. 
Partly that is because one big advantage of the sync clocked device is 
that it can tell time!  The digital world works off of timing.  Nearly 
all interfaces require timing.  Nearly all applications require timing. 
Adding a processor that free runs means another way has to be found to 
sync the processes to the outside world.  Once you do that many of the 
speed advantages go away.

We are on a road that gives us faster processors every year.  The power 
for a given level of complexity in processors continues to decrease. 
Design an async clocked processor this year and next year it will be 
usurped by the next generation of sync clocked processor.  It's hard to 
hit a moving target.

I think FPGAs can be used best to design Forth processors using 
conventional logic techniques focusing on interesting CPU architectures 
rather than misusing the FPGA.

This post got pretty long... not nearly a manifesto though...

-- 

Rick C

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

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

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

csiph-web