TimeQuest Timing Analyzer[Setup slack analysis]

kaz asked: why are you avoiding the direct question of why not report the true micro Tsu param in the TQ report?

Answer: that's because in practice, the modeling tools do not really give you the theoretical micro Tsu. Primetime will tell you the relative signal race delay (constraint) between the clock and data pins. HSPICE sim depends greatly on the setup of the simulation but in the end it is the same.

The HW modeling teams provide these delays directly from the modeling tools and we use them.

slack = data required time - data arrival time

data arrival time = launch edge + longest path from clk to src.clk + micro Tco + longest data path to dst.d

data required time = latch edge + shortest path from clk to dst.clk - micro Tsu

So, in the above example, uTsu = -0.021ns (is negative on its own).

Timing analysis should always be done by looking at the the complete reg2reg transfer.

I have to ask: why does this matter? If the reg2reg delays are well correlated on mature FPGA products now, why questions about the sometimes arbitrary breakdown of the delays? Someone, somewhere will always be surprised by such a breakdown, because the expectations of the delays on the micro level differ. For example, in the TQ equations above I would prefer the micro Tsu to be added to and reported with the arrival time, not subtracted from the required time; that logically makes more sense to me, but it would not be prudent for me to change this in TQ reporting now; it would invert all the signs on the reported uTsu, but then the total slack calculation would amount to the same value.