Cyclone 10 GX Clock Skew from the Same IOPLL

[trchen]

Background:

I'm doing some signal processing design with 300MHz main clock, but part of my pipeline will require to run all M20K at 600MHz to have enough bandwidth, so I was trying to implement a 1:2 and a 2:1 gearbox to raise the clock speed during the critical path. However the clock skew makes CDC very challenging.

My clock setup:

I have external 100MHz(clkin) feed into IOPLL0 to generate quality 100MHz(refclk), then feed that refclk into IOPLL1, running direct compensating mode with 600MHz(clk_2x) and 300MHz(clk) output. Both outputs distributed by GCLK.

As the faster clock is 600MHz, I have about 1.666ns timing budget. The estimated skew from within the IOPLL1 is around +-0.2ns, which matches the IOPLL jitter performance specification. However the estimated skew from clock path is around +-0.5ns. These alone ate up pretty much all the timing budget.

Does that sound about right or the Timing Analyzer is being too pessimistic? I'm a little bit surprised because both clocks are generated from the same IOPLL and feed into GCLK network from the neighbor CKLCTRL cells.

Alternative setup:

I also tried using IOPLL's normal compensation mode. So that I have:

100MHz(clkin) --> IOPLL0(direct compensation) --> 300MHz(clk) --> IOPLL1(normal compensation) --> 600 MHz (clk_2x)

But then I'm seeing even more clock skew in 5ns range!

Question:

* Where can I find the specification on the GCLK propagation / skew characteristics?

* If the variation between individual GCLK nets is indeed that much different, is there a way to somehow generate very well aligned (< 0.2ns skew) synchronized clocks?

* How would you program 1:2 2:1 gearboxes that works at 300MHz:600MHz?

[sstrell]

Cyclone 10 GX cannot even run at 600 MHz, up to 300 MHz:

https://www.intel.com/content/www/us/en/docs/programmable/683485/current/device-overview.html

[trchen]

That is not true. Even Cyclone V can do better than that. Cyclone 10 GX could clock up to fMAX = 644MHz, limited by minimal pulse width: https://www.intel.com/content/www/us/en/docs/programmable/683828/current/clock-tree-specifications.html

That said, it is true that the number of logic layers would be severely limited at that frequency, the design will need to be heavily pipelined. That's why I target my design at 300MHz with only the memory intensive part running at 600MHz.

I did try to fiddle a few settings afterwards. I realized that my Timing Analyzer calculated for both the fastest and the slowest speed grade. It was a mistake as I don't really intend to use slower speed grade devices. My product is intended to be used indoor with good thermal solution. After changing the settings to consider only the fastest speed grade I was able to get the 600-->300 CDC to work. Still need to add some delay to satisfy hold, but at least now I have plenty time margin for setup.

[Ash_R_Intel]

Hi,

First thing I would suggest is to reduce the number of IOPLL in path. This will reduce the jitter introduced by the PLL itself. Each IOPLL in Cyclone 1 GX can generate up to nine output clocks at the same time. You can generate 100MHz, 300MHz and 600MHz from one IOPLL only. Use the Normal compensation mode.

For the CDC, you should always use the domain crossing techniques such as double flop synchronizer or pulse stretcher or FIFO etc. to make sure that the crossing is correct. Other way that you can use is to define False Path between the two domains. Hope this helps.

Regards

[Ash_R_Intel]

Hi,

Are there any further queries on this? Can this case be closed?

Regards

[Ash_R_Intel]

We did not receive any response from you to the previous answer that I have provided. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you