Re: computer-go: question -- Oracle of Life and Death FPGA

["Gary Boos" <gboos@xxxxxxx>]

Here, perhaps I may be able to contribute a bit to the
discussion:  I think such a new machine would be allowed
by the Ing foundation.
    Gary
-----------
-----------
-----Original Message-----
From: Kurt Thorn Perkins <thorn@xxxxxxxxxxxxxxxxx>
To: computer-go@xxxxxxxxxxxxxxxxx <computer-go@xxxxxxxxxxxxxxxxx>
Date: Sunday, December 12, 1999 4:20 PM
Subject: Re: computer-go: question -- Oracle of Life and Death FPGA


>Many FPGAs excel at table lookups (that being how many of their internal
>calculations are arrived at), so I believe they would be more of a fast
library
>lookup.  Just a side thought.
>
>You're right about FPGA clock speeds.  However, unless there is an
advantage
>in having a dynamically reprogrammable piece of hardware in a design, the
>normal path is to use an FPGA to prototype, then take the ASIC design file
>and ship it off to someone to actually produce silicon that matches it.
The
>final piece of hardware is usually an order of magnitude faster than the
FPGA
>is capable of.  On the other hand, while it is cheap (relatively) and easy
to get
>customized silicon made, it is usually with minimum orders of several
kiloparts.
>Perhaps if someone knows a university with access to protofab facilities?
(My
>school was just starting to get the equipment when I left this past
spring...
>likely
>another year or two before its up.)
>
>Now, a question (I am almost certain its been asked, but I can't find the
answer
>in the archives... probably just not doing it right).  The primary goal of
most
>efforts seems to be writing better software and tuning it to run as fast as
>possible
>on standard computers.  Most of these computers are also running other
programs
>that eat up cycle time, such as the OS or supporting programs (just ask
anyone
>who has run a program in an OS like Linux both with and without the GUI).
>Does anyone believe there would be an advantage to designing a computer
>that has only one goal... playing Go?  Some of the required items to
support
>input and output could be relegated to microcontrollers or a support
processor
>of lower caliber, with the main processor (Alpha, PIII, Lego computer)
providing
>most of its cycle time to evaluation of the board.
>
>A alternative to this might be an SBC that is designed to work in the PCI
bus, so
>that you could have this card doing the evaluations of the board, and
sending
>the results to a normal PC/Mac to handle the user interface issues.
>
>The two largest problems I see with this is the time of designing and
producing
>a system along these lines initially, and that I don't believe it would be
>permitted
>in the Ing cup. :)
>
>So, what am I missing here?  I know there has to be something.
>
>  Kurt
>
>
>Compgo123@xxxxxxxxxxxxxxxxx wrote:
>
>> >From my own experience, a life death search is quite involved and need
to be
>> very adaptable. It's not very well defined yet .Thus make it difficult to
>> implement in a FPGA. To justify a special hardware, the speed improvement
>> should be at least a factor of 10. The clock speed of present FPGA's is
about
>> 60 MHz. Thus, a parallel factor of 10 will only make a FPGA equivalent to
a
>> 700 MHz cpu.  I think the most suitable algorithms to implement in
special
>> hardwares are the utility routines in computer Go. For example, the group
>> structure is well defined and standardized. However, to maintain the
group
>> structures and it's properties needs lengthy calculations. If these
>> calculations can be implemented in a special hardware the improvement to
>> overall speed will be tremendous. As Clay Chipsmith pointed out, this can
be
>> approached in three ways. Parellel cpus, FPGA's, and special hardwares.
FPGA
>> is somewhere between the first and the third approaches. I did some
reading
>> about the FPGAs. It seems more adapted to implement digital parallel
>> calculations.  It's not quite yet adapted to exploit the geometric
structures
>> of the Go board. Thus, a special hardware will be the most ideal way to
>> approach the problem. The general structure of this special hardware can
be
>> worked out easily. The problem is where to find the resources to
implement it.
>>
>> Dan Liu
>