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

#49535

rickman <gnuarm@gmail.com> writes:
>I have been 
>told the clock tree in a large chip can dissipate half the power.

IIRC the clock for the 21064 (1992) consumed 30% of the power, and the
final driver of the clock had a gate length of 35cm.  That was at
200MHz.

Of course that could not scale, so quite some time ago they have
divided the chips into smaller clock domains (and later also power
domains); e.g., the Williamette (first Pentium 4, 2001, 1400MHz) had a
very fast integer ALU core that, however, did not include
multiplication or shifting.  So integer multiplication and shifting
were achieved by shipping the data over to the FPU, and then shipping
the result back.  The data had to cross several clock domain borders
on the way, losing a cycle on every crossing; that's why integer
multiplication is slower than FP multiplication on the Pentium 4.

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

AFAIK the GA144 is not an asynchronous design; it's a clocked design,
but the clock is generated internally (one clock per core).  At least
an earlier chip by Chuck Moore worked that way (IIRC the MuP21), and
the idea that this was an async design was already rampant (and
contradicted) at the time.

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

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

#49540

On 7/26/2016 12:00 PM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> I have been
>> told the clock tree in a large chip can dissipate half the power.
>
> IIRC the clock for the 21064 (1992) consumed 30% of the power, and the
> final driver of the clock had a gate length of 35cm.  That was at
> 200MHz.
>
> Of course that could not scale, so quite some time ago they have
> divided the chips into smaller clock domains (and later also power
> domains); e.g., the Williamette (first Pentium 4, 2001, 1400MHz) had a
> very fast integer ALU core that, however, did not include
> multiplication or shifting.  So integer multiplication and shifting
> were achieved by shipping the data over to the FPU, and then shipping
> the result back.  The data had to cross several clock domain borders
> on the way, losing a cycle on every crossing; that's why integer
> multiplication is slower than FP multiplication on the Pentium 4.
>
>> 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.
>
> AFAIK the GA144 is not an asynchronous design; it's a clocked design,
> but the clock is generated internally (one clock per core).  At least
> an earlier chip by Chuck Moore worked that way (IIRC the MuP21), and
> the idea that this was an async design was already rampant (and
> contradicted) at the time.

None of the CPUs described as "asynchronous" are truly that.  They are 
asynchronously clocked.  In the GA144 there are delay paths that are 
activated for each type of instruction with a delay matched to the time 
taken for that class of instruction.  Someone here argued with me that 
this constituted an astable oscillator but that is just semantics.  Of 
course it will oscillate as the end of any one clock period has to 
coincide with the beginning of the next.  But just like all the other 
"async" CPUs, the GA144 is async in the same way, asynchronously clocked.

True asynchronous logic is different.  It has no clocked registers.  The 
logic is self latching like RS FFs and has to be designed very 
differently even from asynchronously clocked logic.  I remember an async 
logic state machine available many years ago when PLDs were still new. 
It was true async logic, but never made much of a dent in the market.  I 
saw it used on one design which likely became out of date due to the 
part becoming obsolete not too long after.

-- 

Rick C

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

#49555

rickman <gnuarm@gmail.com> writes:
>On 7/26/2016 12:00 PM, Anton Ertl wrote:
>In the GA144 there are delay paths that are 
>activated for each type of instruction with a delay matched to the time 
>taken for that class of instruction.

So you no longer have to do three nops before (or was it after?) a
full-length "+"?  That's new then.  The way I understood the
description of the MuP21 in the earlier discussion, it had some kind
of on-chip oscillator that clocked the whole core, and the addition
could take up to four cycles.

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

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

#49561

On 7/27/2016 5:39 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> On 7/26/2016 12:00 PM, Anton Ertl wrote:
>> In the GA144 there are delay paths that are
>> activated for each type of instruction with a delay matched to the time
>> taken for that class of instruction.
>
> So you no longer have to do three nops before (or was it after?) a
> full-length "+"?  That's new then.  The way I understood the
> description of the MuP21 in the earlier discussion, it had some kind
> of on-chip oscillator that clocked the whole core, and the addition
> could take up to four cycles.

All of the ALU instructions are timed with the same timing path.  The 
add requires extra time for the carry to settle, so one nop is required 
before an addition unless the previous instruction does not modify 
either of the two operands in which case no nop is needed.  Other, 
non-alu instructions have various timings and have other timing paths. 
It is definitely *not* one timing path for the "whole core".

I don't recall the various classes of instructions that have separate 
timing from the ALU, but at one point I made a timing based tool in a 
spread sheet.  Type in the instructions and it gave you the timing.  I 
think it even accounted for instruction word boundaries which require 
additional timing for the next word fetch under some conditions.

