Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #50922
| 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> |
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
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