Is my FPGA chess move generation slow because of the board representation or something else?

The bottleneck you are seeing is likely the board representation and how you are accessing it, not just the move generation. When you are using an 8x8 array of squares, every time you want to check if a knight can jump to a specific square, you are essentially doing multiple memory lookups and conditional branches. This is slow because it forces the pipeline to stall repeatedly, even at 100 MHz. Switching to bitboards is not just a minor refactor; it's a structural change that allows you to represent the entire board state as a small, fixed number of parallel registers, which is what FPGAs excel at. Operations like 'check if any white piece is on this target square' or 'move all black pieces one square' then become simple logical shifts and AND/OR operations. The clock cycles per node should drop dramatically when you move to that parallel style.

Before you fully commit to rewriting the move logic in bitboard format, though, you absolutely need to quantify the time spent on the search logic versus the time spent on setup. Use your timing reports to break down each node: how many cycles are spent iterating through your arrays versus how many cycles are spent executing the pruning logic itself. If the setup and move generation phase dominates the execution time, then improving the representation is the immediate win. If the pruning logic is complex, then you need to look at move ordering. A poorly ordered alpha-beta search exploring useless lines is a huge waste of cycles, regardless of how fast your bitboard operations are. I reccomend implementing the bitboards first, but focus on the basic move generation and state update. Then, measure the performance gain. Once the fundamental board access time is minimized, you can really focus on optimizing the search algorithm itself, like implementing specific killer or transposition tables, which will reduce the number of nodes you even have to visit in the first place. It is almost guaranteed that reducing the time it takes to process a single node will give you a far more noticible jump than tweaking the pruning logic alone right now.

I'm working on a pretty simple signal processing filter on my board right now, not something as big as chess, so I don't have the same kind of search complexity. But even for that, getting the initial structure to talk to the clock is just a headache. If switching to bitboards is that big of a structural change, do you think I should just start with a highly simplified version of my problem first? Maybe get the basic data moving before trying to map out the whole parallel logic. The idea of massive parallel registers is cool, but writing the logic for even a tiny part of it feels overwhelming at the moment.

If you decide to go with the bitboard approach, just be careful about how you initialize the data structure. People tend to overcomplicate the register mapping, but you want something simple to start. When I implemented my first move generation unit, I used a fixed 64-bit register for piece positions, and that reduced the setup overhead from about 2500 cycles down to less than 50. Focus on that minimum viable representation first. Don't try to hardcode every possable move sequence in the initial design. Start small and see the speed jump, then expand the logic.