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

[Kurt Thorn Perkins <thorn@xxxxxxxxxxxx>]

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