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

Groups > comp.lang.forth > #50409 > unrolled thread

OKAD?

Back to article view | Back to comp.lang.forth

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#50963

rickman <gnuarm@gmail.com> writes:
> Some people insist in referring to the delay line technique as a "ring
> oscillator".

A ring oscillator is an odd number of inverters arranged in a circle, I
thought.  So when you put in a pulse, it loops repeatedly around the
circle at a speed determined by the gate delays.  Of course you can put
taps in appropriate places to get delays.

https://en.wikipedia.org/wiki/Ring_oscillator

[toc] | [prev] | [next] | [standalone]

#50964

On Wed, 14 Sep 2016 05:08:52 -0400
rickman <gnuarm@gmail.com> wrote:

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

Maybe Chucks ring oscillator has both taps and gating, and is
the only delay element in each processor core?

Jan Coombs

[toc] | [prev] | [next] | [standalone]

#50965

On 9/14/2016 5:33 AM, Jan Coombs wrote:
> On Wed, 14 Sep 2016 05:08:52 -0400
> rickman <gnuarm@gmail.com> wrote:
>
>> Some people insist in referring to the delay line technique as
>> a "ring oscillator".
>
> Maybe Chucks ring oscillator has both taps and gating, and is
> the only delay element in each processor core?

Except that it doesn't oscillate.  When the CPU is waiting it stops.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#50966

On Wed, 14 Sep 2016 05:55:20 -0400
rickman <gnuarm@gmail.com> wrote:

> On 9/14/2016 5:33 AM, Jan Coombs wrote:
> > On Wed, 14 Sep 2016 05:08:52 -0400
> > rickman <gnuarm@gmail.com> wrote:
> >
> >> Some people insist in referring to the delay line technique
> >> as a "ring oscillator".
> >
> > Maybe Chucks ring oscillator has both taps and gating, and is
> > the only delay element in each processor core?
> 
> Except that it doesn't oscillate.  When the CPU is waiting it
> stops.

If you have gates in the ring oscillator loop you can pause or
stop the clock at any phase.  

Chuck must have at least one gate to be able to pause it. 

Jan Coombs
-- 

   Run/Stop            _      
  >-------------------| \      
      |\      |\      |  )O--.
   .--| )O----| )O----|_/    |
   |  |/      |/             |
   '-------------------------'

[toc] | [prev] | [next] | [standalone]

#50976

On 9/14/2016 6:33 AM, Jan Coombs wrote:
> On Wed, 14 Sep 2016 05:55:20 -0400
> rickman <gnuarm@gmail.com> wrote:
>
>> On 9/14/2016 5:33 AM, Jan Coombs wrote:
>>> On Wed, 14 Sep 2016 05:08:52 -0400
>>> rickman <gnuarm@gmail.com> wrote:
>>>
>>>> Some people insist in referring to the delay line technique
>>>> as a "ring oscillator".
>>>
>>> Maybe Chucks ring oscillator has both taps and gating, and is
>>> the only delay element in each processor core?
>>
>> Except that it doesn't oscillate.  When the CPU is waiting it
>> stops.
>
> If you have gates in the ring oscillator loop you can pause or
> stop the clock at any phase.
>
> Chuck must have at least one gate to be able to pause it.

I don't get why you feel it has to be a "ring oscillator".  There are 
many different timings each one adjusted to match the circuit it is 
timing.

         +---------------------------------------------+
         |                                             |
         | +-----------------------------------------+ |
         | |                                         | |
         | | +-------------------------------------+ | |
         | | |                                     | | |
         | | |  +----------+                       | | |
         | | +--| Timing 1 |----+                  | | |
         | |    +----------+    |     +---------+  | | |
         | |                    +---->|         |  | | |
         | |    +----------+          |         |--+ | |
         | +----| Timing 2 |--------->|         |    | |
         |      +----------+          |         |----+ |
         |                      +---->| Control |      |
         |      +----------+    |     |         |------+
         +------| Timing 3 |----+     |         |
                +----------+          |         |-------->
                    ...               |         |          To
         ---------------------------->|         |-------->
   From decode,                       |         |        Circuits
         ---------------------------->|         |-------->
   I/O, etc.                          |         |
         ---------------------------->|         |-------->
                                      +---------+

