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 1 of 2  [1] 2  Next page →

#50409 — OKAD?

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

[toc] | [next] | [standalone]

#50411

Mux <Yvo.Zoer@gmail.com> writes:
> 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..

It's hand layout, tiles with gates and circuits and hand routing between
them, comparable to various 1980s tools.

    https://www.youtube.com/results?search_query=okad+forth

finds a few videos that I haven't watched, but there are also some web
pages that describe it.

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

#50414

On 8/23/2016 12:07 AM, 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
>

Hi Mux,

first, there is Chucks own description of the OKAD system, on his lately 
vanished website colorforth.com. Fortunately, the wayback machine 
provides us with the latest snapshot:

http://web.archive.org/web/20160314224653/http://www.colorforth.com/vlsi.html

Second, Jeff Fox's site http://ultratechnology.com/ contains a bunch of 
information about colorforth, OKAD, OKAD 2 and many more systems, 
including descriptions how Chuck used OKAD for designing the F21, c18, 
and related chips; Jeff has worked with Chuck for about three decades 
until he sadly passed away at 5/4/2011.
strangeGizmo.com kindly hosts ultratechnology.com now.

You may also find videos on http://www.forth.org/svfig/ made on the 
SVFIG Silicon Valley Forth Interest Days, which Chuck attended regularly 
(and still does afaik).

Regards,
Bernd

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

#50432

On Monday, August 22, 2016 at 4:44:30 PM UTC-7, Bernd Linsel wrote:
> On 8/23/2016 12:07 AM, 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
> >
> 
> Hi Mux,
> 
> first, there is Chucks own description of the OKAD system, on his lately 
> vanished website colorforth.com. Fortunately, the wayback machine 
> provides us with the latest snapshot:
> 
> http://web.archive.org/web/20160314224653/http://www.colorforth.com/vlsi.html
> 
> Second, Jeff Fox's site http://ultratechnology.com/ contains a bunch of 
> information about colorforth, OKAD, OKAD 2 and many more systems, 
> including descriptions how Chuck used OKAD for designing the F21, c18, 
> and related chips; Jeff has worked with Chuck for about three decades 
> until he sadly passed away at 5/4/2011.
> strangeGizmo.com kindly hosts ultratechnology.com now.
> 
> You may also find videos on http://www.forth.org/svfig/ made on the 
> SVFIG Silicon Valley Forth Interest Days, which Chuck attended regularly 
> (and still does afaik).
> 
> Regards,
> Bernd

Thanks all!

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

#50772

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?

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

#50777

On Friday, September 9, 2016 at 8:18:32 AM UTC+1, JUERGEN 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?

Just looked through the data on the wayback link:

VLSI Design Tools
In 500 lines of colorForth these tools provide everything required to design a chip. They are derived from an earlier version called OKAD that successfully generated many versions of Forth microprocessor chips. 

Can somebody point me to these 500 lines of colorforth?

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

#50783

On 9/9/2016 5:47 AM, JUERGEN wrote:
> On Friday, September 9, 2016 at 8:18:32 AM UTC+1, JUERGEN 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?
>
> Just looked through the data on the wayback link:
>
> VLSI Design Tools
> In 500 lines of colorForth these tools provide everything required to design a chip. They are derived from an earlier version called OKAD that successfully generated many versions of Forth microprocessor chips.
>
> Can somebody point me to these 500 lines of colorforth?

Even if you can design a chip using such minimal code, there are tons of 
rules and other documentation required to do anything useful.  I don't 
know, but I suspect the tools don't do any design calculations other 
than putting features where you want them.  I expect it is also set up 
to target one specific process although if it isn't doing any design 
calculations or checking it could easily be process agnostic.

In other words, I bet this is just a drawing package.

-- 

Rick C

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

#50784

On Friday, September 9, 2016 at 4:52:29 PM UTC+1, rickman wrote:
> On 9/9/2016 5:47 AM, JUERGEN wrote:
> > On Friday, September 9, 2016 at 8:18:32 AM UTC+1, JUERGEN 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?
> >
> > Just looked through the data on the wayback link:
> >
> > VLSI Design Tools
> > In 500 lines of colorForth these tools provide everything required to design a chip. They are derived from an earlier version called OKAD that successfully generated many versions of Forth microprocessor chips.
> >
> > Can somebody point me to these 500 lines of colorforth?
> 
> Even if you can design a chip using such minimal code, there are tons of 
> rules and other documentation required to do anything useful.  I don't 
> know, but I suspect the tools don't do any design calculations other 
> than putting features where you want them.  I expect it is also set up 
> to target one specific process although if it isn't doing any design 
> calculations or checking it could easily be process agnostic.
> 
> In other words, I bet this is just a drawing package.
> 
> -- 
> 
> Rick C

What knowledge are you basing your bet on?

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

#50789

It has simulation built in. Not at the clock tick level either like modern tools. You can watch capacitors charge and discharge. 

Incredible.

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

#50790

On 9/9/2016 5:57 PM, Mark Wills wrote:
> It has simulation built in. Not at the clock tick level either like modern tools. You can watch capacitors charge and discharge.
>
> Incredible.

