IOPLL Source Synchronous Compensation Issue? -- Arria 10

Question

I have a design using a source synchronous input and I am generating the latch clock from an IOPLL in source synchronous compensation mode. The description of that mode states:

"If you select the source synchronous mode, the clock delay from pin to I/O input register matches the data delay from pin to I/O input register."

Based on that, I'd expect the latch clock delay to be close to the data path delay. Unfortunately, TimeQuest does not show this. It shows the full data delay, with the latch clock edge occurring at the PLL phase offset value.

The input device is an ADC w/ edge-aligned, double data rate, outputs. All of the inputs are LVDS.

The ADC output clock is 250 MHz (4000 ps period).
The data skew values relative to the DCO are: min: -160 ps, max: +360 ps.
The IOPLL is setup in source sync compensation mode to generate a 250 MHz clock w/ a +90 degree (1000 ps) phase shift.
The data lines from the FPGA pins go to IBUFs and then to DDIO_IN registers that are clocked by the PLL output signal.
Using Quartus Pro 17.0.2, build 297
I've read app note AN-433 (May-2016), and "Source Synchronous Timing" by Ryan Scoville.

This is an edge-aligned, double data rate source synchronous case w/ the PLL using a +90 degree phase shift.

When analyzed, the data arrival path shows a typical result of an IOB delay(500 ps), and the data delay from the IOB to the register(850 ps). So the overall data delay is 1710 ps from launch clock to data arrival.

The data required path shows the IBUF delay, routing delays to the PLL, and a number of internal PLL delays. It also shows a compensation block that compensates for the majority of the delays in the PLL. This results in the latch clock arriving at 1000 ps - the PLL phase shift amount.

The source synchronous compensation behavior of the PLL: "clock delay from pin to I/O input register matches the data delay from pin to I/O input register" does not seem to be evident. It looks like it is running in "normal" compensation mode, where the PLL compensates for the delay of the internal clock network used by the clock output.

All of the IBUFs, and DDIO_IN registers are in the IOBs (typically col X148 in this part: Arria10 10AS066N3F40E2SG)

Constraints:

250 MHz virtual clock for the ADC
250 MHz clock for the ADC DCO clock input pins
Calls to derive_pll_clocks and derive_clock_uncertainty after the clock creation lines
Min and max input delay constraints on the input data lines for the rising and falling edges referenced to the virtual ADC clock.
False paths for the setup fall_to/rise_from the virtual and fall_from/rise_to the PLL output clock
False paths for the hold fall_from/rise_to the virtual and rise_from/fall_to the PLL output clock

Questions:

Why does the source synchronous compensation mode not seem to do what it states? (why does it appear that the data delay from pin to register is not compensated for by the clock?)
Why does the data path delay increase proportionally when I adjust the PLL phase shift value to account for the negative slack in the original design?
Am I misunderstanding something regarding the PLL, source sync compensation, etc?
Am I missing something in the constraints, etc. that is preventing this from working?

Thanks,

--Mike V.

altera_forum · Answer

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.

altera_forum · Answer

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 ---

altera_forum · Answer

In PLL source synchronous mode I expect that changing PLL phase will not work as expected since the fitter tries to keep data/clk phase same at any pll phase.

I suggest you try PLL in normal mode then adjust its phase.

altera_forum · Answer

If that is the case, then it removes the majority of the usefulness of source synchronous mode. I would expect that mode to instruct the fitter to keep the data/clk phase of the internal, zero phase shifted PLL output to be the same. That allows the phase shift parameter to control how far the sample clock edge is into the data window. If the fitter keeps the data/clk phase the same using the the phase shifted output, then there is no way to adjust the sampling edge for an edge-aligned, source sync input. This is counter to the information in AN-433 "Constraining and Analyzing Source Synchronous Interfaces" and "Source Synchronous Timing with TimeQuest" - by Ryan Scoville.

If the PLL is in normal mode, then there is no compensation to compensate for the data/clk path skew. It now has to be done manually by adjusting the PLL phase and any IDELAY blocks in the data path.

--- Quote Start ---

In PLL source synchronous mode I expect that changing PLL phase will not work as expected since the fitter tries to keep data/clk phase same at any pll phase.

I suggest you try PLL in normal mode then adjust its phase.

--- Quote End ---

altera_forum · Answer

--- Quote Start ---

If that is the case, then it removes the majority of the usefulness of source synchronous mode. I would expect that mode to instruct the fitter to keep the data/clk phase of the internal, zero phase shifted PLL output to be the same. That allows the phase shift parameter to control how far the sample clock edge is into the data window. If the fitter keeps the data/clk phase the same using the the phase shifted output, then there is no way to adjust the sampling edge for an edge-aligned, source sync input. This is counter to the information in AN-433 "Constraining and Analyzing Source Synchronous Interfaces" and "Source Synchronous Timing with TimeQuest" - by Ryan Scoville.

If the PLL is in normal mode, then there is no compensation to compensate for the data/clk path skew. It now has to be done manually by adjusting the PLL phase and any IDELAY blocks in the data path.

--- Quote End ---

Well I can't speak for Altera PLL modes. But following definitions of source synchronous modes it becomes a guess what is exactly the effect of PLL non-zero phase in this mode.

I read several definitions of this mode, some weird but this one makes sense, just :

"Source-Synchronous mode—maintains the same phase relationshipfor data and clocks that arrive at the same time at the clock and dataports of any I/0 element (IOE) input register"

I think the best thing is to experiment it.

Forum Discussion

IOPLL Source Synchronous Compensation Issue? -- Arria 10

6 Replies

Recent Discussions

FPGA issue on electronic board

MAX10 RSU upgrade succeeds, but device boots Factory image instead of Application

Arria 10: Remote Update Factory Fallback won't work & Watchdog does not trigger

Max10 FPGA Programming with .pof file

About ALTIOBUF simulation