Use of clock in SDC style IO constraints for FPGAs
Consider the above case, where block is sitting outside FPGA and FPGA is feeding synchronous data to it via an output port. Here, the timing analyser won't be able to analyse the path Reg A --> a --> b --> Reg B. Because the clock freq. and the latency in the physical path outside FPGA is unknown to the tool. So we will define an output delay at the output port with respect to an imaginary clock clock_in_virtual called virtual clock. The output delay will constitute the route delay, delay of b and the setup time of Reg B (Delay of a, and clock-q delay of Reg A are already known to the timing analyser tool). We can model the time period and latency of the virtual clock. The tool can now analyse this path for setup-hold violations. Suppose we don't use virtual clock and we define output delay with respect to clock_in itself, such an analysis will be pessimistic for setup and optimistic for hold, because the capture clock latency is taken as zero. The same idea is used in input ports too. I hope this makes some sense to you now on why virtual clocks are used.

Case I: 

Here the design is source synchronous. Data out and clock out will change in known timing and the physical path is irrelevant because the route delays for both clock and data lines would almost be equal. This ensures best timing for setup and hold. Hence you can constraint output delay with respect to the generated clock to constraint the path. Virtual clock is not needed.

Case II:

To analyse this, both the clocks should be synchronous. You have to define a virtual clock that model the characteristics and relationship between ASIC clock and FPGA clock. The output delay is then constrained with respect to the virtual clock. The latency of the virtual clock is defined as the insertion delay/network latency of the clk_int.