I'll agree. Make it work FIRST. If it ships it's a bonus 
The beauty with FPGA is that you can ship first, and code later 
You gotta do something to prove the FPGA PCB works. No sense in shipping a buggy PCB and leaving the FPGA coders wondering why something doesn't work right... How do we do that? Put something in there and see if it can communicate with the host properly.
PCB things that could come out wrong:
shorts
opens
bad layer stackup choice making signal integrity a mess
bad signal angles can affect signal integrity as well as manufacturability (DFM)
mismatched trace lengths can affect timing
Opens and Shorts should be easy to check with a multimeter and a lot of patience. Ive had to do that before for boards containing 8 sockets for 700+ pin chips. A board like we're discussing here may not be quite that bad.
Timing and Signal Integrity issues are harder to check without running something at real-world speeds. There are expensive simulation tools that can probably a PCB layout as well, but I'm not sure if anyone here has and knows them. (If anyone does, please talk about that, I want to learn!)
While the 060 bus probably isn't the best example of something requiring obsessive-compulsive signal integrity planning, it is at the low end of where you start to care. The general rule of thumb for this starts around 50MHz. Some say they've seen problems as low as 17KHz...
So, how does one prove this PCB before shipping, to ensure it's worth putting hte "real" FPGA coding effort into?