Sure, when the I/O doesn't tell the control circuit to halt operation, 
the timing circuit in use triggers the control circuit which in turn 
triggers another timing circuit according to the instruction decode and 
I/O signals.  I just think it is a bit simplistic to call this a ring 
oscillator.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#50978

On Wed, 14 Sep 2016 13:18:48 -0400
rickman <gnuarm@gmail.com> wrote:

> On 9/14/2016 6:33 AM, Jan Coombs wrote:
> > On Wed, 14 Sep 2016 05:55:20 -0400
> > rickman <gnuarm@gmail.com> wrote:
> >
> >> On 9/14/2016 5:33 AM, Jan Coombs wrote:
> >>> On Wed, 14 Sep 2016 05:08:52 -0400
> >>> rickman <gnuarm@gmail.com> wrote:
> >>>
> >>>> Some people insist in referring to the delay line
> >>>> technique as a "ring oscillator".
> >>>
> >>> Maybe Chucks ring oscillator has both taps and gating, and
> >>> is the only delay element in each processor core?
> >>
> >> Except that it doesn't oscillate.  When the CPU is waiting
> >> it stops.
> >
> > If you have gates in the ring oscillator loop you can pause
> > or stop the clock at any phase.
> >
> > Chuck must have at least one gate to be able to pause it.
> 
> I don't get why you feel it has to be a "ring oscillator".
> There are many different timings each one adjusted to match
> the circuit it is timing. 

I like your ASCIIart, but cannot quickly see how it affects the
operation cycle of a S40C18 or similar processor. 

Perhaps we should build a model in HDL with realistic gate
delays and see if we can guess any closer, or even reproduce
the instruction timing as in the data sheet. 

I think that it might be possible to model asynchronous logic on
ProASIC3 and similar parts, so the library components for these
might be a practical starting point if we hoped to reproduce
anything close to Chuck's work. 

Jan Coombs

[toc] | [prev] | [next] | [standalone]

#50979

On 9/14/2016 4:02 PM, Jan Coombs wrote:
> On Wed, 14 Sep 2016 13:18:48 -0400
> rickman <gnuarm@gmail.com> wrote:
>
>> On 9/14/2016 6:33 AM, Jan Coombs wrote:
>>> On Wed, 14 Sep 2016 05:55:20 -0400
>>> rickman <gnuarm@gmail.com> wrote:
>>>
>>>> On 9/14/2016 5:33 AM, Jan Coombs wrote:
>>>>> On Wed, 14 Sep 2016 05:08:52 -0400
>>>>> rickman <gnuarm@gmail.com> wrote:
>>>>>
>>>>>> Some people insist in referring to the delay line
>>>>>> technique as a "ring oscillator".
>>>>>
>>>>> Maybe Chucks ring oscillator has both taps and gating, and
>>>>> is the only delay element in each processor core?
>>>>
>>>> Except that it doesn't oscillate.  When the CPU is waiting
>>>> it stops.
>>>
>>> If you have gates in the ring oscillator loop you can pause
>>> or stop the clock at any phase.
>>>
>>> Chuck must have at least one gate to be able to pause it.
>>
>> I don't get why you feel it has to be a "ring oscillator".
>> There are many different timings each one adjusted to match
>> the circuit it is timing.
>
> I like your ASCIIart, but cannot quickly see how it affects the
> operation cycle of a S40C18 or similar processor.
>
> Perhaps we should build a model in HDL with realistic gate
> delays and see if we can guess any closer, or even reproduce
> the instruction timing as in the data sheet.
>
> I think that it might be possible to model asynchronous logic on
> ProASIC3 and similar parts, so the library components for these
> might be a practical starting point if we hoped to reproduce
> anything close to Chuck's work.

If that diagram does not mean anything to you, we are mis-communicating 
at a fundamental level and coding would not help.

