Looking through your timing report, there is nothing that indicates a potential issue. Since you have a problem, this means that the scenarios that static timing analysis (STA) is checking are not covering the actual usage of your circuit.
Without any serious setup of STA, some common assumptions are that all inputs are valid by the time the clock rises, and that all states are known (meaning a logic 1 or 0). Immediately, the UUUUUUUU on bus3 looks very suspicious, and is a possible issue with initialization. In logic simulations, U implies that the line is either a 1 or 0, but a register driving it was not initialized properly. This could cause the simulator to give weird answers until all registers are loaded or reset. However, this problem manifests itself in later cycles after all registers have been initialized.
The other potential issue is bus1 starts in a high impedance state (ZZZZZZZZ). Considering that tri-state is not usually assumed in timing analysis, this is the most likely source of the timing discrepancy. Tri-state conditions must be carefully coded into your STA tool in order for them to be considered. This can be a very difficult task, and is prone to error (incorrect programming, missed cases, etc.). I believe that programming in tri-state delays would most likely give you an accurate STA result that should match your simulation.
However, tri-state is usually a bad choice for on-chip communication for both ASICs and FPGAs. This ambiguity of STA reliability, potential for bus contention, and the uncertainty of drive strength requirements make tri-state more likely to cause problems than fix them. The safer method is to use a multiplexor to select which source "talks" to the bus, or partition the design differently. I would only use tri-state when I know it will solve more issues than it can cause.
If you don't get a violating in timing analysis, but do in simulation, your timing analysis is likely incomplete. Revisit clock crossing and TIG (ignore) in particular. See Xilinx answer 38348 for more details on TIG.
Best Answer
Check the pinout file, make sure your inputs and outputs are where you think they should be.
Check your reset signal is connected, and the right polarity
Check the input clock has a clean waveform at the right frequency.
If it's still not working and you have internal clock multipliers/dividers (DCMs/PLLs), remove them and reduce your logic to something simple with a single clock just to get things going and build it back up from there.