When I started looking into doing the input for this project, one of the most common methods of dealing with the multiple clocks in SPI and User Logic land was to... ignore it completely.  By using the User clock to sample the changing SPI input signals, you can make a reasonable input stage to whatever you're making.

Of course, that method comes with a large downside, pointed out by Mr. Harry Nyquist (and contemporaries Shannon, Whittaker and Kotelnikov) - your maximum SPI speed is then limited to half of your user clock.  That might be fine for many applications, but rate limiting my SPI to 1/2 of the 25.125 MHz clock (12.5625 MHz) might become a major limitation - considering each send of 8 bits is just one pixel!

Here's my take on crossing the clock domain from SPI to user logic, which you can find at my newly published Git repository for VGAtonic:

https://github.com/dqydj/VGAtonic/tree/master/SPI_Demo

I hope you'll check my math, but my take on the maximum speed of this implementation is:

    (3*tUSER + 2*tSU)/7.5 ns

For a clock of 25.125 MHz (39.801 ns) and our chosen part the XC95144XL-10 (3.0 ns setup time), I get a maximum speed of 1/16.7204 ns, or 59.807 MHz.

That should cover even the Intel Galileo's SPI, which can run up to 25 MHz.

As for efficiency of flip-flops, here's what we lost in the tradeoff:

* 2 FFs for reset sync in user logic
* 1  FF for reset flag from SPI
* 2 FFs for register full
* 1 FF for register full flag from SPI
* 8 FF for the one-byte FIFO (philosophy: is that still a FIFO?)
* -1 FF, since we only need a 7 bit wide buffer for the SPI domain now.

* = 13 extra FFs to cross clock domain

Here's a picture of it working with 1 MHz SPI and a 14.318 MHz user clock on an XC95144XL (LEDs are tied to a register in the user logic domain).

Hope some of you find the code useful - and please let me know if you can shave off any more FF usage!