Re: OKAD?

From	rickman <gnuarm@gmail.com>
Newsgroups	comp.lang.forth
Subject	Re: OKAD?
Date	2016-09-21 18:03 -0400
Organization	A noiseless patient Spider
Message-ID	<nrv032$c1l$1@dont-email.me> (permalink)
References	(10 earlier) <efb5eba2-d81f-4353-a1ff-25ae7144ba6c@googlegroups.com> <nrf3qn$8le$1@dont-email.me> <542641f7-0853-46cc-a2db-4ac5a9d5cfba@googlegroups.com> <nrkb6v$bi7$1@dont-email.me> <5e23cb9a-0766-44ae-a293-08d411dacbd8@googlegroups.com>

Show all headers | View raw

On 9/21/2016 4:42 PM, Jecel wrote:
> On Saturday, September 17, 2016 at 6:05:42 PM UTC-3, rickman wrote:
>> On 9/16/2016 1:38 PM, Jecel wrote:
>> I don't know about the F21.  On the F18A the NOPs (denoted by a period
>> in the instruction set which you used to indicated all the other
>> instructions) are not so relevant since the adder is running all the
>> time while the other instructions are running.  Any time the stack
>> changes the adder runs and consumes power.  Is the F21 different?
>
> No, that is exactly how the F21 was designed as well.
>
>>> [RTL: register on inputs AND outputs]
>> You miss the point.  The registers latch one copy of the results which
>> then feed multiple circuits in parallel.  The is the "output register"
>> view.  If you consider registering the inputs of each functional block,
>> the outputs of a block will feed multiple registers, but only the ones
>> required for the next calculation are enabled so the unused logic is
>> "quiet" and does not use power.
>
> Right.
>
>> So while in general the registers "separate" blocks of logic, how you
>> enable them and how many you use depends on your view and determines how
>> much power is used.
>
> Exactly.
>
>>> Other design styles are possible, so your observation is very
>>> relevant. And even with RTL you have multiplexors that can be placed
>>> closer to the outputs of the registers or near their inputs, and
>>> the choice will have an effect on power and speed.
>>
>> I don't get what you are saying about multiplexers.  Multiplexers are
>> part of the logic.  What does that have to do with "RTL"?
>
> I was just saying what you were saying but in a different way.
>
> Your "output register" view has a direct connection between the
> register's input and the output of one combinational block. The
> output of the register goes to many combinational blocks in
> parallel. But this means that more than one register can send
> data to the same combinational block (for any interesting
> design), which implies some multiplexor at the inputs of that
> block.
>
> REG ---- MUX ----- LOGIC --- REG
> REG ----|


If there is a mux, it is just part of the logic.  Multiple registers 
feeding the same logic is just that.  Logic has many inputs.

         +-------+
REG --->|       |
         | Logic |--->
REG --->|       |
         +-------+

> Your "input register" view has a direct connection between the
> register's output and the input of one combinational block. The
> input of a register must come from several combinational blocks
> which means there must be a multiplexor at the input of the
> register.
>
> REG ---- LOGIC ----- MUX ---- REG
> REG ---- LOGIC -----|

No mux.  One register on the input of each logic block.  No muxes 
anywhere unless they are part of the logic.

Register on logic output.

                  +--- LOGIC --- REG
                  |
LOGIC --- REG ---+
                  |
                  +--- LOGIC --- REG

Reg on inputs
                  +---- REG --- LOGIC
                  |
REG --- LOGIC ---+
                  |
                  +---- REG --- LOGIC


The difference is that the registers on the inputs do not all get 
enabled.  Only the registers feeding logic being used are enabled so any 
logic that is not needed is quiet and not using power.


> Suppose that the select lines for all the multiplexors can
> change a bit after the clock. In the "output register" view
> this means that the inputs for logic blocks take a while to
> settle down, which causes pointless transitions and wasted
> energy. In the "input register" view this means that the
> inputs for the logic blocks are stable soon after the clock.

Forget these muxes.  They don't exist.


> This all applies to RTL but, as I said, this is just one
> particular design style. Though, like structured programming,
> it is currently used so extensively that it is easy to forget
> it is not the only option.

RTL is a coding style I thought.  I'm not sure what you are saying about 
that.

Structured programming is very different and orthogonal I thought.  This 
has to do with using well defined control flow structures like IF THEN 
ELSE or BEGIN UNTIL, etc. in place of GOTO which Forth doesn't have 
unless you want to add your own.

-- 

Rick C

Thread

OKAD? Mux <Yvo.Zoer@gmail.com> - 2016-08-22 15:07 -0700
  Re: OKAD? Paul Rubin <no.email@nospam.invalid> - 2016-08-22 15:31 -0700
  Re: OKAD? Bernd Linsel <bl1@gmx.com> - 2016-08-23 01:45 +0200
    Re: OKAD? Mux <Yvo.Zoer@gmail.com> - 2016-08-23 13:55 -0700
  Re: OKAD? JUERGEN <epldfpga@aol.com> - 2016-09-09 00:18 -0700
    Re: OKAD? JUERGEN <epldfpga@aol.com> - 2016-09-09 02:47 -0700
      Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-09 11:52 -0400
        Re: OKAD? JUERGEN <epldfpga@aol.com> - 2016-09-09 10:22 -0700
        Re: OKAD? Mark Wills <markwills1970@gmail.com> - 2016-09-09 14:57 -0700
          Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-09 18:02 -0400
            Re: OKAD? Paul Rubin <no.email@nospam.invalid> - 2016-09-09 15:33 -0700
              Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-10 01:55 -0400
              Re: OKAD? mhx@iae.nl - 2016-09-09 23:36 -0700
                Re: OKAD? Jecel <jecel@merlintec.com> - 2016-09-12 13:48 -0700
                Re: OKAD? Paul Rubin <no.email@nospam.invalid> - 2016-09-12 14:17 -0700
                Re: OKAD? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-09-13 00:01 +0100
                Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-13 14:54 -0400
                Re: OKAD? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-09-14 08:50 +0100
                Re: OKAD? Paul Rubin <no.email@nospam.invalid> - 2016-09-14 01:15 -0700
                Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-14 05:08 -0400
                Re: OKAD? Paul Rubin <no.email@nospam.invalid> - 2016-09-14 02:14 -0700
                Re: OKAD? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-09-14 10:33 +0100
                Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-14 05:55 -0400
                Re: OKAD? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-09-14 11:33 +0100
                Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-14 13:18 -0400
                Re: OKAD? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-09-14 21:02 +0100
                Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-14 17:20 -0400
                Re: OKAD? Jecel <jecel@merlintec.com> - 2016-09-15 10:54 -0700
                Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-15 17:28 -0400
                Re: OKAD? Jecel <jecel@merlintec.com> - 2016-09-16 10:38 -0700
                Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-17 17:05 -0400
                Re: OKAD? Jecel <jecel@merlintec.com> - 2016-09-21 13:42 -0700
                Re: OKAD? rickman <gnuarm@gmail.com> - 2016-09-21 18:03 -0400
                Re: OKAD? Jecel <jecel@merlintec.com> - 2016-09-23 13:21 -0700
    Re: OKAD? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-09 14:01 +0200
      Re: OKAD? JUERGEN <epldfpga@aol.com> - 2016-09-09 04:57 -0700
  Re: OKAD? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-09-13 09:18 -0700
    Re: OKAD? JUERGEN <epldfpga@aol.com> - 2016-09-13 10:09 -0700
      Re: OKAD? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-09-16 17:24 -0700
        Re: OKAD? JUERGEN <epldfpga@aol.com> - 2016-09-17 02:38 -0700

csiph-web