I'm having a battle with my Cyclone II FPGA. I am using Quartus 9.1 web version to create a LVDS data deserialiser/sequencer for an industrial camera. The image sensor has active and idle modes. In the active mode it passes image data, in idle mode it repeats the serial reference word that I use to align my deserialiser. There's no difference in word format or timing between these two modes. I'm using megafunctions for PLL and comparator, I made my own deserialiser, because the Altera one didn't hit the spot for my design. I have enabled Timing Driven Synthesis and written a SDC file to describe the clock frequencies I am using. So - I find that the output data turns to rubbish if there is a lot of image activity, but it is stable if the image is quiet. It is also OK when the sensor is in idle mode. I quickly discovered that the 12x PLL that multiplies the crystal clock is losing lock when picture is busy. Hold your hand over the lens, it stays locked. Let some light in, it loses lock (!) OK, so I do away with the PLL, and use a high frequency crystal instead. Not my preferred option, but,hey I'm getting desperate. Even this method is not rock solid when the image gets busy. Is it possible that I am getting crosstalk between signals inside the FPGA? Or perhaps some marginal timing? My design is almost completely pipelined, but needs to run from several different clock frequencies. I am designing in VHDL, and I can't use the LogicLock feature on my version of Quartus. Are there any other tricks I can try to tighten up timing or internal routing? Is internal crosstalk a known problem? TNX in advance... Pete

Hi snaarman, do you use a custom board or an Altera Development Kit?? I ask you this because I had similar problem with the PLL in mine custom board and the problem was in the power supply. At the beginning of the project I used only one PLL and all worked fine, I discovered the problem when I added a second PLL. When the second one locked the clocks signal the first one lost the lock signal. I solve the problem modifying the clock frequencies of the second PLL to fit in the first one because, in my case, to change the power supply became too much expensive. I hope that this post can help you.

Hi there. Yes, that is possible. It's a custom board and I did not provide special filtering to the PLL power pins unfortunately. However I measured it and the local 3v3 power plane seems quite clean. I begin to think the problem is deeper than the PLLs, because I still get data problems even when I don't use the PLL. I suspect some sort of data crosstalk inside the device. This seems a weird idea (after all my years designing with CPLDs) so I am open to any suggestions :) Pete --- Quote Start --- Hi snaarman, do you use a custom board or an Altera Development Kit?? I ask you this because I had similar problem with the PLL in mine custom board and the problem was in the power supply. At the beginning of the project I used only one PLL and all worked fine, I discovered the problem when I added a second PLL. When the second one locked the clocks signal the first one lost the lock signal. I solve the problem modifying the clock frequencies of the second PLL to fit in the first one because, in my case, to change the power supply became too much expensive. I hope that this post can help you. --- Quote End ---

Hi Pete, --- Quote Start --- I suspect some sort of data crosstalk inside the device. This seems a weird idea (after all my years designing with CPLDs) so I am open to any suggestions :) --- Quote End --- How about testing that theory? Create a design with a large number of pseudo-random binary sequence (PRBS) generators and checkers. The generators can send PRBS data through varying depths of pipeline registers to use resources on the device. Then at the checkers, each receiver PRBS would be loaded from each transmit PRBS, and would then count errors in the received streams. You do this by xor'ing the PRBS from the transmitter with the PRBS at the receiver (that was previously loaded from the transmit stream); if there are any bits different, the xor result will have bits set. If you get errors, then your hypothesis would be confirmed; you still might have clock errors, but at least this is an all-internal test that will assist in debug. There are Avalon cores for PRBS generation and checking, you could try those, or if they give you trouble, use the PRBS generator in here: http://www.ovro.caltech.edu/~dwh/correlator/pdf/esc2011_fpga_dsp_code.zip (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/esc2011_fpga_dsp_code.zip) There's another component not in there called 'count_ones.vhd' that will count the error bits in each xor result, and then accumulate the results ... see the attached VHDL ... Cheers, Dave

--- Quote Start --- Hi there. I begin to think the problem is deeper than the PLLs, because I still get data problems even when I don't use the PLL. I suspect some sort of data crosstalk inside the device. This seems a weird idea (after all my years designing with CPLDs) so I am open to any suggestions :) Pete --- Quote End --- I very much doubt that. Cross talk inside FPGAs is something I never heard of though it is possible in theory. I believe it is more likely you have clock domain transfer issues and possibly cross talk outside fpga.

