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

Groups > comp.lang.forth > #50962

Re: OKAD?

Show all headers | View raw

On 9/14/2016 3:50 AM, Jan Coombs wrote:
> 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?"

I have never seen any information indicating the techniques used to 
design the async logic in the GA144.  The timing would indicate there is 
a delay line associated with each of the major functional blocks such as 
ALU, memory, I/O, etc. because there are a number of separate timing 
values which apply to various functional groups.

Some people insist in referring to the delay line technique as a "ring 
oscillator".

-- 

Rick C

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