Author: Robert Hyatt
Date: 07:15:08 12/22/99
Go up one level in this thread
On December 22, 1999 at 01:49:14, David Blackman wrote: >On December 21, 1999 at 10:40:50, Robert Hyatt wrote: > > >> >>I am more concerned about a different problem. This ram is single-ported. Yet >>a good hardware eval will continually be reading bits and pieces out of this >>memory... how many pawns on this file.. which side has the left-most passed >>pawn or candidate, which side has the right-most passed pawn or candidate... >> >>This means that memory is going to be accessed from many different eval >>components. And I don't see how to do this efficiently, as it is going to be >>a serial bottleneck. In a non-FPGA design, you could distribute this memory >>around so that this isn't a bit handicap, but here it is. > >I've been reading about the latest FPGAs from Xylinx and other companies. Which >is not quite the same as actually using the things :-) But it appears they are >getting really serious about RAM on FPGAs these days. > >First there is a lot of it available. Certainly up to 10s of KBytes on many >models. As I mentioned earlier. This doesn't help me. My code for candidate passers and outside passers uses 256kb of memory, not counting all the other stuff used elsewhere in the eval. I (for my eval, anyway) would probably want at least 1-2 megabytes... > Second, for at least some models it is dual port ram, or at least 2 read >or 1 write per cycle. A typical pawn eval would process all 8 files in parallel, which means 8 reads would be needed at one time so that one file evaluator can get the pawns on that + the 1 or 2 adjacent files... Not to mention the locations of pieces to test for blockaders, rooks for weak pawns on half-open files, etc... > Third, most of the models i read about partition the ram >into lots of fairly small cells, each independant and connected to a local array >of processing elements nearby on the chip. Each of these RAM/processing element >chunks seems to work in parallel, so the total bandwidth to all the ram on the >FPGA must be enormous. Tricky if you want a single large unified address space, >but great if you have a lot of small parallel processes each needing memory >access. That would certainly help, although it increases the set-up time for a position. But you could theoretically send 3 files of pawn info to each of 8 SRAMS on the chip, then you effectively have an 8-ported memory during the eval. However, it would also mean that the setup time would be far longer than the execution time of the entire eval. > >Now it looks to me that programming one of these efficiently would be a bit >tricky, and certainly very different to programming a conventional CPU. But i >reckon if you could figure it out, you could get a FPGA to run chess really, >really fast. If the figures quoted by Xilinx are just the usual marketing hype, >and not total outright lies, then their top of the line FPGAs are better than >the ASICs used by Deep Blue in almost every way. More gates, more memory, >faster, etc. Not quite as flexible of course, but the hardware is grouped in a >reasonably convenient way and there is so much extra resources available that i >think you would have to come out ahead. They aren't better than ASICS in a couple of important ways. The main one being that it is necessary to move results from one part of the eval to another part. quickly. With DB's ASICS, Hsu just included a 'bus' that could be used to move stuff from one side to the other quickly. With FPGAs, you have a box of leggos (you can build a lot with them, but you are definitely very constrained in the basic components you can use). With ASICS, you have a clean sheet of paper that can hold any digital component you want, from a mux to a bus to adders/shifters to you-name-it. They are very different in that regard. FPGA's don't do well at 'parallel' stuff if the things being done in parallel are way different. You then resort to multiple FPGAs and run them in parallel to do this. ASICS let you build exactly what you need... IE at one instant I want to be evaluating pawns, and knights, and bishops, and rooks, and queens, and finding out which pieces are lined up on the same diagonal or file, and looking at the pawn structure around the king, and looking at how many pieces are bearing on the king, and how easy it is to open one or more lines to the king, etc. All at the same time so I can fold that together into one number, in as few cycles as possible. > >FPGAs have come a long way in the last few years. Yes they have... as has most of digital electronics...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.