Compensating for clock netwrok delay

[PRega1]

Hello, I have a design (5CGXFC5C6U19I7) receiving a source synchronous DDR data interface from an ADC. The input clock is connected to a global clock input (CLK6, unfortunately not a DQS). The input clock is routed to DDIO input pads.

The clock network delay is a little bit to high and the delay variation between worst and best condition is too large for the data window validaty (talking about less than a ns, but still not good).

I have tried to insert a PLL on the path to compensate for the clock delay and its PVT variations. Quartus generates the following path: input pad -> fractionnal PLL -> clock control block -> buffer (when no PLL, I have the clkctrl block as well).

The clock control and the buffer delays are not compensated. The PLL does align its out to the clock input though. But the clckctrl and buffer are still in the path and tehrefore the timing constraints cannot be made.

I have been trying various PLL mode, source synchronous being my first choice.

Is there any way to :

• get rid of the clkctrl block in the middle ?
• constrain the PLL to insert the clkctrl and buffer in the feedback path of the PLL ?

Please note that I have tried the PLL modes that have a feedback input pin, but it fails as Quartus seems to expect the feedback to be connected to a input buffer (at least, that is my undertstanding of the error message).

Any hints would be appreciated before having to make a board run 2 to connect the clock input to a DQS input.

Thanks

Pascal

[Kenny_Tan]

How fast you are running towards the DDIO?

[Kenny_Tan]

basically, if you are running more than 200Mhz. You will have to use altdq_dqs.

you can refer to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altera_phylite.pdf

[PRega1]

Hello, clock frequency is 300MHz, or 600MT/s.

Tuning D0/D3 delays in DDIO input pad does not help.

I understand your point and I know that I would be better off if the clock signal was connected to a DQS input. Can the PHYLite work with a global clock instead ? Now rather than waiting for a re-spin of the HW, i am looking for a way to compensate for the clock network. Hence my question.

In "Normal Compensation" mode, I was expecting the PLL to compensate for the delay. However, Quartus introduces a CLKCTRL and a buffer (the clock tree) that are not in the PLL feedback. Is this normal ? Why ? If not, is tehre a way to workaround this ?

Pascal

[SreekumarR_G_Intel]

Hello , sorry for late message .. i caught into other stuff...Can I know update on the same ? If you still having the issue can you let me know ?

Thank you ,

Regards,

Sree