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


Groups > comp.lang.vhdl > #4414

Re: Forth in VHDL

From rickman <gnuarm@gmail.com>
Newsgroups comp.lang.vhdl, comp.lang.forth
Subject Re: Forth in VHDL
Date 2016-07-27 10:01 -0400
Organization A noiseless patient Spider
Message-ID <nnaet0$nvs$1@dont-email.me> (permalink)
References (8 earlier) <20160726110441.73da10eb@HP-6550b> <nn7ulv$v73$1@dont-email.me> <2016Jul26.180023@mips.complang.tuwien.ac.at> <nn84qv$m6a$1@dont-email.me> <2016Jul27.113935@mips.complang.tuwien.ac.at>

Cross-posted to 2 groups.

Show all headers | View raw


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

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