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


Groups > comp.lang.forth > #50922

Re: OKAD?

From Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Newsgroups comp.lang.forth
Subject Re: OKAD?
Date 2016-09-13 00:01 +0100
Organization A noiseless patient Spider
Message-ID <20160913000101.46c106d8@HP-6550b> (permalink)
References (5 earlier) <nqvbi4$1pv$1@dont-email.me> <87lgz0k8jh.fsf@jester.gateway.pace.com> <679aed09-f763-4072-893b-9421e121a204@googlegroups.com> <8db49be3-e9e5-4247-a4ef-425b11efa623@googlegroups.com> <87lgywg6mb.fsf@jester.gateway.pace.com>

Show all headers | View raw


On Mon, 12 Sep 2016 14:17:48 -0700
Paul Rubin <no.email@nospam.invalid> wrote:

> Jecel <jecel@merlintec.com> writes:
> > The reason thermal simulation was added toe OKAD is that the
> > F21 chip could be run at 800MHz but a sequence of ADDs would
> > overheat two transistors in the ALU and ruin them. The
> > solution was to either run it at a lower clock or include
> > NOPs between pairs of ALU operations.
> 
> Oh my heavens.  The GA144 requires NOP after ADD but most of
> us thought that was to give a ripple carry adder time to
> settle.

No, before the add, to allow the ripple adder result to
stabilise.  See "S40C18_DataSheet.pdf", extract below:


The ALU is asynchronous logic, and continuously recalculates all
possible ALU results, updating every time T or S changes.

Since any change in T or S propagates carry nine bits in a
single cycle, one extra cycle of settling time is required
before the addition logic will be valid for an 18-bit result. In
a single cycle the low-order nine bits are guaranteed. Note that
addresses can be calculated in a single cycle.

+ and +* should not be used immediately after any opcode which
affects the value of T or S. However, if there is an intervening
opcode which does not affect T or S, the add operation will work
correctly. These opcodes are marked in the following
descriptions as ‘Helps plus.’ 

If it is not possible to arrange
the opcode sequence such that a helps-plus opcode occurs just
before a + or +* , a nop should be inserted. Whenever a
+ in Slot 3 is stretched by more than one extra opcode time
(Cases 2 and 3 from Section 3.9, Prefetch) there will be enough
time for the bits in the ALU to stabilize for a + or +* , which
is in Slot 3 to return correct results.


Since the ripple adder is racing against a clock, the fabric of
the S40C18 cannot be purely asynchronous logic.  So what is it?

Jan Coombs

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


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