Constraining external ripple clocks correctly on external pin (pad_io)

So yes, the generated clock will look identical to the sys_clk_90shift, because that's what it is based on and there is no -phase or anything. Remember that the clock launch and latch edges are "ideal", i.e. how the clocks are described in the .sdc before any place-and-route is done. If the time to get off chip was 2ns or 200ns, it wouldn't have any affect on where the launch and latch edges are.

My concerns is the last statement that the clock delay is moved into the data delay. The clock delay is still part of the latch clock path. So in the waveform view, the second dotted line labeled "clock delay" is what this time is to get off chip, and it starts from the latch clock time. I prefer looking at the Data Path tab, which has more information but is harder to visualize. If you look at the bottom Data Required Path window, it starts with thte Latch Edge, which is the same as the sys_clk_90shift clock. If you follow the location column, you'll see that clock is described as coming into the FPGA at input port fpga_clk, then goes through the PLL, global, DDR output, and finally out ssync_tx_clk. The User Guide briefly discusses this, but generated clocks should always start way back at the base clock, so it can account for any delays getting to the generated clock. Anyway, take a look at that and see if it makes sense. In the end, the Data Path tab has the Data Arrival Path, which is how long your data takes to get out, and your Data Required Path, which is how long the clock takes to get out. It also has the output delay subtracted from it. Hopefully that makes sense.