Electronic – FPGA output pin high capacity load

Your FPGA design is using the fall signal to clock out data on MISO. But its probably using rise to clock data in from MOSI. The microcontroller will do the same thing. It knows the falling edge of SCLK is telling the slave to change the MISO line, so it won't clock that data in until the rising edge of SCLK. You have to be sure that your FPGA clock is fast enough that even with two clocks delay on detecting the falling edge, it will be presenting valid data to the microcontroller by the time of the rising edge.

This arrangement not only gives your slave device some leeway in how quickly it responds to SCLK, it also allows for some uncertainty about whether the SCLK or the MISO traces or cables are the same length. By sampling MISO in the middle of its valid period, you allow the SCLK transmission delay to be either longer or shorter than the MISO transmission delay. Another way to say this is that the SPI receiver is designed with balanced set-up and hold times.

This is different from the way you normally arrange data transfer between gates in your FPGA. There, your flip-flops generally have zero hold time. That is, they clock old data in on the same edge when the upstream flip-flop is changing its output state. They can do this by delaying their data inputs just a little bit more than their clock inputs, and its an arrangement that generally gives the best possible maximum clock rates while still being relatively easy to guarantee the timing with automated tools.

The balanced set-up and hold arrangement on SPI can't achieve the same high clock rates as the interfaces within the FPGA, but it also doesn't require anywhere near as careful management of the propagation delays between the sender and receiver.

I assume you're looking at "Read Cycle No. 1". Yes, that's the correct interpretation of the datasheet.

Now you have to worry about the FPGA side, which has its own setup/hold times and delays. If you have enough frequency headroom on the FPGA you don't need to worry much about this beyond basic timing constraints; the tools will abstract things away to some extent. But eventually you will find something that needs to be micromanaged, so it helps to start thinking about these issues now. I suggest completing the HDL side of your project (read those timing reports) before finalizing your hardware design.

Operating an external 100 MHz interface on budget FPGA families is probably going to require some care. You can start low and slow, though, like a few tens of MHz, before really getting your feet wet.