[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Computer Go hardware
>
>in College in my senior year, we designed a graphics accelerator on
>Xilinx 4005 series FPGA's, it basically was a RISC based computer, 16
>bit of data paths, etc. But we had to use Mentor Graphics tools
>(Design Architect, etc) and all the code, assembly coding were done in
>parallel to the mentor graphics tools. How do these FPGA boards work
>on the current PC's ?
>
I work since the beginning of the Brutus/Hydra project with boards from the
Edinburgh based company Alpha-Data. I have the best experiences with these
boards. But these boards are more on the high-end side. The Alpha-Data staff
has also a lot of FPGA-experience and I got an excellent support. At the
beginning of the project I did not even now what FPGA means. I asked them a
lot of stupid questions.
See www.alpha-data.com
The 4005 is now very outdated. But the work - at least my work - is
basically the same. I use the XiLinx Standard Synthese tools (they are the
cheapest tools). The FPGA-part is written in Verilog, the PC-Side of the
programm in C. Additionally I have a full C-Simulator/Verificator. The
Simulator is NOT a direct translation of the Verilog code (or the other way
round). It is on purpose in a quite different style. It is used to verify
the FPGA part. Normal HDL simulators are for Hydra of little use. It is the
combination of the software and the hardware part which is critical. The
error one gets after searching 20 Plies deep into a completly strange
position. I have found no practical way to interface from the C-chess engine
to the simulators. The simulators are also much too slow.
It would be helpfull to have a direct translation of the C-Simulator to HDL.
But on the other side I have already considerable experience in doing this
conversion by hand. It is cumbersome, but so far this is no mayor source of
bugs.
The problem with the automatic C to HDL tools is:
a) The quality of the translation is low (for general types of
problems).
b) One has to write in a specific C-Style which is not very natural for
"normal" C programming. This is in contradiction to the verification purpose
of the C-code.
c) The tools are even for a Sheikh expensive.
I can also write in the meantime C-code, which can be almost
automatically transformed with some vim-commands into Verilog.
Chrilly
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/