As I said, it's good for engine games but it's a bad idea for games against human players. I don't know if there are any playchess games in the Rybka 4 book, but Jiri said that he thoroughly chose games he thought good enough to add.

That is my speculation, yes.  On a decent dual 6-core nehalem box at the last CCT I saw speeds of 30M-50M nodes per second.  For a single CPU, you have two choices.  You can take a single FPGA and let it be the "chess board" giving you a very fast Make/Unmake/Evaluate as Ken Thompson did in Belle prior to the 1980 version.  Or you can do as he did later, and implement the entire search in the FPGA.  That is problematic for lots of reasons.  It is a finite state machine.  Variable length operations are not good.  And you can't access a large RAM memory efficiently which wrecks hashing.  The first FPGA search, 1980 belle, searched at 160K nodes per second.  We beat Ken searching around 10-20K nodes per second.  And we did a lot of comparisons since we were good friends, and we discovered that his huge gain in speed came at a big cost.  No hash tables.  No killer moves.  All he could do for move ordering was MVV/LVA for captures, and that was it.  We actually found problem solutions faster than Belle, even though we were running at 1/16th to 1/8th the speed.  And in endgames it got _much_ worse since we had hashing and he did not.

The real gains come from multiple FPGA cards, ala Hsu and hydra, where you take those very inefficient searches done in the FPGA, and run 'em in parallel from a more usual software search, except the software search stops at some remaining depth (8, 10, would vary by program) and hands that position off to one of the many FPGA cards and says "give me a score for this branch".  There is a lot lost in terms of efficiency.  But not as much as a pure FPGA solution because the software part of the search can still do all the move ordering tricks.  And we all know that move ordering near the root is _much_ more important than move ordering out near the tips where the FPGAs would be searching.

It is pretty easy to be impressed until you get over the "what kind of speed can I see" and get to the "what do I have to give up to get that kind of speed?"  And when you start listing killer moves, SEE, hash tables you begin to get a sinking feeling.  Somewhat akin to a new Indy car showing up that has a motor that turns 30K rpm.  But so little torque that you have to gear it to the point it has a 150mph top speed.  Then that 30K doesn't look so hot.  Sounds impressive when it goes by, like a Honda S2000 winding out, but it doesn't go anywhere.

That's my take.  If I had one per CPU, I would certainly take the make/unmake/evaluate/generate/etc operations and move 'em out to the FPGA as I would gain a ton in terms of speed, without giving up hashing and the good things that make us efficient today.  That's no good for multiple CPUs if you only have one FPGA, as you would need one FPGA per cpu so that each could have its own board.