I have not read about the processor in the S40C18 in any detail, but it 
appears similar to the processor in the GA144.  I believe the diagram 
you snipped is a useful block diagram of the functionality.  I know that 
processor has different instruction timing for different categories of 
instructions.  That is why I show different timing circuits.  The 
control circuit selects a delay circuit based on the opcode being 
executed.  Some instructions are simple, requiring a minimum delay.  But 
with multiple instructions per instruction word, there is a timer for 
the next instruction word prefetch.  If a branch occurs in the 
instruction word a different timer must be selected.  If a memory 
instruction is executed a different timer is selected.  If an I/O 
instruction is executed a different timer is selected and control may 
also depend on a signal back from the I/O unit.  The processor is 
typically stopped until the I/O operation is complete which requires a 
response from the neighbor.

I get the impression you are thinking of other types of asynchronous 
logic where the timing information is contained within the data path 
itself.  I am pretty sure that is not how the GA144 operates, but I 
can't say for certain of course.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#51007

On Monday, September 12, 2016 at 6:17:50 PM UTC-3, Paul Rubin wrote:
> Jecel 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.

Sorry to have given the wrong impression: by adding thermal simulation
to OKAD the problem with the F21 was not repeated in the designs that
followed. But as others have explained in this thread, a second reason
for adding NOPs between additions is to allow the carry chain enough
time to do its job. And this second reason is still valid for the
GA144.

On a F21 running at a reasonable clock rate or a GA144 at full speed
you don't need a NOP between two logical operations, for example.
Only after an addition. But on a F21 running at 800 Mhz you would
need a NOP to allow the transistors I mentioned to cool down.

-- Jecel

[toc] | [prev] | [next] | [standalone]

#51012

On 9/15/2016 1:54 PM, Jecel wrote:
> On Monday, September 12, 2016 at 6:17:50 PM UTC-3, Paul Rubin wrote:
>> Jecel 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.
>
> Sorry to have given the wrong impression: by adding thermal simulation
> to OKAD the problem with the F21 was not repeated in the designs that
> followed. But as others have explained in this thread, a second reason
> for adding NOPs between additions is to allow the carry chain enough
> time to do its job. And this second reason is still valid for the
> GA144.
>
> On a F21 running at a reasonable clock rate or a GA144 at full speed
> you don't need a NOP between two logical operations, for example.
> Only after an addition. But on a F21 running at 800 Mhz you would
> need a NOP to allow the transistors I mentioned to cool down.

Adding the nop between ADD operations does not help with the power issue 
unless the instructions are mostly ADDs.  The top and second stack items 
are directly wired to the adder as well as the logical unit so that the 
ADD unit is constantly adding whether you use ADD instructions or not. 
Using the ADD instruction helps lower the power because the stack data 
has to be quiet for an extra cycle.

When designing FPGAs I realized you can get lower power by putting your 
enabled registers on the *input* of a functional block rather than the 
output.  With the registers on the output all the logic following the 
register is stimulated every time the register changes (which can 
include multiple registers enabled differently) the following logic 
dissipates power even if the output is not going to be used.  With the 
register (which implies more registers when the signals fan out) on the 
input only the logic required uses power.  I've never seen this 
mentioned anywhere so there may be some limitation that makes it less 
useful than it sounds.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#51042

On Thursday, September 15, 2016 at 6:29:02 PM UTC-3, rickman wrote:
> Adding the nop between ADD operations does not help with the power issue 
> unless the instructions are mostly ADDs.  The top and second stack items 
> are directly wired to the adder as well as the logical unit so that the 
> ADD unit is constantly adding whether you use ADD instructions or not. 

Exactly.

> Using the ADD instruction helps lower the power because the stack data 
> has to be quiet for an extra cycle.

I suppose you meant NOP, here. And indeed, if you let the N and T
register keep their values for a while then no transistors in the ALU
will switch and so no power will be dissipated (the leak current for
old processes such as used for the F21 was very small).

Note that I don't know anything other that what I heard Chuck tell
in his Fireside Chat videos, but my guess is that something like:

.... + + .....

would get the wrong result depending in the data on the stack, so:

..... + NOP + ....

is needed to let the carry chain settle. But at 800 MHz this could
damage the F21 so this was done instead:

..... + NOP NOP + ....

> When designing FPGAs I realized you can get lower power by putting your 
> enabled registers on the *input* of a functional block rather than the 
> output.  With the registers on the output all the logic following the 
> register is stimulated every time the register changes (which can 
> include multiple registers enabled differently) the following logic 
> dissipates power even if the output is not going to be used.  With the 
> register (which implies more registers when the signals fan out) on the 
> input only the logic required uses power.  I've never seen this 
> mentioned anywhere so there may be some limitation that makes it less 
> useful than it sounds.

