Forum Discussion
When I/O paths are constrained with set_input_delay, set_output_delay, or set_max_delay/set_min_delay, report_timing works on I/O paths the same as on internal paths except that for a device pin in the -to or -from field you use get_ports instead of get_registers. You can use get_keepers for either device pins or registers (a keeper is either a port or a register), so there's no difference in I/O-path reporting and internal-path reporting if you use that collection. You can report between I/O and internal clock domains if you use a virtual clock for the set_input/output_delay -clock field (the recommended practice except for source-synchronous outputs). For example, an input path could be reported with -from_clock my_virtual_clock_for_the_port -to_clock my_real_clock_for_internal_register.
If you use set_max_delay/set_min_delay without set_input_delay or set_output_delay, then the port (device pin) will have a clock called "na" (or maybe it's "n/a"). This is a special case where you don't have to have an user-created clock for the thing being reported with report_timing.