Author: Robert Hyatt
Date: 05:07:56 04/07/00
Go up one level in this thread
On April 07, 2000 at 04:43:28, Tom Kerrigan wrote: >On April 07, 2000 at 00:19:54, Robert Hyatt wrote: > >>I would parallelize the Hsu/Thompson design. Do a find-victim/find-aggressor >>cycle for black and white in parallel. This is a one-cycle operation... with > >Really? It's been about 2 months since I last read about this stuff, but I >thought it was a 2 cycle operation. First, assert find-victim, then latch some >values, then assert find-aggressor. > >To do the white and black thing in parallel, I think you would basically need >two move generators. Otherwise the attack signals would be all wrong. The FSMs >are built with the assumption that the attack signals depend on the >side-to-move. > That's why I said "I wouldn't use the move generator circuitry for this..." I would simply design this circuit from scratch and then the white/black FV/FA circuits wouldn't care about wtm/!wtm at all. And two cycles or one cycle doesn't matter, as it is an _internal_ cycle to the ASIC... Again, it all depends on the design and the total gate-delay thru a cycle. FV could be done in 1/2 cycle, or it could be overlapped with something else to hide the time... >>things to hide the cost totally... Typical SEE cycle would take two to three >>such cycles since most cases (at least last time I counted them) had only one > >You're ignoring my main point. Let's say that generating a move takes one cycle >and doing SEE takes one cycle. Now let's say you're at a node where there are 5 >captures and you get a cutoff after capture #2. If you rely on MVV/LVA, then you >only have to spend 2 cycles generating moves. If you do SEE, then you have to >generate all the captures (5 cycles) and do the SEE calculations for all of them >(another 5 cycles). So doing SEE takes 10/2=5 times as long. This ignores the >fact that the SEE is probably much more expensive than 1 cycle, and the added >complexity/time of saving the list of captures/SEE values and then sorting them. Again, as I said, if I was designing a circuit to do a SEE, it would _still_ be faster than software SEE. And it could include as much as we wanted in terms of not overlooking pinned pieces or whatever... and _still_ run fast enough that it would be totally unnoticable in a chess engine... IMHO of course. >I wouldn't be surprised at all if the SEE method took 10 to 20 times as long. > Certainly it would. But here, who cares? That 20 times longer gets buried in the rest of the hardware stuff that is going on. MVV/LVA is perfect for simple hardware move generators for totally obvious reasons. The main one is simplicity. But SEE is definitely doable... just not real easy... But then, DB wasn't "easy" to build.. >>or two attackers for one side at most. It would not be easy... but it would >>definitely be doable. I wouldn't want to try an FPGA design, probably, but >>an ASIC? Hsu was looking for things to take up the last bit of real estate on >>his ASICS. a SEE 'block' would be a useful addition (IMHO) > >He had to struggle to fit the Chiptest generator onto one ASIC. Admittedly, it >was a 2 micron process, but that tells me that the logic might be more >complicated than you might think. > >-Tom Not when you read the details about the _last_ ASIC. They added kpk endgame database to simply fill out the remainder of the chip... which sounds like space wasn't a problem... especially considering they used under 50% of the total eval hardware in the last version of DB, which suggests that he also added a _lot_ of feature detection hardware that was also done just to fill out the chip and was not used due to lack of time to test it.
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.