Cyclone V: A PLL with multiple clocks and independently adjusting phase of a clock

Surely I can't be unique in being the only guy trying to shift the clock phases from a PLL.

Has anyone else successfully shifted the phases of multiple clock from a single PLL?

I increased the number of outputs to 8 to check which clock output had a phase-shift for which value of cntsel[4:0]

Where:

cntsel[4:0] = 0, outclk0 phase undergoes a change
cntsel[4:0] = 1, outclk4 phase undergoes a change
cntsel[4:0] = 2, outclk2 phase undergoes a change
cntsel[4:0] = 3, outclk5 phase undergoes a change
cntsel[4:0] = 4, outclk4 phase undergoes a change
cntsel[4:0] = 5, outclk3 phase undergoes a change
cntsel[4:0] = 6, no clock changes phase
cntsel[4:0] = 7, no clock changes phase

I note a throw away comment in AN-661 (Implementing Fractional PLL Reconfiguration with
Altera PLL and Altera PLL Reconfig IP Cores)

"When the PLL has two clocks with 0 degree initial phase shift between the clocks, the Fitter synthesizes
away the second clock automatically. To prevent the clocks from merging, Altera recommends
manually performing location constraint for each of the PLL output counters which share the same
frequency and phase shift."

After looking at the report file I can confirm each of the output counters (PLLOUTPUTCOUNTER_X54_Yy_Nn) are different for all outputs. Implying the clocks are not merged.

Any help would be most welcome.

We sincerely apologize for the inconvenience caused by the delay in addressing your Forum queries. Due to an unexpected back-end issue in our system, your Forum cases, along with others, did not get through as intended. As a result, we have a backlog of cases that we are currently working through one by one.

Please be assured that we are doing everything we can to resolve this issue as quickly as possible. However, this process will take some time, and we kindly ask for your patience and understanding during this period. The cases will be attended by AE shortly.

We appreciate your patience and understanding, and we are committed to providing you with the best support possible.

Thank you for your understanding.

Hello,

Apologies for the delay and inconvenience caused. I can now focus for your issue.

Based on the parameters you provided, the VCO effective frequency is 450MHz, so there are 8 VCO periods for each 56.25MHz output clock. That means there are 64 phase shifts available for each of those 56.25MHz output clocks to roll through one output clock period. I say “effective” VCO frequency because in reality the VCO is running at 900MHz. 450MHz is lower than the supported VCO operating range, there is a post scale VCO counter that is often used to support lower frequencies, so it divides the VCO frequency in half. The compilation fitter report – PLL usage/summary will show the value of this post scale counter. For phase shift calculations, you use the VCO frequency reported by Quartus, which is after the VCO post scale counter, so 450MHz in this case.

You may be able to see a change after several phase shifts, but for accurate phase measurements you should route the clocks to I/O pins that can be scoped on the board. The phase shift resolution is 270ps, and you are sampling signal tap at a 4.4ns period, so you would need over 16 phase shifts to see a change in signal tap.

When implementing dynamic phase stepping, you can specify either an individual output clock, or all of the output clocks depending on what you drive to the cnt_select port of the PLL IP. Table 4 of AN 661 shows how to set the cnt_sel port. A value of 11111 shifts all of the output clocks simultaneously.

Let me check this and get back to you.

Hello,

I have found out that way back you had to address the physical counter locations, this was prior to version 13.1 as stated on page 14 of AN 661. Users had to look at the PLL usage report to see where there counters were physically placed and then address those locations on the CNTSEL ports to phase shift those counters. It was really confusing.

Then starting in 13.1, users were able to target the counters as they set them in the RTL, so that’s the “logical counter” ordering. If the clock output is on C0 in the IP, then the customer sets CNTSEL to 00000 to phase shift that clock.

I have a chance to connect with other FAE and they recently talked to a Cyclone V customer using dynamic phase shifting on multiple clock outputs and it was working fine. Next steps for you is to verify the version of Quartus and if it’s prior to 13.1 (not likely), then that could explain the problem. If it’s a current version, then the next step would be to confirm the CNTSEL ports are connected as expected.

Regards,

Aqid

The only way I can think that the same clock would get affected by more than one selection of cntsel[] would be if some of the cntsel bits are tied to a static value by mistake. The only exception is when all of the cntsel bits are high, then all of the clocks will be phase shifted at the same time. Maybe you can put the cntsel bits in signal tap and verify they are toggling as expected?

We are not aware of any examples showing how to make the location assignments for the PLL counters. I have made PLL location assignments before, but that used post-compile node names to lock down PLLs to specific locations. In this case, you need pre-synthesis or design entry names to make the assignments. I suggest trying to re-create this in some fashion in Quartus – create a simple design with a PLL and duplicate the frequency and phase on multiple output counters. Then see if they get synthesized into one clock.

If they do, then try making the location assignments to the PLL output counters. I used Design Entry all names as my filter in the node finder. Make it a location assignment, and for Value you need to specify PLL Output Counter as the element by double clicking the 3 dots. Then you have to figure out the x, y, and z locations. I don’t think we document locations to that detail, I think we only show locations for the PLLs. You can probably find x,y,z coordinates in the chip planner or start with a successful compile and check the PLL Usage Summary report to see one valid PLL counter location, then use that as a reference to make the assignments.

The hardest part is getting the right nodes, you need to be sure the output clocks are children of a PLL instance in the node finder.