-- 

Rick C

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

#49593

On Tue, 26 Jul 2016 16:00:23 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> AFAIK the GA144 is not an asynchronous design; it's a clocked
> design, but the clock is generated internally (one clock per
> core).  At least an earlier chip by Chuck Moore worked that
> way (IIRC the MuP21), and the idea that this was an async
> design was already rampant (and contradicted) at the time.

Yes, both Green Arrays and IntellaSys chips [1][2] need 'nop' or
another instruction that does not alter T or S to precede an
addition. This is in order to allow the carry to stabilise. The
earlier manual states that the carry propagates nine bits in
each processor cycle. 

The GA144 is asynchronous at the boundary of each processor
module.  AFAICTell this is a common 'asynchronous' design method.
Otherwise the wikkipedia article [3] "Asynchronous CPU" needs
revision.  There are perhaps zero recent CPU designs built of
purely asynchronous logic?  (And, for good patent readers, what
are Achronix async FPGA parts made of)

The most efficient asynchronous signalling method for random
logic seems to be "four state encoding". This uses two wires to
carry a single bit and a 'time stamp'. The 'time stamp' is the
data cycle to which the data bit belongs, mod 2. 

The encoding is arranged so that in the transition to each new
time phase only one of the two wires changes state, regardless
of whether or not the data has changed.  This avoids race
problems between the two wires. 

I'd like to know what the cost for this is in transistors,
having guessed it is about 10 _times_ more than simple
conventional logic.

Jan Coombs
-- 
[1] DB001-110412-F18A.pdf "F18A Technology Reference" pg8
[2] "SEAforth 40C18 Data Sheet (Preliminary)" pg44
[3] https://en.wikipedia.org/wiki/Asynchronous_circuit

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

#49538

On Tuesday, July 26, 2016 at 11:04:42 AM UTC+1, 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.   
> 
> 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

Jan, you can implement asynch logic in any FPGA. And should compare apples and apples: either implemented in the same FPGA. Just read the NCL articles see http://link.springer.com/article/10.1007/s10836-008-5083-1 and http://www.theseusresearch.com/NCLPaper01.htm. It just depends if the extra effort is required or synchronous is good enough.

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

#49601

On Tue, 26 Jul 2016 09:43:31 -0700 (PDT)
JUERGEN <epldfpga@aol.com> wrote:

> Jan, you can implement asynch logic in any FPGA. 

Yes, of course, with a clock faster than the maximum data
propagation rate.  From this could I get anything better than a
slow and power-hungry simulation?


>       Just read the NCL articles see
> http://link.springer.com/article/10.1007/s10836-008-5083-1 and
 - pay barrier GBP 29.95

> http://www.theseusresearch.com/NCLPaper01.htm.
 - link to pdf broken, perhaps there is a copy somewhere else? 


>                                                It just depends
> if the extra effort is required or synchronous is good enough.

Achronix claimed a 10x reduction of the power/speed factor for
their asynchronous FPGAs, although these are now 'on the back
burner'. [1]

Jan Coombs
-- 
[1] http://eejournal.com/archives/articles/20150218-achronix/

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

#49603

On 7/28/2016 4:12 AM, Jan Coombs wrote:
> On Tue, 26 Jul 2016 09:43:31 -0700 (PDT)
> JUERGEN <epldfpga@aol.com> wrote:
>
>> Jan, you can implement asynch logic in any FPGA.
>
> Yes, of course, with a clock faster than the maximum data
> propagation rate.  From this could I get anything better than a
> slow and power-hungry simulation?
>
>
>>       Just read the NCL articles see
>> http://link.springer.com/article/10.1007/s10836-008-5083-1 and
>  - pay barrier GBP 29.95
>
>> http://www.theseusresearch.com/NCLPaper01.htm.
>  - link to pdf broken, perhaps there is a copy somewhere else?
>
>
>>                                                It just depends
>> if the extra effort is required or synchronous is good enough.
>
> Achronix claimed a 10x reduction of the power/speed factor for
> their asynchronous FPGAs, although these are now 'on the back
> burner'. [1]

Interesting that they not only dropped the async logic, they added a lot 
of hard IP targeted to their main market, "wireline".  I have always 
thought the direction of FPGAs would be to include more hard IP in 
addition to the "fabric".  The problem with that is the product line 
complexity it creates with the variations needed.  That's why Achronix 
is only targeting one market, to focus their architecture to that market.

-- 