When you use the Register Transfer Level design style, you have
registers both in the inputs and the outputs of combinational
logic blocks and they happen to be the same registers. See the
picture of how the J1 works, for example.

Other design styles are possible, so your observation is very
relevant. And even with RTL you have multiplexors that can be placed
closer to the outputs of the registers or near their inputs, and
the choice will have an effect on power and speed.

-- Jecel

[toc] | [prev] | [next] | [standalone]

#51083

On 9/16/2016 1:38 PM, Jecel wrote:
> On Thursday, September 15, 2016 at 6:29:02 PM UTC-3, rickman wrote:
>> Adding the nop between ADD operations does not help with the power issue
>> unless the instructions are mostly ADDs.  The top and second stack items
>> are directly wired to the adder as well as the logical unit so that the
>> ADD unit is constantly adding whether you use ADD instructions or not.
>
> Exactly.
>
>> Using the ADD instruction helps lower the power because the stack data
>> has to be quiet for an extra cycle.
>
> I suppose you meant NOP, here. And indeed, if you let the N and T
> register keep their values for a while then no transistors in the ALU
> will switch and so no power will be dissipated (the leak current for
> old processes such as used for the F21 was very small).

Yes, brain cramp.  I meant using the NOP instruction.


> Note that I don't know anything other that what I heard Chuck tell
> in his Fireside Chat videos, but my guess is that something like:
>
> .... + + .....
>
> would get the wrong result depending in the data on the stack, so:
>
> ..... + NOP + ....
>
> is needed to let the carry chain settle. But at 800 MHz this could
> damage the F21 so this was done instead:
>
> ..... + NOP NOP + ....

I don't know about the F21.  On the F18A the NOPs (denoted by a period 
in the instruction set which you used to indicated all the other 
instructions) are not so relevant since the adder is running all the 
time while the other instructions are running.  Any time the stack 
changes the adder runs and consumes power.  Is the F21 different?


>> When designing FPGAs I realized you can get lower power by putting your
>> enabled registers on the *input* of a functional block rather than the
>> output.  With the registers on the output all the logic following the
>> register is stimulated every time the register changes (which can
>> include multiple registers enabled differently) the following logic
>> dissipates power even if the output is not going to be used.  With the
>> register (which implies more registers when the signals fan out) on the
>> input only the logic required uses power.  I've never seen this
>> mentioned anywhere so there may be some limitation that makes it less
>> useful than it sounds.
>
> When you use the Register Transfer Level design style, you have
> registers both in the inputs and the outputs of combinational
> logic blocks and they happen to be the same registers. See the
> picture of how the J1 works, for example.

You miss the point.  The registers latch one copy of the results which 
then feed multiple circuits in parallel.  The is the "output register" 
view.  If you consider registering the inputs of each functional block, 
the outputs of a block will feed multiple registers, but only the ones 
required for the next calculation are enabled so the unused logic is 
"quiet" and does not use power.

So while in general the registers "separate" blocks of logic, how you 
enable them and how many you use depends on your view and determines how 
much power is used.


> Other design styles are possible, so your observation is very
> relevant. And even with RTL you have multiplexors that can be placed
> closer to the outputs of the registers or near their inputs, and
> the choice will have an effect on power and speed.

I don't get what you are saying about multiplexers.  Multiplexers are 
part of the logic.  What does that have to do with "RTL"?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#51159

On Saturday, September 17, 2016 at 6:05:42 PM UTC-3, rickman wrote:
> On 9/16/2016 1:38 PM, Jecel wrote:
> I don't know about the F21.  On the F18A the NOPs (denoted by a period 
> in the instruction set which you used to indicated all the other 
> instructions) are not so relevant since the adder is running all the 
> time while the other instructions are running.  Any time the stack 
> changes the adder runs and consumes power.  Is the F21 different?

No, that is exactly how the F21 was designed as well.

