Electrical – Edge aligned Source synchronous outputs

There's always some propagation delay through the flip-flop. It's often called "clock-to-Q" delay.

That means your inputs are captured on the edge, and you outputs change on the same edge, but just a few nanoseconds later. This few nanoseconds delay is enough (if your flip-flops are designed with "zero hold time" as they are in most FPGAs) that the changes don't affect any downstream flip-flops until the next clock edge.

In functional or RTL simulation (which is probably what you're doing to generate your result) the delay won't be simulated as lasting nanoseconds. In VHDL, it will be a single delta cycle of the simulator clock, which is technically no time at all. This makes it impossible to see the delay in the simulator output. Nonetheless for the simulated-as-ideal flip-flops, it is enough that the output changes don't affect downstream flip-flops.

If you do post-place-and-route simulation, it should be able to include appropriate delays so you see these effects clearly, at the cost of increased simulation effort.

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.