Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #50958
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: OKAD? |
| Date | 2016-09-14 08:50 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <20160914085017.6648817c@HP-6550b> (permalink) |
| References | (7 earlier) <679aed09-f763-4072-893b-9421e121a204@googlegroups.com> <8db49be3-e9e5-4247-a4ef-425b11efa623@googlegroups.com> <87lgywg6mb.fsf@jester.gateway.pace.com> <20160913000101.46c106d8@HP-6550b> <nr9i18$dus$2@dont-email.me> |
On Tue, 13 Sep 2016 14:54:33 -0400 rickman <gnuarm@gmail.com> wrote: > On 9/12/2016 7:01 PM, Jan Coombs wrote: > > > > Since the ripple adder is racing against a clock, the fabric > > of the S40C18 cannot be purely asynchronous logic. So what > > is it? > > I'm sorry, I don't follow this reasoning at all. How do you > get this conclusion? If the adder logic is asynchronous at the gate level, then the completion information would also pass through every gate. The adder would declare it's work complete when the slowest result path is resolved. This may be accomplished by the two wires used for each bit propagation carrying both the logic level and a time stamp. The ALU result selector would have to wait much longer for an addition to complete than for simpler ALU operations, but the addition would be complete, not just guaranteed half complete as in the S40C18 specification I quoted. One way to make a logic block asynchronous at it's boundary is to use regular logic inside the block, and a delay line to declare when the enclosed function is complete. This is cheaper, because it uses perhaps a quarter of silicon required for gate level asynchronous logic. The delay line time will generally track silicon processing and temperature variations. The margin for this being set at design time, as with synchronous logic. Probably this is what was done in the S40C18. What interested me is where the asynchronous boundaries are. They could be just around each processor, or maybe the processor logic is further divided into asynchronous sections. Hence my question above, "So what is it?" Jan Coombs -- [Twoddle warning: Written from memory and/or imagination]
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