> > [RTL: register on inputs AND outputs]
> You miss the point.  The registers latch one copy of the results which 
> then feed multiple circuits in parallel.  The is the "output register" 
> view.  If you consider registering the inputs of each functional block, 
> the outputs of a block will feed multiple registers, but only the ones 
> required for the next calculation are enabled so the unused logic is 
> "quiet" and does not use power.

Right.

> So while in general the registers "separate" blocks of logic, how you 
> enable them and how many you use depends on your view and determines how 
> much power is used.

Exactly.

> > Other design styles are possible, so your observation is very
> > relevant. And even with RTL you have multiplexors that can be placed
> > closer to the outputs of the registers or near their inputs, and
> > the choice will have an effect on power and speed.
> 
> I don't get what you are saying about multiplexers.  Multiplexers are 
> part of the logic.  What does that have to do with "RTL"?

I was just saying what you were saying but in a different way.

Your "output register" view has a direct connection between the
register's input and the output of one combinational block. The
output of the register goes to many combinational blocks in
parallel. But this means that more than one register can send
data to the same combinational block (for any interesting
design), which implies some multiplexor at the inputs of that
block.

REG ---- MUX ----- LOGIC --- REG
REG ----|

Your "input register" view has a direct connection between the
register's output and the input of one combinational block. The
input of a register must come from several combinational blocks
which means there must be a multiplexor at the input of the
register.

REG ---- LOGIC ----- MUX ---- REG
REG ---- LOGIC -----|

Suppose that the select lines for all the multiplexors can
change a bit after the clock. In the "output register" view
this means that the inputs for logic blocks take a while to
settle down, which causes pointless transitions and wasted
energy. In the "input register" view this means that the
inputs for the logic blocks are stable soon after the clock.

This all applies to RTL but, as I said, this is just one
particular design style. Though, like structured programming,
it is currently used so extensively that it is easy to forget
it is not the only option.

-- Jecel

[toc] | [prev] | [next] | [standalone]

#51160

On 9/21/2016 4:42 PM, Jecel wrote:
> On Saturday, September 17, 2016 at 6:05:42 PM UTC-3, rickman wrote:
>> On 9/16/2016 1:38 PM, Jecel wrote:
>> I don't know about the F21.  On the F18A the NOPs (denoted by a period
>> in the instruction set which you used to indicated all the other
>> instructions) are not so relevant since the adder is running all the
>> time while the other instructions are running.  Any time the stack
>> changes the adder runs and consumes power.  Is the F21 different?
>
> No, that is exactly how the F21 was designed as well.
>
>>> [RTL: register on inputs AND outputs]
>> You miss the point.  The registers latch one copy of the results which
>> then feed multiple circuits in parallel.  The is the "output register"
>> view.  If you consider registering the inputs of each functional block,
>> the outputs of a block will feed multiple registers, but only the ones
>> required for the next calculation are enabled so the unused logic is
>> "quiet" and does not use power.
>
> Right.
>
>> So while in general the registers "separate" blocks of logic, how you
>> enable them and how many you use depends on your view and determines how
>> much power is used.
>
> Exactly.
>
>>> Other design styles are possible, so your observation is very
>>> relevant. And even with RTL you have multiplexors that can be placed
>>> closer to the outputs of the registers or near their inputs, and
>>> the choice will have an effect on power and speed.
>>
>> I don't get what you are saying about multiplexers.  Multiplexers are
>> part of the logic.  What does that have to do with "RTL"?
>
> I was just saying what you were saying but in a different way.
>
> Your "output register" view has a direct connection between the
> register's input and the output of one combinational block. The
> output of the register goes to many combinational blocks in
> parallel. But this means that more than one register can send
> data to the same combinational block (for any interesting
> design), which implies some multiplexor at the inputs of that
> block.
>
> REG ---- MUX ----- LOGIC --- REG
> REG ----|


If there is a mux, it is just part of the logic.  Multiple registers 
feeding the same logic is just that.  Logic has many inputs.

         +-------+
REG --->|       |
         | Logic |--->
REG --->|       |
         +-------+

> Your "input register" view has a direct connection between the
> register's output and the input of one combinational block. The
> input of a register must come from several combinational blocks
> which means there must be a multiplexor at the input of the
> register.
>
> REG ---- LOGIC ----- MUX ---- REG
> REG ---- LOGIC -----|

