01-13-2018 02:01 PM
I wanted to test Vivado Constraints Wizard so I have written simple entity that xors two 32 bit long vectors in synchronous manner.
I have carried out timing analysis for 100 MHz clock and to my surprise it failed to meet not so rigorous timing constraints.
After checking violating paths it turned out that Clock Path Skew for some input flip flops equals 4.443 ns.
I do not understand what is the reason of such high value for so simple design. Can anyone explain this?
I attach archived project for reproducing the results.
01-13-2018 02:30 PM - edited 01-13-2018 02:30 PM
Since it meets timing for me, my guess is you're looking at the post synthesis timing report instead of the post implementation timing report. The post synthesis timing reports are estimates, and often I've found post synthesis holds are estimated to fail. However, during implementation, the tools do a hold fix, and this almost always fixes hold issues in synchronous designs. Consequently, I usually ignore post synthesis hold estimate failures.
01-14-2018 11:35 AM
For an input path, it is expected to have a large clock skew (and you have to design the interface to accommodate it).
A static timing path starts at a startpoint and ends at an endpoint. Each of these has a clock.
The startpoint of an input path is the "set_input_delay -clock <clk>" command. Unless you have used a set_clock_latency command, the clock insertion to the startpoint is 0.
The endpoint is a flip-flop inside the FPGA. Assuming <clk> is connected to the port of the FPGA, it has to go through (at least) the IBUF to get into the chip, some routing to a clock buffer, go through the clock buffer, and then go through the clock network to the clock pin of the cell capturing the data. Therefore the clock insertion is the sum of all these delays.
The clock skew is the difference between these. Since the source insertion is 0, the skew is expected to be relatively large.