Periodically, I plan on taking a break from my interviews with programmable technology experts to post about other topics that I think might be of interest to readers (mostly because I'm interested in these topics myself -- but hey, that's part of doing a blog, right?). In this column I will introduce the first of these types of topics -- the definition and design of a chess-playing FPGA.
Why a chess-playing FPGA?
You might well ask. It turns out that there are many interesting aspects of the definition and design of an FPGA that can play chess. Also, there are several methodologies and algorithms used in this design that are found in other (non-game related) types of designs. A chess-playing FPGA can serve as an example (and a fun one at that) of these key techniques. It also helps us develop a different way of thinking about solving complex problems using FPGAs, as opposed to the traditional sequential approach we are trained for when working with processor-oriented designs. Chess gives us an opportunity to jog our brains from that (all too familiar) sequential space into the parallel computation space.
The definition and design of a chess-playing FPGA also gives us a chance to look at some examples of definition and design methodologies. What level of detail is enough for a first-pass definition? How do we include the ability to evaluate design options? Are there estimations that we can make to predict performance and other criteria early in the design so we don't get surprised late in the development cycle? Some of these questions are going to be more in the realm of design style ("More an art than a science?"), so these topics will be interesting to explore and get comments from others to better understand the breadth of possibilities available to us.
I can think of lots of other reasons why this should be an illuminating topic, but maybe it's better to just dive into the definition and development stage of the project and see what pops up.
Chess-playing FPGA: white to move.
The problem definition for a chess-playing FPGA is fairly simple. We want to create, in a single FPGA, an electronic chess-playing opponent. The FPGA will accept moves from the outside world, "think" for a while, and then provide its move back to the outside world. (Typically this will be via a human operator, but there is no reason why two electronic opponents couldn't play each other directly, without human intervention, if the move protocol is well defined.) We would expect the computer to stick to some standard amount of time, similar to the way human chess matches are played (for example, 90 minutes for the first 40 moves).
Next page >