No mux.  One register on the input of each logic block.  No muxes 
anywhere unless they are part of the logic.

Register on logic output.

                  +--- LOGIC --- REG
                  |
LOGIC --- REG ---+
                  |
                  +--- LOGIC --- REG

Reg on inputs
                  +---- REG --- LOGIC
                  |
REG --- LOGIC ---+
                  |
                  +---- REG --- LOGIC


The difference is that the registers on the inputs do not all get 
enabled.  Only the registers feeding logic being used are enabled so any 
logic that is not needed is quiet and not using power.


> Suppose that the select lines for all the multiplexors can
> change a bit after the clock. In the "output register" view
> this means that the inputs for logic blocks take a while to
> settle down, which causes pointless transitions and wasted
> energy. In the "input register" view this means that the
> inputs for the logic blocks are stable soon after the clock.

Forget these muxes.  They don't exist.


> This all applies to RTL but, as I said, this is just one
> particular design style. Though, like structured programming,
> it is currently used so extensively that it is easy to forget
> it is not the only option.

RTL is a coding style I thought.  I'm not sure what you are saying about 
that.

Structured programming is very different and orthogonal I thought.  This 
has to do with using well defined control flow structures like IF THEN 
ELSE or BEGIN UNTIL, etc. in place of GOTO which Forth doesn't have 
unless you want to add your own.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#51191

On Wednesday, September 21, 2016 at 7:03:23 PM UTC-3, rickman wrote:

> If there is a mux, it is just part of the logic.  [....]

> Forget these muxes.  They don't exist.

They most certainly do exist, but are part of the logic as you
said. Imagine you have a register called PC and sometimes you want
to load it from the output of an incrementer and sometimes you
want to load it from the output of the ALU. That implies a mux,
which has different timing for its input lines and for its select
lines. Where you put this mux inside the logic block will change
the total delay of that block as well as its energy use.

> RTL is a coding style I thought.  I'm not sure what you are saying about 
> that.

I can write code in Verilog that is not RTL. Just like I was forced
to write only structured code in Fortran at the university but the
language itself allowed styles like spaghetti coding if I wanted.

-- Jecel

[toc] | [prev] | [next] | [standalone]

#50778

In article <bc52bcf1-4045-425b-bbc4-a0cb0791e2e8@googlegroups.com>,
JUERGEN  <epldfpga@aol.com> wrote:
>On Monday, August 22, 2016 at 11:07:10 PM UTC+1, Mux wrote:
>> Hi all,
>>
>> Is there any documentation / video on how Chuck used OKAD to design his chips? Particularly interested in how he did the routing and what not..
>>
>> Cheers,
>>
>> -Mux
>
>The question I ask myself: has anybody else apart from Chuck used this system to do a chip - or at least play with it?

Or even, since Chuck's laptop died, has Chuck tried to read the
floppy with OKAD on some other laptop?

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50779

On Friday, September 9, 2016 at 12:53:18 PM UTC+1, Albert van der Horst wrote:
> In article <bc52bcf1-4045-425b-bbc4-a0cb0791e2e8@googlegroups.com>,
> JUERGEN  <epldfpga@aol.com> wrote:
> >On Monday, August 22, 2016 at 11:07:10 PM UTC+1, Mux wrote:
> >> Hi all,
> >>
> >> Is there any documentation / video on how Chuck used OKAD to design his chips? Particularly interested in how he did the routing and what not..
> >>
> >> Cheers,
> >>
> >> -Mux
> >
> >The question I ask myself: has anybody else apart from Chuck used this system to do a chip - or at least play with it?
> 
> Or even, since Chuck's laptop died, has Chuck tried to read the
> floppy with OKAD on some other laptop?
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

could you amuse us by telling what silly things you have done in your life?

[toc] | [prev] | [next] | [standalone]

#50938

Hi all

