Honored Contributor
Honored Contributorso in short, replacing an input clock with virtual clock does the following:
(1) adds default 20 ps as uncertainty between these two clocks (2) ignores input path for fmax analysis but not for slack This last item is really risky since it gives false pass on fmax. The advantage of virtual clock apart from this uncertainty issue is that you can shift it as appropriate relative to actual clock and use it as reference instead of say modifying delay values. I personally don't like the idea so far and would rather compute my delays. One such case raised here was when input data is clocked by a clock from fpga (opposite direction) then I can either make my calculations for delay to account for that or keep figures as they are but use virtual clock that is imagined to come with data at appropriate phase. I see this as confusing dual inverse and unnecessary approach.