Rick C

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

#49614

On Thursday, July 28, 2016 at 9:12:14 AM UTC+1, Jan Coombs wrote:
> On Tue, 26 Jul 2016 09:43:31 -0700 (PDT)
> JUERGEN <epldfpga@aol.com> wrote:
> 
> > Jan, you can implement asynch logic in any FPGA. 
> 
> Yes, of course, with a clock faster than the maximum data
> propagation rate.  From this could I get anything better than a
> slow and power-hungry simulation?
> 
> 
> >       Just read the NCL articles see
> > http://link.springer.com/article/10.1007/s10836-008-5083-1 and
>  - pay barrier GBP 29.95
> 
> > http://www.theseusresearch.com/NCLPaper01.htm.
>  - link to pdf broken, perhaps there is a copy somewhere else? 
> 
> 
> >                                                It just depends
> > if the extra effort is required or synchronous is good enough.
> 
> Achronix claimed a 10x reduction of the power/speed factor for
> their asynchronous FPGAs, although these are now 'on the back
> burner'. [1]
> 
> Jan Coombs
> -- 
> [1] http://eejournal.com/archives/articles/20150218-achronix/

Jan I own 
the first one 
and a second one Designing Asynchronous Circuits using NCL by Scott C Smith  http://www.morganclaypool.com/doi/pdf/10.2200/S00202ED1V01Y200907DCS023, quite good. You can have them on loan?
There should be a factor of about 2 for logic in transistors and I know Theseus implemented NCL in Xilinx FPGA. Archronix is probably fine but very targeted and I would be careful with longterm supply - very special application area  - telecom. www.Wavesemi.com started with NCL but changed direction. The pain factor is not high enough yet - exept for specials like the Infineon special micros , not the standard ones , where the Asynch hides the activities - here well worth paying for. I will see if I can dig up some old articles.
Another link: http://www.win.tue.nl/async-bib/ do not know how good they are. 
Fulcrum Micro was good enough - Intel bought them. Network niche. I sent you the article directly.

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

#49621

On 7/28/2016 10:56 AM, JUERGEN wrote:
> Archronix is probably fine but very targeted and I
> would be careful with longterm supply - very special application area
> - telecom. www.Wavesemi.com started with NCL but changed direction.

Just to make a point, *all* FPGA makers are targeted to the telecom 
market as that is where the real money is.  Whey they come out with a 
new part that costs >$1000, they aren't thinking they will sell them in 
TVs.  Nearly all new product design is focused on the telecom market 
with alternate markets a second consideration.

Once in a while someone comes out with a product targeted to handheld 
apps or low cost (same thing really), but no FPGA company has made much 
money there yet.

-- 

Rick C

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

#49726

On Thu, 28 Jul 2016 07:56:41 -0700 (PDT)
JUERGEN <epldfpga@aol.com> wrote:
[re Null Convention asynchronous Logic]
>                                      There should be a
> factor of about 2 for logic in transistors and I know Theseus
> implemented NCL in Xilinx FPGA. 

Thanks for the document refs. I found the drawing showing logic
blocks which then clocked latches once ripple/noise settled. It
looks cumbersome, and is hardly close to transistor logic.  An
FPGA with LUTs should be able to do much better. 

I can see that NCL logic is only twice the number of transistors
for simple gates. For a two input you can drive the true output
from a nand of the true inputs, and the false output from a nor
of the two false inputs (feedback path ignored).  

But, NCL logic needs two edges for every bit transfer, the
assertion then negation of one of either the true or false wire. 

Four state logic only requires one line transition for each data
bit transferred, but needs more transistors. In transmission it
is therefore potentially twice as fast at half the energy cost
per bit transferred. 

To what extent this gain is lost in the needed extra transistors
and propagation delays in logic I would like to know.  Four
state is likely better for long on-chip wires, but NCL perhaps
for tight logic areas. 

Any further references, especially explaining and comparing
types of asynchronous logic would be useful. 

Jan Coombs

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

#49616

On Thursday, July 28, 2016 at 9:12:14 AM UTC+1, Jan Coombs wrote:
> On Tue, 26 Jul 2016 09:43:31 -0700 (PDT)
> JUERGEN <epldfpga@aol.com> wrote:
> 
> > Jan, you can implement asynch logic in any FPGA. 
> 
> Yes, of course, with a clock faster than the maximum data
> propagation rate.  From this could I get anything better than a
> slow and power-hungry simulation?
> 
> 
> >       Just read the NCL articles see
> > http://link.springer.com/article/10.1007/s10836-008-5083-1 and
>  - pay barrier GBP 29.95
> 
> > http://www.theseusresearch.com/NCLPaper01.htm.
>  - link to pdf broken, perhaps there is a copy somewhere else? 
> 
> 
> >                                                It just depends
> > if the extra effort is required or synchronous is good enough.
> 
> Achronix claimed a 10x reduction of the power/speed factor for
> their asynchronous FPGAs, although these are now 'on the back
> burner'. [1]
> 
> Jan Coombs
> -- 
> [1] http://eejournal.com/archives/articles/20150218-achronix/

