12-09-2019 11:04 PM - edited 12-10-2019 04:08 PM
Can you explain why the clock path skew is negative?
I want to know it.
I want not to have negative slack and to know the reason of the negative clock path skew.
Can I change the negative clock path skew to positive clock path skew?
If you want to have my design source, I will attach it.
partial source code as follows.
12-10-2019 09:49 PM - edited 12-10-2019 09:50 PM
The clock skew is Destination (DCD) - Source (SCD).
If the SCD is larger than DCD, you get a negative clock skew. It is not absolute value.
There are formula details in your screenshot for the clock skew calculation.
You can refer to UG949 about the timing violation root causes and correspoinding solutions.
12-10-2019 09:51 PM
12-23-2019 12:24 PM
More specifically, this is an output path of the FPGA.
The source clock starts at a "clock" object outside the FPGA (defined with a create_clock), comes in through an IBUF, and some other clocking (we can't tell what since you didn't post the complete schematic or report), but either a regional clock buffer like a BUFIO/BUFR, or a global clock buffer (BUFG) with or without an MMCM between the IBUF and the BUFG. The clock then fans out on a dedicated clock network before ultimately reaching the startpoint of the static timing path - the FDRE that drives the startpoint. This is the source clock delay (SCD).
The endpoint is an output port. The only timing associated with it is the set_output_delay on the output port (which appears to be 0) and is relative to the same clock defined on the input port (the same create_clock -name clk). Thus the clock "clk" goes "directly" to the endpoint, which is the set_output_delay command - thus it has no destination clock delay (DCD). Since the clock skew is DCD-SCD, and the DCD is 0, the clock skew is negative. This is true for all paths that leave the FPGA.
Ultimately, though, what this is telling you is that you cannot synchronously get through the FPGA in 5ns (i.e at 200MHz). What you are effectively asking for is for a 5ns maximum delay from the time the clock arrives at the clock pin of the FPGA until the output appears on the output pin of the FPGA. This is too fast - this must go through (I will assume BUFG clocking)
So you add all this together and it clearly cannot be done in 5ns, which is what you are asking for with your (presumably) create_clock -period 5 and set_output_delay 0.