Non-optimal clock IOB/BUFGMUX placement correctable in software or hardware?
There are a few points that need to be clarified. The signal CLKOUT is what is commonly called "data clock". The data clock is basically a copy of clock reference (SCK) aligned with the data so it can be used to sample it.

As it was correctly pointed out before, the main issue is that the data clock wasn't connected to a clock capable inputs on the device and therefore there is no optimal way to route it into the clock network.

The reason why you're getting the timing issues is using this signal as a clock - do you use it along with @posedge (or rising_edge()) statement anywhere in the code? (eventually check your synthesis netlist in PlanAhead to see if there are flip flops clocked by this signal).

To answer your question - It all depends on what you expect - for example what rate are you trying to achieve. There are several options:


You can resample the CLKOUT signal by faster clock and use it as "data valid" strobe for latching the SDO. Note that even this may be tough if you plan to use +100MHz clock frequencies + I'd recommend to use 2-DFF synchronizer to minimize chance of metastability issues.
For lower rates, use the SCK for data sampling and ignore the CLKOUT completely. There you would sample the data on the rising edge of SCK as the data are presented on the falling edge (like in SPI applications). You can use oscilloscope to ensure that the SDO transitions do not occur too close to the edge of SCK.
If you plan to do new PCB revision anyway, use solutions provided above as temporary workaround and connect the CLKOUT_P/N to clock capable pins in the same halfbank as the SDO