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

Groups > comp.lang.vhdl > #4410

Re: Forth in VHDL

Cross-posted to 2 groups.

Show all headers | View raw

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

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

Thread

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 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 rickman <gnuarm@gmail.com> - 2016-07-27 18:15 -0400

csiph-web