Source Synchronous Input: Capture clock/Launch Clock analysis

Question

Hi, I have a Source Synchronous LVDS DDR input into a Kintex7, the launching clock is edge-aligned to the data and capture clock should capture on opposite edge (a launch on the rising edge should be captured by the falling edge). I have designed it to work at 100Mhz by compensating the clock insertion delay with a PLL (to save the MMCM for other purposes) using BUFH (the timing is not so tight to use BUFIO/BUFR). The PLL also centers the opposing edge on the data window by shifting -90°. Now the launching clock waveform is {5.0 0.0}, and the waveform generated by the PLL is {2.5 7.5}, this is reported correctly by Vivado. But when vivado analyses the setup path (I have set the proper set_input_delays) the following happens:
-Launching clock rising edge is correctly at 5.0ns at the input data PIN.
-Capture clock falling edge is INCORRECTLY 7.5ns AT THE CLOCK PIN.
What I don't get is: why Vivado, that recognizes that the capture clock is a generated clock by the PLL, uses the {2.5 7.5} waveform AT THE CLOCK PIN, and not at the ouptut of the PLL BUFH. I mean the falling edge of the capture clock should be 7.5ns at the output of the BUFH, not at the input to the FPGA (I see that the PLL correctly shifts this 7.5ns to be 5ns at the BUFH, but this is not what actually happens).
Doing the calculations manually the interface meets setup/hold with ease. I just want Vivado to make the proper analysis.

Answer 1

I am not 100% certain I followed all your logic, but I think the issue is that you aren't following how clocks are treated in SDC/XDC.
In Vivado/SDC/XDC, there are two separate concepts - clock phase, and clock propagation. For calculating how the launch/capture edge relationship is done, it is done based purely on phase - propagation does not factor in to it. Regardless of how they are generated, you have two clocks
  - the primary clock (generated by the create_clock command), which has a waveform of {0.0 5.0} (I am not sure why you say the opposite - {5.0 0} is not a meaningful representation in XDC)
  - the automatcially generated clock at the output of the PLL, which has edges at {2.5 7.5}. Its a little irrelevent how you defined it (with a +90 or -90 degree shift since the interface is DDR) - for the sake of argument, I will say its +90 degrees.
First, recognize that when you define a DDR input and use an IDDR to capture it, you are defining four static timing paths - you have two startpoints, one from your set_input_delay and one from your set_input_delay -clock_fall -add_delay. You also have two endpoints, one from the rising edge clock at the IDDR and one at the falling edge of the IDDR. This generates 4 paths
  a) rising input -> falling IDDR
  b) falling input -> rising IDDR
  c) rising input -> rising IDDR
  d) falling input -> falling IDDR
All four paths exist, and all are timed.
Now you need to understand the rules that Vivado uses to determine launch and capture edges. For this system, it is easy - the capture edge is always the edge of the capture clock that is the earliest that follows the launch edge. So in this case (assuming launching is {0 5.0} and capture is {2.5 7.5} will be
  a) rise at 0 -> fall at 7.5
  b) fall at 5 -> to rise at 12.5 
  c) rise at 0 -> rise at 2.5 (this is the most critical one, so a) is irrelevent)
  d) fall at 5 -> fall at 7.5 (this is the most critical one, so b) is irrelevent)
Now that it has determined the launch and capture edges for all the paths, it starts the propagation at the primary clocks. For your set_input_delay these are the clock pin. For the capture IDDR, the edge starts at the primary clock, propagates through the PLL (which adjusts it for clock propagation but not for the phase shift), and ultimately to the IDDR clock.
Now, in a real system this is what is going to happen - I am not sure why you think this is incorrect. If, however, there is some reason to believe that c and d are false paths, then you have to declare them as such (which will then leave a and b as the ones that remain). To do this, you would work with a virtual clock - you would define TWO clocks - the primary clock to the clock pin, and an idential virtual clock for your set_input_delays
# Create the real and virtual clock
create_clock -period 10 -name real_clk [get_ports clk_pin]
create_clock -period 10 -name virt_clk
# Define the input delay with respect to both edges of the virtual clock
set_input_delay <delay> -clock virt_clk [get_ports data_pin]
set_input_delay <delay> -clock virt_clk [get_ports data_pin] -clock_fall -add_delay
# Disable the rising to falling and falling to rising paths
set_false_path -rise_from [get_clocks real_clk] -fall_to [get_clocks virt_clk]
set_false_path -fall_from [get_clocks real_clk] -rise_to [get_clocks virt_clk]
Even though "real_clk" and "virt_clk" are different clocks all clocks in Vivado are related by default, so the fact that they have the same period and starting phase (which defaults to {0 5.0}) then they are effectively the same clock.
The reason for using the virtual clock is to make sure that if there is a rising to falling edge path inside the FPGA, you don't accidentally declare it false too - and these will happen between the IDDR and fabric logic (if it is in OPPOSITE_EDGE mode).
I hope this is clear... It can be a bit confusing, but it does make sense.
Avrum