Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16559 Discussions

Doh! My PLLs lose lock. Crosstalk?

Altera_Forum
Honored Contributor II
1,541 Views

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
0 Kudos
17 Replies
Altera_Forum
Honored Contributor II
718 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
718 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

 

--- 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
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

 

--- 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
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
718 Views

I thought I would update on this one. 

 

We re-laid the board. We put in filtering for the PLL pins. We checked the data and clock timing again. We cleaned everything up and.. it made no real difference. All my problems still felt like some sort of crosstalk inside the device. The more output activity, the less reliable the processing. 

 

I fell across the answer by accident. We drive a 28 bit bus from one side of the chip at 40MHz, so that's a lot of output pins changing at the same time.  

 

So.. I changed the current drive strength on all the outputs (except outgoing clocks and strobes) from 24mA which was the default, to 4mA.  

 

This seems to have fixed it. At last. After three months... 

 

:-) 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

Hi Pete, 

 

 

--- Quote Start ---  

 

I fell across the answer by accident. We drive a 28 bit bus from one side of the chip at 40MHz, so that's a lot of output pins changing at the same time.  

 

So.. I changed the current drive strength on all the outputs (except outgoing clocks and strobes) from 24mA which was the default, to 4mA.  

 

This seems to have fixed it. At last. After three months... 

 

--- Quote End ---  

Thanks for the update. 

 

How 'well' is this fixed though? 

 

Did you try different current strengths? Did you try different combinations of bit patterns, eg. walking 1's, walking 0's, an increasing number of transitions on the bus, a PRBS signal over the bus? 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

As previously explained, it's not cross talk inside the device. Your experience is almost reproducing what I reported in post# 7. The difference is however, that drive strength had been already reduced in our design. 

 

Reducing the drive strength from maximum to minimum involves a considerable interference reduction as well, I think there's reason for hope. 

 

But, when redesigning the board, why didn't you change to Cyclone III or IV? It can be expected to end the ground bounce/SSN related PLL unlock problems.  

 

Regards, 

Frank
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

 

--- Quote Start ---  

Reducing the drive strength from maximum to minimum involves a considerable interference reduction as well, I think there's reason for hope. 

 

But, when redesigning the board, why didn't you change to Cyclone III or IV? It can be expected to end the ground bounce/SSN related PLL unlock problems.  

 

Regards, 

Frank 

--- Quote End ---  

 

 

In general I think the layout and power supplies are ok now (filters on PLL inputs, ground and power planes, ultra short tracking etc etc). 

 

Yes, I agree that this feels more like an "analog" fix rather than a logical fix, however if it proves reliable then I will put aside my residual concerns :) 

 

As to Cyclone III, (I haven't checked this) I think our only options at this size chip would be BGA. We did a BGA design once but were frightened by the whole layout and pcb building process. Plus you can't scope the pins easily. 

 

I know we will have no choice in this one day :( 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

 

--- Quote Start ---  

Hi Pete, 

 

Thanks for the update. 

 

How 'well' is this fixed though? 

 

Did you try different current strengths? Did you try different combinations of bit patterns, eg. walking 1's, walking 0's, an increasing number of transitions on the bus, a PRBS signal over the bus? 

 

Cheers, 

Dave 

--- Quote End ---  

 

 

No, I just went for 4mA. There is only about 2 inches of track to the appropriate bus receiver, and no real loading, so the tracks don't need heavy drive current for terminators.  

 

As to data tests, we are driving it with real video sensor data, and if anything reveals poor timing or weak design, its camera video data :) 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

 

--- Quote Start ---  

 

We did a BGA design once but were frightened by the whole layout and pcb building process. Plus you can't scope the pins easily. 

 

--- Quote End ---  

Actually, I prefer BGA designs for probing. 

 

The key is to design the PCB such that all BGA pads go to vias, and then expose the bottoms of the vias. A scope probe then sits nicely in the via on the PCB underside. I add a few ground vias around the outside of the BGA pattern and put a white circle around them on the silk, I can then use those known-grounds as my probe tip ground. 

 

1mm pitch BGAs are also easy to decouple. You have the PCB house expoxy fill the ground and power vias on the underside, and you can place 0402 components directly across the via pairs. If you have a VCC pin without a nearby ground, then you sacrifice an I/O pin, by cutting its BGA pad to via trace, and re-purposing the via as a ground via. 

 

For an example of this, there are PCB design files here: 

 

http://www.ovro.caltech.edu/~dwh/carma_board/index.html (http://www.ovro.caltech.edu/%7edwh/carma_board/index.html

 

Ok, these features are not ideal for the lowest-cost board design, however, if you have to go to a BGA based design, then using this approach makes layout and debugging a lot easier. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
718 Views

Although I also want to encourage you to try FPGA with BGA packages for your design, I can understand that you shy at the new PCB technology requirements.  

 

I have a customer who also strictly tried to avoid BGA packages with FPGAs until two years ago. I've been using e.g. EP3C16P240 or EP3C25P240. It has several adavantages over EP2C20P240, PLL stability is one of them.
0 Kudos
Reply