New Contributor
Super ContributorWow, that is a huge negative slack! I will look into why the clock skew is so high and start work from there first. 2.347 is too high.
Before that, check if the timing path is relevant as Timing Analyzer will analyze all paths. If not, set false path to tell the tool to exclude that path.
You may checkout the Best Design Practices for Timing Closure:
https://www.youtube.com/watch?v=UGGkKZylJBo&t=122s
p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 9/10 survey.
New ContributorIn fact, i have confirmed that the 0 ns routing delay has no connection with the huge slack earlier this evening. And now, i am more concerned about why the 0 ns routing delay persist... I have been stumped until now and didn't know what else to do...
New ContributorI designed a 16-bit full adder. Its routing delay between adjacent LABs is 0 ns as similar as the figure above. Both are wrong obviously, but what else can I do?