Do you know what process it is developed for?  I recall reading that he 
didn't use the standard models for transistors and developed his own. 
The claim was made that it showed Spice to be "wrong" whatever that 
means.  Spice is a tool like a hammer.  Use it one way it builds, use it 
another and it tears down.  Neither Spice nor the hammer know anything 
about how you use them.

-- 

Rick C

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

#50791

rickman <gnuarm@gmail.com> writes:
> Do you know what process it is developed for?

It's been used with a bunch, going back to the F21.  The GA processors
were made in both 180nm and 130nm.

There have been a few other threads about OKAD and the 500LOC is not the
whole package, but rather some (important) part, or maybe the part in
memory at a given moment.  I remember reading that the program was
around 250KB but it was in overlays so not much was being run at any
moment.

Its capabilities seemed comparable to 1980s-era tools like Caesar.
You'd hand-layout gates etc. on "tiles" and place tiles by hand, and the
tool did some DRC and timing simulation iirc.  Lots of chips including
(small by today's standards) microprocessors were made that way back
then.  At higher complexity (like we see now) it may be less manageable.

> I recall reading that he didn't use the standard models for
> transistors and developed his own. The claim was made that it showed
> Spice to be "wrong" whatever that means.

The claim was that OKAD modelled transistor temperature and SPICE
didn't.  But SPICE is definitely capable of doing that.

I don't think the code was ever released.  I hope they do release it
since it doesn't seem to have all that much commercial value these days,
and it would be interesting to look at a large Colorforth program.

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

#50796

On 9/9/2016 6:33 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Do you know what process it is developed for?
>
> It's been used with a bunch, going back to the F21.  The GA processors
> were made in both 180nm and 130nm.
>
> There have been a few other threads about OKAD and the 500LOC is not the
> whole package, but rather some (important) part, or maybe the part in
> memory at a given moment.  I remember reading that the program was
> around 250KB but it was in overlays so not much was being run at any
> moment.
>
> Its capabilities seemed comparable to 1980s-era tools like Caesar.
> You'd hand-layout gates etc. on "tiles" and place tiles by hand, and the
> tool did some DRC and timing simulation iirc.  Lots of chips including
> (small by today's standards) microprocessors were made that way back
> then.  At higher complexity (like we see now) it may be less manageable.
>
>> I recall reading that he didn't use the standard models for
>> transistors and developed his own. The claim was made that it showed
>> Spice to be "wrong" whatever that means.
>
> The claim was that OKAD modelled transistor temperature and SPICE
> didn't.  But SPICE is definitely capable of doing that.
>
> I don't think the code was ever released.  I hope they do release it
> since it doesn't seem to have all that much commercial value these days,
> and it would be interesting to look at a large Colorforth program.

I recall the specific claim by Jeff Fox that these tools showed spice 
was "broken" or "wrong".  I think they were using some boundary 
conditions of their transistors that were not used in conventional 
designs and so might not simulate properly by spice, but I don't know 
for sure.  I *do* know that while it was claimed this tool allowed them 
to design much faster transistors, spice is not "broken".  It's a tool 
equivalent to a spread sheet.  It's up to the user to use it correctly 
with valid models, etc.

-- 

Rick C

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

#50797

On Saturday, September 10, 2016 at 12:33:39 AM UTC+2, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
[..]
>> I recall reading that he didn't use the standard models for
>> transistors and developed his own. The claim was made that it showed
>> Spice to be "wrong" whatever that means.

>The claim was that OKAD modelled transistor temperature and SPICE
>didn't.  But SPICE is definitely capable of doing that.

SPICE models that compute local device dissipation, and, through
an approximation of local thermal properties (thermal resistance 
and capacitance), compute local temperature to be used in the 
standard device equations, are a relatively recent SPICE addition.
Because of the order of magnitude difference between thermal and 
electrical time constants such computations are exponentially 
slower than purely electrical ones. Normally one does this only 
for a few selected devices and with a vastly simplified thermal 
network.

With OKAD, Chuck Moore very likely solved the issues at hand without 
trying to generalize the approach to anything but his own circuit. 
I am sure very good results are possible given access to the numerical
process parameters of the foundry (he might need to have used 
a SPICE to be able to get at this data).

Obviously not many people in industry enjoy the luxury of being
allowed this way of working to build real chips. It is prone to
burn millions of dollars in failed test runs and missing the 
window for profitable chip introduction. Also, you can't switch 
fabs or processes without revising all physical experiments
and all your code.

'Computer Cowboys' -- Chuck certainly knew what he was doing :-)

-marcel

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

#50917

Most of the information available on OKAD can be found
Chuck Moore's "fireside chats" over the years and in the
old colorforth web site.

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.

With the improved OKAD this kind of design problem would
not happen again.

Comparing the Fireside Chats from different years you can
see some evolution in OKAD. Originally there was a lot of
manual design at the rectangle level but it became a higher
level language over time and the building blocks were
more flexible.

-- Jecel

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

#50920

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.

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

#50922

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

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

#50947

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?

-- 

Rick C

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

#50958

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]

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

#50961

Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
> 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 believe each core is clocked by a ring oscillator local to that core.

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

#50962

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web