Unfortunately, OKAD is no more than a toy. Please don't be too encouraged by the ability to 'build a chip'. GDSII format for factory looks like set of polygons in different layers. It is relatively easy to create even by notepad, but main issue is to perform Design Rules Check. Drawing transistors according to discrete electronic skills leads to failure sooner or later. GA is not scalable design, even not reliable for 180-130 nm node. I remember estimation of 1 GHz clock speed, but in reality it is much slower. In technical terms, having 600 MHz instead of 1 GHz looks like failure. Industry CADs from vendors like Cadence or Synopsys provides complete design flow for chips and perform huge amount of DRC procedures, covering number of known physical effects. Voltage drop, heat dissipating etc are included. So OKAD looks like an attempt to solve a very complex problem by ignoring basics... 'because of Forth'.

[toc] | [prev] | [next] | [standalone]

#50941

On Tuesday, September 13, 2016 at 5:19:01 PM UTC+1, Ilya Tarasov wrote:
> Hi all
> 
> Unfortunately, OKAD is no more than a toy. Please don't be too encouraged by the ability to 'build a chip'. GDSII format for factory looks like set of polygons in different layers. It is relatively easy to create even by notepad, but main issue is to perform Design Rules Check. Drawing transistors according to discrete electronic skills leads to failure sooner or later. GA is not scalable design, even not reliable for 180-130 nm node. I remember estimation of 1 GHz clock speed, but in reality it is much slower. In technical terms, having 600 MHz instead of 1 GHz looks like failure. Industry CADs from vendors like Cadence or Synopsys provides complete design flow for chips and perform huge amount of DRC procedures, covering number of known physical effects. Voltage drop, heat dissipating etc are included. So OKAD looks like an attempt to solve a very complex problem by ignoring basics... 'because of Forth'.

Ilya, I might want to disagree. It is the same approach of Chuck as with Forth. A minimum approach. Normally the factory runs loads of wafers to get the design rules ready. And to cover the spread across the wafer. And they only know afterwards as well and tweak the design kit for the next run. Even Boole's algebra normally does not work, as timing and wire delays have to be added to the design kit to make it work. He did a design - probably rule of thumb - with 0 design tool cost compared with how many Dollars per year for a design software? Yes, it is not competition to Cadence - but I think this as never the target. I see it as a proof of concept - as not many chips have been designed with it to get stable results. And 1 Million Dollar chips might need a second round as well as design targets have not been achieved. You can relax the design rules, be not as efficient but it still  works - if it is fast enough - fine. 
Bottom line though is that okCAD is not accessible as I have been told recently - so it might stay a theoretical discussion forever.

[toc] | [prev] | [next] | [standalone]

#51049

> Ilya, I might want to disagree. It is the same approach of Chuck as with 

I see your arguments. I also see Chuck's reasons to do what he did.  Yes, we need to make things easy, but not too much. Microelectronics already works with many effects and its you choise to keep it in mind or not. The goal of making CADs more complex is not to make them too hard to write, but to make chips work perfectly. You can use F=mg for school calculating of stone falling trajectory, but it is not enough to calculate trajectory of spaceship. OKAD just ignoring most part of chip design flow and it is not too wise to hide from problems.

[toc] | [prev] | [next] | [standalone]

#51071

On Saturday, September 17, 2016 at 1:24:23 AM UTC+1, Ilya Tarasov wrote:
> > Ilya, I might want to disagree. It is the same approach of Chuck as with 
> 
> I see your arguments. I also see Chuck's reasons to do what he did.  Yes, we need to make things easy, but not too much. Microelectronics already works with many effects and its you choise to keep it in mind or not. The goal of making CADs more complex is not to make them too hard to write, but to make chips work perfectly. You can use F=mg for school calculating of stone falling trajectory, but it is not enough to calculate trajectory of spaceship. OKAD just ignoring most part of chip design flow and it is not too wise to hide from problems.

Ilya, I agree actually with all of your points, but there is nothing stopping me to go a hobby route and hand draw a simple library in GDS3 - just the AND OR INVERT XOR, might have forgotten one - and then convince a fab to run them through a fab - a bit of dirt in the corner - and characterize afterwards - not effective not fast and a lot of work. Then I can design Flip Flops registers - actually this is exactly why I was interested in OKCAD. Or go the route of an OKCAD designed FPGA - yes routing delays will be an issue - do it in NCL asynchronously and most of the issues disappear. Some info is hidden deep in the ExMark Files from http://www.exemark.com/asynch/index.html; have not touched it for many many years so have not checked it either, just as a flavour.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web