Electronic – Synthesis timing summary in Xilinx tool (ISE)

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.

According to the datasheet the hard multiplier takes between 4 and 5 ns to propogate from inputs to outputs in combinational mode. You'll lose a few more 100s of ps getting to and from the multiplier to the rest of your logic. If that's fast enough, then just make use of it.

If not, build your LUT-based multiplier by just writing some code with the * operator in it, synthesise it, place and route, and see if that's fast enough. You may needs an attribute to force it to not use the hard multipliers (see the MULT_STYLE attribute in the XST manual). You could even try just forcing a single LUT-based (non-constant) multiplier with that constraint and see what the result is - that's a very quick test.

Only if those fail should you go down the route of hand-building a LUT-based structure - and even then only if you've looked at the output of the synthesiser and are pretty sure you can beat it for some reason. The synthesisers have been tuned to work out constant coefficient multipliers very well in my experience - I doubt coregen will gain much.

Wet finger estimate: A LUT delay is ~0.7ns. Assuming routing delays are of a similar magnitude, you can afford a chain of only 3-4 LUTs in the delay of the hard multiplier. It seems unlikely to me that you'll achieve what you need in that depth of logic.