Clock Phase Shift in ALTPLL IP

Hi Guys,

Could you tell me how much clock phase shift should I input in the ALTPLL IP for a particular PLL?? How can I calculate the clock phase shift of the PLL?? How can I measure the phase shift??

sreevenkjan said:

Could you tell me how much clock phase shift should I input in the ALTPLL IP for a particular PLL?? How can I calculate the clock phase shift of the PLL?? How can I measure the phase shift??

Click to expand...

Read the user's guide for ALTPLL.

K-J said:

Read the user's guide for ALTPLL.

Click to expand...

Yes I did refer the ALTPLL Megafunction guide but unfortunately there is not enough information on how to set the phase shift and all how to measure them. I tried measuring the phase shift between the 2 clocks of similar frequency which I generate i.e 1 clock goes to the sensor and the other I use it intern in my FPGA to simulate the sensor functioning. However they were having 0 deg phase shift. How would you measure the clock phase while designing the ALTPLL block??

The PLL with default settings is designed to remove skew between the input clock and the output clocks. Maybe you don't understand what the PLL is supposed to do?

Try using no PLL and run the signals directly into the chip or set the PLL to "No Compensation mode" so it doesn't try to modify the skew between input and output clocks.

sreevenkjan said:

Yes I did refer the ALTPLL Megafunction guide but unfortunately there is not enough information on how to set the phase shift and all how to measure them.

Click to expand...

What part of Figure 4 from https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_altpll.pdf is too difficult to understand for setting the phase shift?

I tried measuring the phase shift between the 2 clocks of similar frequency which I generate i.e 1 clock goes to the sensor and the other I use it intern in my FPGA to simulate the sensor functioning. However they were having 0 deg phase shift. How would you measure the clock phase while designing the ALTPLL block??

Click to expand...

The first question is why are you trying to measure the phase shift? But assuming a valid reason, the only direct way you can measure them is to bring them out to external I/O pins. Then you put a scope on them and measure the time delay. If the signals cannot be brought out to I/O pins, then an indirect way to measure the phase shift is to measure the time delay between a flip flop available on an I/O pin that is clocked by clock #1 and a different flip flop available on an I/O pin that is clocked by clock #2.

In either case, you'll want to be using paths that the tool computes to have very similar path delays and assume that the actual skew between the paths matches the skew computed from the path delays reported in timing analysis.

Where is the difficulty in this?

Kevin Jennings

I'm using phase shift of Altera PLLs a lot but like K-J I'm having difficulties to find out what's the OP's problem with it.

Perhaps it would be easier if you tell which application problem you want to solve with PLL phase shift?

FvM said:

I'm using phase shift of Altera PLLs a lot but like K-J I'm having difficulties to find out what's the OP's problem with it.

Perhaps it would be easier if you tell which application problem you want to solve with PLL phase shift?

Click to expand...

Hi FVM,

well I am generating a sensor clock frequency and then sending it a CMOS Image sensor which in return send the same sensor clock back. I use this clock as input to a data PLL to generate 3 data clock which I use to sample the data further.

The first problem that I had was the locking of the PLL, I was able to solve it by choosing a different frequency. At the moment I get some errors in the data, which I believe it may be the clock phase shift which produce bad data.

@K-J

when you suggest that I measure the signal on the extern IO pins (which I have plenty). do you mean that I measure the phase between input clk and the 3 data clocks which I generate??

Hi,

I´d use the returning clock (from CCD) directely as DFF clock.
This is a clean solution. (As long as you select the correct clock edge)

Then use additional DFF to synchronize the data from first DFF to your FPGA system clock.

--> Both clocks are synchronous, but phase shifted (delayed). Here - depending on delay time - you again need to select the correct clock edge.
This avoids the use of PLL.
(synchrounous serial SDR data transfer)
****

But for sure the PLL solution should be "clean", too.

Klaus

KlausST said:

Hi,

I´d use the returning clock (from CCD) directely as DFF clock.
This is a clean solution. (As long as you select the correct clock edge)

Then use additional DFF to synchronize the data from first DFF to your FPGA system clock.

--> Both clocks are synchronous, but phase shifted (delayed). Here - depending on delay time - you again need to select the correct clock edge.
This avoids the use of PLL.
(synchrounous serial SDR data transfer)
****

But for sure the PLL solution should be "clean", too.

Klaus

Click to expand...

Hi Klaus,

are you telling not to use the PLL block and then produce the data PLL clocks ?? why would I want to synchronize it to my FPGA system clock??

what do you mean by select the right clock edge?? I am a beginner in this subject, are you telling me to observe my FPGA system clock and DFF sensor output clock on osci?? After that I need to add DFFs to synchronise the sensor clk with that of sys clock. Is that what you mean??

Hi,

are you telling not to use the PLL block and then produce the data PLL clocks ??

Click to expand...

for the synchronous serial SDR data input you don´t need a PLL at all.

*****

why would I want to synchronize it to my FPGA system clock??

Click to expand...

It´s recommended to avoid problems like metastability...

*****

what do you mean by select the right clock edge?? I am a beginner in this subject, are you telling me to observe my FPGA system clock and DFF sensor output clock on osci??

Click to expand...

You didnt give any specification or timing of your data and clock.
Therefore I assumed "synchronous serial SDR data input".
Usually data is clocked OUT at one clock edge and clockdIN at the opposite clock edge. --> The datasheet will tell you.

*****

After that I need to add DFFs to synchronise the sensor clk with that of sys clock. Is that what you mean??

Click to expand...

No, I meant what I wrote:
sensor data --> first DFF (@sensor_clock) --> second DFF (@FPGA_clock)

*****
But as said before: This is how I´d do it. There are other possible solutions.

Klaus

There are many unclear points in this thread, e.g. what's the purpose of 3 data clocks. A timing diagram would surely help to understand the problem.

I agree with KlausST that a single data rate signal with accompanying clock can be read in without a PLL. In some cases a PLL can be helpful though, e.g. to generate a sample clock with adjustable phase.