Just remembered ASYNCH DLX as FPGA and ASIC implementation see http://www.ics.forth.gr/carv/asynchronous-circuits-revised.html
Another Forth though ...
FAQ http://www.ics.forth.gr/carv/async/faq.html
 4. Licensing and cost
4.1 Can I download and use DLX free of charge?
Yes, you can download our implementation of DLX from our web site or our FTP site. Your are welcome to implement DLX on your FPGA, but for the ASIC version, you need to send it to a fabrication facility, which is not free of charge.
4.2 Is DLX commercially available? 
and go to OpenCores.

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

#49591

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.

I took a look at a C Forth implementation, pForth.  I'm not sure I 
follow everything he is doing, I guess my C is a bit rusty.  I see he 
used a large CASE statement for primitive words.  I'm not clear on how 
the inner interpreter works through the XTs in a word definition for 
words compiled into other words.  I suppose it is just a matter of 
indexes into the dictionary (or pointers in C) but I don't see the code 
he is using to manipulate them.  He uses a ton of defines which hide the 
details and it is a bit of work for me to try to figure this out.

I'll get it sooner or later.  I just need to keep reading.

-- 

Rick C

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

#49628

On Wednesday, July 27, 2016 at 7:16:48 PM UTC-7, rickman wrote:
> I see he 
> used a large CASE statement for primitive words.  I'm not clear on how 
> the inner interpreter works through the XTs in a word definition for 
> words compiled into other words.  I suppose it is just a matter of 
> indexes into the dictionary (or pointers in C) but I don't see the code 
> he is using to manipulate them. 

It may be a token threaded Forth. You have at most 256 cases in the "switch" statement. For high level Forth, you have CALL and RET tokens. 

You can take a look at Fminus, a token threaded Forth I put on Sourceforge in 2007. It uses a VM generator to build the big switch statement and generate a bytecoded ROM. I'll probably rewrite it one of these days since now even I can't figure out some of the structures it uses.

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

#49709

On 7/28/2016 6:19 PM, Brad Eckert wrote:
> On Wednesday, July 27, 2016 at 7:16:48 PM UTC-7, rickman wrote:
>> I see he
>> used a large CASE statement for primitive words.  I'm not clear on how
>> the inner interpreter works through the XTs in a word definition for
>> words compiled into other words.  I suppose it is just a matter of
>> indexes into the dictionary (or pointers in C) but I don't see the code
>> he is using to manipulate them.
>
> It may be a token threaded Forth. You have at most 256 cases in the "switch" statement. For high level Forth, you have CALL and RET tokens.
>
> You can take a look at Fminus, a token threaded Forth I put on Sourceforge in 2007. It uses a VM generator to build the big switch statement and generate a bytecoded ROM. I'll probably rewrite it one of these days since now even I can't figure out some of the structures it uses.

For a token threaded Forth the primitives use fixed values, the tokens 
or in other words, machine commands of the virtual machine.  But Forth 
defined words are in the dictionary and there would need to be something 
to distinguish them, no?

-- 

Rick C

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

#49711

rickman <gnuarm@gmail.com> writes:
> For a token threaded Forth the primitives use fixed values, the tokens
> or in other words, machine commands of the virtual machine.  But Forth
> defined words are in the dictionary and there would need to be
> something to distinguish them, no?

Think of the GA144 instruction set: there's a bunch of primitive
instructions like arithmetic, and there's also CALL and JUMP
instructions that read an address from the instruction stream and adjust
the RSP and PC appropriately.

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

#49424

On Sunday, July 24, 2016 at 7:29:28 PM UTC-7, 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.
> 
> -- 
> 
> Rick C

According to pages 24 & 25 of http://people.sabanciuniv.edu/erkays/el310/io_10.pdf it appears possible to enter a line of input from the console. It would be interesting to run Forth as one process during simulation. But what would you do with it?

Something else I tried once and got to work was to use a pair of files as transmit and receive mailboxes for communication between a running simulation and an external application. That could simulate a serial link, which could connect a debugger running in a Forth system in synthesizable VHDL to a terminal app that talks through the mailboxes.

