IOPLL Source Synchronous Compensation Issue? -- Arria 10

I agree with your understanding of the source synchronous compensation in the IOPLL as well. I would expect that the timing relationships between the ref clock and data lines at the pins should be maintained between the non-shifted (zero phase) PLL output clock and the data lines at the first set of registers. This should include delays through the DIFF_IBUFs and routing delays between the IBUFs and the DDIO_IN registers.

As for clock optimization vs. a set of input lines, the -max input delay number gives the worst case setup time constraint for the input data signals, so I'd think that value, plus the worst case IBUF + data routing delay would be the value to compensate for. Also, the tool will adjust the delay chains to minimize the skew in the data lines too. Those can be examined in the Fitter > Route State > Delay chain summary report.

The problem occurs when I try to adjust the PLL output clock phase to account for the negative slack initially reported. So, for example, I build the design w/ the IOPLL in source sync mode and a + 90 deg phase shift (delay of 1000 ps) so the latch edge is centered in the data window. The tools report a negative setup slack of 370 ps. The worst case path has an IBUF delay of around 518 ps, and a routing delay of 852 ps. I increase the phase shift to 1400 ps. This should be enough to accommodate the -370 ps of slack reported the first time. I run the tools again and see that the routing delay has increased by 1000 ps!! If I check the delay chains for the data path, they're all now 10 and 11.

It seems like I'm missing a constraint, but I cannot figure out what it is. I've tried multi-cycle paths, and they do not seem to be the solution.

At this point, I'd just like full control over the delay chains and routing used so I can finish the design.

--- Quote Start ---

Your setup of timing looks sound to me. What I may differ is the understanding of source synchronous mode for PLL. To me it means the relationship between data and clock at pins is maintained when arriving at io registers.So in your case data is edge aligned but obviously you tell the tool that through set_input_delay(max & min) and I assume then this max/min will be taken into account by the fitter.

edit: notice with several data lines but one clock then compensation has to be optimised or based on a selected line.

--- Quote End ---