--- Quote Start --- I very much doubt that. Cross talk inside FPGAs is something I never heard of though it is possible in theory. I believe it is more likely you have clock domain transfer issues and possibly cross talk outside fpga. --- Quote End --- I have seen strange 'errors' in FPGAs when you pull lots of power through them, or get them hot. Technically this is not the fault of the FPGA fabric, since the 'user' is either taking the die outside its thermal limit, or the power-supply is dipping below is data sheet specification. A PRBS is a nice test, since it can load down the power rails and warm things up nicely. Don't try this at home kids; unless you like the smell of burning ICs ... or your finger if it gets too close, i.e., don't touch the chip! (speaking from personal experience of course ...) Cheers, Dave

Doh! My PLLs lose lock. Crosstalk? | Altera Community

17 Replies

Altera_Forum
Honored Contributor
14 years ago
Hi snaarman,

do you use a custom board or an Altera Development Kit??
I ask you this because I had similar problem with the PLL in mine custom board and the problem was in the power supply.
At the beginning of the project I used only one PLL and all worked fine, I discovered the problem when I added a second PLL.
When the second one locked the clocks signal the first one lost the lock signal.
I solve the problem modifying the clock frequencies of the second PLL to fit in the first one because, in my case, to change the power supply became too much expensive.

I hope that this post can help you.
Altera_Forum
Honored Contributor
14 years ago
Hi there.
Yes, that is possible. It's a custom board and I did not provide special filtering to the PLL power pins unfortunately. However I measured it and the local 3v3 power plane seems quite clean.

I begin to think the problem is deeper than the PLLs, because I still get data problems even when I don't use the PLL. I suspect some sort of data crosstalk inside the device. This seems a weird idea (after all my years designing with CPLDs) so I am open to any suggestions :)

Pete

--- Quote Start ---
Hi snaarman,

do you use a custom board or an Altera Development Kit??
I ask you this because I had similar problem with the PLL in mine custom board and the problem was in the power supply.
At the beginning of the project I used only one PLL and all worked fine, I discovered the problem when I added a second PLL.
When the second one locked the clocks signal the first one lost the lock signal.
I solve the problem modifying the clock frequencies of the second PLL to fit in the first one because, in my case, to change the power supply became too much expensive.

I hope that this post can help you.
--- Quote End ---
Altera_Forum
Honored Contributor
14 years ago
Hi Pete,

--- Quote Start ---
I suspect some sort of data crosstalk inside the device. This seems a weird idea (after all my years designing with CPLDs) so I am open to any suggestions :)

--- Quote End ---
How about testing that theory?

Create a design with a large number of pseudo-random binary sequence (PRBS) generators and checkers. The generators can send PRBS data through varying depths of pipeline registers to use resources on the device. Then at the checkers, each receiver PRBS would be loaded from each transmit PRBS, and would then count errors in the received streams. You do this by xor'ing the PRBS from the transmitter with the PRBS at the receiver (that was previously loaded from the transmit stream); if there are any bits different, the xor result will have bits set. If you get errors, then your hypothesis would be confirmed; you still might have clock errors, but at least this is an all-internal test that will assist in debug.

There are Avalon cores for PRBS generation and checking, you could try those, or if they give you trouble, use the PRBS generator in here:

http://www.ovro.caltech.edu/~dwh/correlator/pdf/esc2011_fpga_dsp_code.zip (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/esc2011_fpga_dsp_code.zip)

There's another component not in there called 'count_ones.vhd' that will count the error bits in each xor result, and then accumulate the results ... see the attached VHDL ...

Cheers,
Dave
count_ones.vhd11 KB
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
Hi there.
I begin to think the problem is deeper than the PLLs, because I still get data problems even when I don't use the PLL. I suspect some sort of data crosstalk inside the device. This seems a weird idea (after all my years designing with CPLDs) so I am open to any suggestions :)

Pete
--- Quote End ---