In a real system, that would be replaced with a UART or maybe some registers in the JTAG chain.

For a synthesizable Forth system, you need to define the instruction set, implement the compiler and write and debug the kernel words and rest of the system. It's a bit of work. The J1 (http://excamera.com/sphinx/fpga-j1.html) is a small CPU written in Verilog. I'd study that as a start.

I've considered a byte slice processor with 8-bit data paths. Operations would be strung together to support 24-bit and 32-bit VMs. Also, you don't want interrupts because they greatly complexify verification, and you don't need them.

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

#49426

On Sunday, July 24, 2016 at 8:08:36 PM UTC-7, Brad Eckert wrote:
> The J1 (http://excamera.com/sphinx/fpga-j1.html) is a small CPU written
> in Verilog. I'd study that as a start.
> 
You'll notice that its ISA's jumps only span 8K words. Roomy enough for a nice app, but you can easily jump to anywhere in the 64Kx16 address space by defining a word such as LJMP #k16, which would expect the 16-bit data k16 immediately following the call. Sure it's slower than a direct jump, but the CPU will spend most of its time below the 8K mark.

So, you really have a 128K byte address space. You could get creative with a cheap SPI flash, perhaps use some of it for high level code, some of it for BLOCK data storage. The only tricky think I see is inserting wait states to make the J1 wait for the memory interface.

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

#49430

On 7/24/2016 10:33 PM, Brad Eckert wrote:
> On Sunday, July 24, 2016 at 8:08:36 PM UTC-7, Brad Eckert wrote:
>> The J1 (http://excamera.com/sphinx/fpga-j1.html) is a small CPU written
>> in Verilog. I'd study that as a start.
>>
> You'll notice that its ISA's jumps only span 8K words. Roomy enough for a nice app, but you can easily jump to anywhere in the 64Kx16 address space by defining a word such as LJMP #k16, which would expect the 16-bit data k16 immediately following the call. Sure it's slower than a direct jump, but the CPU will spend most of its time below the 8K mark.
>
> So, you really have a 128K byte address space. You could get creative with a cheap SPI flash, perhaps use some of it for high level code, some of it for BLOCK data storage. The only tricky think I see is inserting wait states to make the J1 wait for the memory interface.
>
You can also push a number into the stack move it to the return stack 
then return, that will jump anywhere in the address space. Kind of long 
but you would only use it on rare occasions. The J1 can also execute 
multiple operations on one instruction so it might be possible with one 
opcode.

-- 
Cecil - k5nwa

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

#49432

On 7/24/2016 11:58 PM, Cecil Bayona wrote:
> On 7/24/2016 10:33 PM, Brad Eckert wrote:
>> On Sunday, July 24, 2016 at 8:08:36 PM UTC-7, Brad Eckert wrote:
>>> The J1 (http://excamera.com/sphinx/fpga-j1.html) is a small CPU written
>>> in Verilog. I'd study that as a start.
>>>
>> You'll notice that its ISA's jumps only span 8K words. Roomy enough
>> for a nice app, but you can easily jump to anywhere in the 64Kx16
>> address space by defining a word such as LJMP #k16, which would expect
>> the 16-bit data k16 immediately following the call. Sure it's slower
>> than a direct jump, but the CPU will spend most of its time below the
>> 8K mark.
>>
>> So, you really have a 128K byte address space. You could get creative
>> with a cheap SPI flash, perhaps use some of it for high level code,
>> some of it for BLOCK data storage. The only tricky think I see is
>> inserting wait states to make the J1 wait for the memory interface.
>>
> You can also push a number into the stack move it to the return stack
> then return, that will jump anywhere in the address space. Kind of long
> but you would only use it on rare occasions. The J1 can also execute
> multiple operations on one instruction so it might be possible with one
> opcode.

I designed a stack CPU many years ago and literals were pushed onto the 
return stack just because they were mostly used as addresses so the 
hardware for a "jump" a "call" and a "return" were the same if not used 
exactly the same.  When you wanted literal data the value would be moved 
from the return stack to the data stack.  This also made memory accesses 
easier since the address used one stack and the data the other.  It also 
allowed context switch very rapidly saving the address on the return 
stack and the processor status word on the data stack at the same time. 
One clock cycle interrupt response time *always*.  Not sure why Brad 
says interrupts aren't needed.  I guess he figures you can do anything 
you want with polling or maybe he would use a wait instruction like the 
Transputer and the F18A.

-- 

Rick C

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web