New Contributor
Super ContributorVery odd. What do your timing constraints look like? Perhaps something in the SDC is causing the issue though the issue with the virtual pins doesn't point to that.
Can you generate a timing report with the "show routing" option turned on? That breaks down the wire connection into its individual elements. If you have no other placement assignments, the route must be snaking all over the place adding to the delay, but there's no explanation as to why that may be happening. The show routing option might help figure it out.
What does the hold timing look like on the same path? Perhaps you have optimize hold timing turned on which causes the fitter to intentionally add additional routing on the path to help improve hold timing requirements (though this seems super excessive for that feature). Try turning that off globally or with an assignment.
FYI: I don't think power tiles are thing in A10, so the assignment you mention doesn't do anything.
New ContributorThanks a lot for this answer, it finally led me to the answer:
So basically there was the intention to constrain the IO with set_min_delay 0 and set_max_delay 10. The intent was to have a path from IO to the registers which was at most 10ns long. But that is not what these set_min_delay and set_max_delay constraints are doing. They are instead added to the clock insertion delay and the actual delay has then to be within <clockinsertiondelay>+0ns and <clockinsertiondelay>+10ns. In the past, when fitting for stratix 5 this seems to not have been a problem. But for Arria 10 the fitter was unable to meet both hold and setup requirements of the beforementioned constraints. It seems to fix the hold part by inserting a massive large long routing path, but then is unable to fix the setup part and gives up, the STA reporting the huge long path and setup violation.
If you do report hold timing for the same path in that case you get a 5ns positive slack, while the setup violation is only like -3ns. I was confused by this, but it seems that the fitter is most likely considering on chip variation and calculating worst clock path against best data path (for hold) and best clock path against worst data path (for setup), so the hold slack can not be directly used for fixing the setup violation.
Anyway, by replacing the set_min_delay and set_max_delay with set_net_delay constraints (which actually match the intent of the original constraints) for the IOs the problem is finally solved and we can proceed looking for the right FPGA for our next project.
Thank you very much for your answer, sstrell! Learning both that there is an option to globally deactivate hold fixing and to show the actually routed path was very helpful
The remaining problem is that set_net_delay causes the IOs to be still reported as unconstrained. But we will discuss on our side here how to constrain these paths and not have them reported as unconstrained.
Super Contributor
