Constraining ic delays

Yeah, you usually don't want virtual.

Most of the advantages of a virtual clock are secondary. Examples include:

- You can do stuff to the clock, like give it an offset, give it clock latency, etc. That being said, most people don't do this.

- You have a name for the external clock. This makes timing analysis easier. It's easier to identify it's related to I/O when you see one of the clocks called clk_sys_ext(or whatever name you give it). You can also do things like "report_timing -to_clock sys_clk_ext..." and get all outputs in that domain.

These are secondary since you may not use them. The only truly major one is that derive_clock_uncertainty should give a slightly different uncertainty to an external clock, so the timing is more accurate, but we're probably talking 20ps or less here.

As mentiond, your I/O is probably going to fail, and to be honest, might fail with a PLL, but should be closer.

Good luck. (I'm busy for the rest of the day so most likely won't be able to respond...)