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

[Mikexx]

I have a PLL with 5 output clocks. 

4 are at 56.25MHz and a fifth is at 225MHz that is used to sample the other outputs to confirm any phase shift in Signal Tap.

The tick-box for "Enable access to dynamic phase shift ports" is ticked.

PLL Mode: Integer-N PLL

Reference Clock Frequency 50.0MHz

Operation Mode: direct

M-Counter: 9

N-Counter: 1

C-Counter: 8, 8, 8, 8, 2 (for each outclk respectively)

Some observations:

The datasheets say that the phase can be incremented in clock period/8. The actual shift seems to be a fraction of this.

As the attached waveforms suggests:

When there is an increment in phase, it seems that other clocks move in phase too, not just the selected clock output.

Why is this happening, and how do I shift the phase of clock independently?

[FvM]

Hi,
I can't recognize that more than PLL output is phase shifted in the signal tap recording. With countsel=1, only C1 phase should be affected.

Phase shift increment is 1/8 of VCO period, usually less than output clock period.

[Mikexx]

Many thanks for your reply. 

Yes, the phase increments are associated with the VCO period, so where the clock is divided by 8 from the VCO frequency I would expect 64 counts for a full clock cycle for outputs 0-3. I can confirm 32 counts gets me inverted clocks.

Please have a look at the area highlighted in the attached diagram. I would expect only output 1 to change from a change in C1. 

In practice I hope you can see that clock outputs 0, 1 and 3 change. I'm using clock output 4 as a reference so it is always possible it is this clock 4 and clock 2 are actually the ones that have changed phase.

Either way the PLL isn't behaving as expected. Or it isn't clear which C-clock counts tally with which clock output.

[Mikexx]

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?

[Mikexx]

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.

[Mikexx]

If I move the clock I use on the PLL IP module outclock ports the following change:

cntsel[4:0] = 3, now no change in any output clock phase

cntsel[4:0] = 7, outclk5 phase undergoes a change

It seems the optimiser/synthesiser regarding the PLL IP module moves ports around inconsistent without moving cntsel[] in sympathy.

Is there a way of stopping this and keeping the outclock ordering without the compiler moving ports around?

[AqidAyman_Intel]

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.

[Mikexx]

Any chance of an indication of a timescale for resolution?

At the moment I am looking at Infinix as their Trion series have a hard LPDDR3 interface and a more active forum. I have already purchased a development board.

[AqidAyman_Intel]

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.   

[Mikexx]

Yes, you're entirely correct in that I have to perform multiple phase shifts (32) to invert a clock waveform. This is as expected and described in my post on the 25th September.

However, you seem to be answering a completely different question to the one posed, ie the predictability of which PLL clock is shifted with cntsel set to a known value. My post of the 6th October illustrates the issue, where if I should increment the phase with multiple phase shifts with cntsel[4:0] set to a specific value and noting which of the output's phase changes in sympathy.

For clarity I repeat below:

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

This is the issue at hand and look forward to your reply.

[Mikexx]

---

@AqidAyman_Intel wrote:

Okay, this sounds more like an RTL level issue rather than anything with the bitslip and LVDS IP. Maybe check the RTL viewer to see if synthesis is fanning out the bitslip_pulse signal to each bit of the bitslip control in the LVDS SERDES IP.

---

I'm not using any SERDES IP.

While I might agree an RTL investigation will prove the point, the issue is that this is dependent on synthesis, where there is no obvious way to lock down the relationship with cntsel[] and the clockout signals in the PLL IP.

[AqidAyman_Intel]

Let me check this and get back to you.

[Mikexx]

---

@AqidAyman_Intel wrote:

Let me check this and get back to you.

---

Many thanks. I would appreciate this.

[AqidAyman_Intel]

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

[Mikexx]

Many thanks for the reply. I'm using Version 20.1

While I could check the RTL more than one selection of cntsel[] seems to affect the same clock. Furthermore there are some output clocks that do not change independent of whichever cntsel[] is active.

[AqidAyman_Intel]

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? 

[Mikexx]

I can confirm I have used signal tap to verify the cntsel[4:0] bits within the PLL module, the horses mouth so to speak,  and they are set as expected.

The cntsel[4:0] are not static, but it seems that synthesis will move the bits to suit.

Driving gignals are confirmed as per "Figure 5: Waveform Example for Dynamic Phase Shift with Altera PLL IP Core" in "Implementing Fractional PLL Reconfiguration with Altera PLL and Altera PLL Reconfig IP Cores". A waveform is attached to an earlier post.

What is especially curious is that more than one cntsel[4:0] value will affect the same clock. There is a throw away mention in the above document:

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

How would I do this? Are there any examples?

[FvM]

Hi,
I know that Quartus fitter changes PLL output order in some cases. As far as I remember, this could be prevented by setting an option.
I wasn't yet aware of PLL outputs being merged under circumstances, but I see that it's mentioned in AN661. I consider it as a bug for PLLs with dynamic phaseshift enabled.
I don't understand however how a PLL counter can react on multiple cntsel values. As far as I understand, cntsel has a fixed relation to actual hardware PLL counters.
Can you post a design example that demonstrates the observed effects?

[AqidAyman_Intel]

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. 

[AqidAyman_Intel]

Hello,

Do you have any updates on this? Or can I close this thread?

Thank you for your reply.