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


Groups > comp.lang.forth > #50958

Re: OKAD?

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>

Show all headers | View raw


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


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