I very much doubt that. Cross talk inside FPGAs is something I never heard of though it is possible in theory.
I believe it is more likely you have clock domain transfer issues and possibly cross talk outside fpga.
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
I very much doubt that. Cross talk inside FPGAs is something I never heard of though it is possible in theory.
I believe it is more likely you have clock domain transfer issues and possibly cross talk outside fpga.
--- Quote End ---
I have seen strange 'errors' in FPGAs when you pull lots of power through them, or get them hot. Technically this is not the fault of the FPGA fabric, since the 'user' is either taking the die outside its thermal limit, or the power-supply is dipping below is data sheet specification. A PRBS is a nice test, since it can load down the power rails and warm things up nicely.

Don't try this at home kids; unless you like the smell of burning ICs ... or your finger if it gets too close, i.e., don't touch the chip! (speaking from personal experience of course ...)

Cheers,
Dave
Altera_Forum
Honored Contributor
14 years ago
According to my experience, PLL problems with Cyclone II are mainly caused by interferences at the PLL analog powersupply. Cyclone III and it's sucessors have been provided with internal VCCA voltage regulators to overcome this weakness. Ground bounce respectively simultaneous switching noise (SSN) is an important factor in causing PLL unlock. It's particularly weird with large PQFP package due to the large lead frame and low ground pin count.

A customer had a design with a processor interface, where the 32-Bit data bus had to bet cut back to 16-Bit to achieve regular PLL operation. PLL unlock could be brought up by reading 32-Bit data from FPGA to the processor. Apparently the SSN caused by driving the bus was too much for the PLL. I wasn't involved in the PCB design, but as far as I remember, it's observing good engineering practice with separate VCCA decoupling.

An inappropriately bypassed "ringing" linear 1.2V regulator also caused PLL problems, but these could be easily eliminated.

With another design, where external interferences additionally have been disturbing PLL operation, disabling the PLL and changing the design to a high frequency crystal oscillator seemed to be the only reliable method to make it work.

Today, the problem has become legacy, because new designs are always based on Cyclone III or above.
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
Today, the problem has become legacy, because new designs are always based on Cyclone III or above.
--- Quote End ---

Interesting. Last december I checked, and pricing for the Cyclone III was still prohibitive for high-volume designs compared to the Cyclone II. I now notice, much to my satisfaction, that the Cyclone III prices have dropped to the same levels as equivalent Cyclone II components. It seems like Altera is finally pushing to get everyone over to Cyclone III at minimum.
Altera_Forum
Honored Contributor
14 years ago
I agree that you need to check your PLLs supplies. Although you did say that you had removed the PLL and were using a high frequency osc. It might be your crystal supply as they are common to both.

One other thing I have seen in the past (cyclone II) is that you can get problems with SSN if you use a lot of the pins in the device and max out their current drive on LVTTL. You can reduce the I/O switching current down to min current, that seemed to help. The SSN causes caused wierd random failures.
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---

One other thing I have seen in the past (cyclone II) is that you can get problems with SSN if you use a lot of the pins in the device and max out their current drive on LVTTL. You can reduce the I/O switching current down to min current, that seemed to help. The SSN causes caused wierd random failures.
--- Quote End ---

Thanks for that.. Weird random failures (WRFs?) are exactly what I am getting. As I can't rework the PCB for cleaner power just yet, I am re-engineering it for 3v3 LVCMOS inputs and using external LVDS translator chips on a subcard. I will try that and also remove the PLLs altogether.

If we still still get WRFs I shall go to the pub for several beers.

:(

Pete
Altera_Forum
Honored Contributor
14 years ago
Besides looking for noise on the power supply pins VCCA and VCCD, I would next look clock input. I had a board which had clean clock source measured at the PCB board. However the clock input pin was picking up noise inside the device onto the clock signal. Check if any nearby IO pins are toggling by the clock input. If there is try to not toggle nearby pins to see if the problem changes. My solution was to use a different clock input on a different IO bank.

Forum Discussion

Doh! My PLLs lose lock. Crosstalk?

17 Replies

Recent Discussions

Self service license server doesn't work

Timing analysis - long combinational path

Docker image for Quartus Pro 26.1 missing ?

Error (292014): Can't find valid feature line for core SLL_CA_HBC_T001_Hyperbus_Memory_Controller_10

Agilex 5 – Critical HSSI Error in JESD204B Example Design