PLL woes

[cocoacrumbs]

Hi,

Since this caused me a few hours to figure out, I thought it might be interesting to share it here.

I wanted to try out higher screen resolutions and I managed to get the needed PLL parameters with icepll -i clockin -o clockout -m without problems.

All was fine as long as I sticked to 640 by 480 resolution. But trying the higher resolutions, my LCD screen flickered constantly and it never seemed able to lock to the video signal.

I finally found out that this line if (!pix_clk_locked) in the code below was related to this:

    // calculate horizontal and vertical screen position
    always_ff @(posedge pix_clk) begin
        if (sx == LINE) begin  // last pixel on line?
            sx <= 0;
            sy <= (sy == SCREEN) ? 0 : sy + 1;  // last line on screen?
        end else begin
            sx <= sx + 1;
        end
        // if (!pix_clk_locked) begin
        if (reset) begin
            sx <= 0;
            sy <= 0;
        end
    end

From what I understand is, that the PLL at those higher frequencies looses it lock quite often before it could acquire a lock again and this is constantly resetting sx and sy. Which could explain the flickering. When I replaced the if (!pix_clk_locked) with if (reset) then all is well.

I checked the datasheet of the iCE40HX8K I'm using (which has a 100 MHz input clock - it's an Olimex iCE40HX8K-EVB) and the min VCO freq is 533 MHz while its max VCO freq is 1066 MHz (assuming this is the problem).

Weirdly, the VCO that is calculated by icepll for the 640 by 480 @ 60 Hz is 810 MHz and it has no problems with that. But the calculated VCO for 800 by 600 @ 60 Hz is only 640 MHz. Thus lower, but it does cause that weird PLL Lock problem.

[WillGreen]

Thanks for your note. I'm glad your got it working, but I'd be concerned about the reliability of a design that repeatedly loses clock lock. I've not really worked with iCE40HX, so don't have any suggestions on the VCO situation. Perhaps someone else can chime in?

[gitRepairman]

I've never commented on this forum before, but here goes...
If you could reply with your clockin, clockout, DIVF, DIVQ, DIVR, and FILTER_RANGE settings perhaps I could make a better guess.
If I had to guess, FILTER_RANGE comes to mind.
Your wiring is more critical at higher frequency. You might have to 'scope the actual signals. My experience is that the PLL will lock reliably even when the VCO frequency is out of spec. Hope this helps.

[cocoacrumbs]

Hi,

Thanks for all the feedback.

These are the PLL settings I use (and got from the icepll tool from the icestorm project).

$ icepll -i 100 -o 25.175

F_PLLIN:   100.000 MHz (given)
F_PLLOUT:   25.175 MHz (requested)
F_PLLOUT:   25.312 MHz (achieved)

FEEDBACK: SIMPLE
F_PFD:   10.000 MHz
F_VCO:  810.000 MHz

DIVR:  9 (4'b1001)
DIVF: 80 (7'b1010000)
DIVQ:  5 (3'b101)

FILTER_RANGE: 1 (3'b001)

$ icepll -i 100 -o 40

F_PLLIN:   100.000 MHz (given)
F_PLLOUT:   40.000 MHz (requested)
F_PLLOUT:   40.000 MHz (achieved)

FEEDBACK: SIMPLE
F_PFD:   20.000 MHz
F_VCO:  640.000 MHz

DIVR:  4 (4'b0100)
DIVF: 31 (7'b0011111)
DIVQ:  4 (3'b100)

FILTER_RANGE: 2 (3'b010)

Both input and output frequencies are within spec for the PLL. The only thing I see that's above the minimum capability of the PLL is F_VCO (which is 533 MHz). However F_VCO for the stable 640 by 480 @ 60 Hz is higher at 810 MHz which is only 640 MHz for the not so stable 800 by 600 @ 60 Hz. Which is why I'm confused. I would have expected the opposite.

From reading a bit more about PLL's, one reason of loosing a lock could be PCB layout and/or unstable power supplies.

Maybe the rather high input frequency (100 MHz) isn't doing the PLL any favors? If I would design a real product (which this isn't, since I'm still learning), choosing a better/lower input frequency might help maybe as well?

[gitRepairman]

Hello again,
I'm still just learning also, on the UPduino 3.0 / up5K. Your chip may be different, but I believe the PLL is identical.
Your calculations for PLLOUT 25.3125 MHz (achieved) are 0.55 % high.
Not that it will matter much, but this is only 0.13% high at 25.2083 MHz., VCO 806.667
.DIVF(7'd120),
.DIVQ(3'd5),
.DIVR(4'd14),
.FILTER_RANGE(3'd1),
That said, I too had problems with the LOCK line. Send it to a digital output and 'scope it.
Long settling time. Yet the actual output ( filtered ) is rock steady on the spectrum analyzer.
Too lazy to build in a settling delay before checking LOCK, I just ignore it. Everything works fine.
Not to worry about VCO frequency, it's internal and good above 1 GHz. as you point out.
If you have a 'scope or counter, monitor the 25 MHz and see what's really happening,
I agree, layout of the Olimex board may affect your results. 100 MHz. input deserves respect,
but ain't rocket science nowadays.

[cocoacrumbs]

Hi,

Sorry for the long delay in reacting but I think I finally found out what is going on.

TLDR: It must be a hardware problem on the Olimex FPGA board I'm using (power supply issues?).

Full story

When I thought I got a working PLL, I continued by adding font ROM code and show its content on the screen. Initially I did this with only the RED channel in use and the picture seemed stable (see 1. RED channel only 640x480) although I seemed to notice a light shimmering.

Then I wanted to see everything in white. For some reason, the display was very jittery. My LCD monitor could lock to the 25 MHz clock but the image was certainly not stable (see 2. all RGB channels in use (== white) with severe jitter 640x480 , you can see some rows have slanted characters. In reality those were moving quite fast and not really readable).

I spend a few evening going through every line of my code (I'm a total newbie) that could explain why this happened but I couldn't find any explanation.

I do happen to also have an Alchitry Cu FPGA board which is also using the iCE40HX8K (but with a smaller BGA package). And in the past I made a small expansion board for a VGA connector and SRAM, meant for a framebuffer (see 7. My own VGA-PS2-SRAM board for the Alchitry CU). I decided to run exactly the same code on it and to my big surprise this worked without a hitch. Even the higher resolution of 1280x1024 was rock stable (see 4. Running on Alchitry at 1280x1024). Interesting to note is that the Alchitry board is also using a 100 MHz clock.

So, since my code seems to be OK, I decided to take a look at the clock signal generated by the PLL on the Olimex board.

5. 25 MHz from the Olimex board is the output of the PLL for 25.000 MHz. It doesn't look good to me but the LCD monitor produced a stable image albeit with a slight shimmer. Which is probably explained by this weird clock signal.

6. 25.312 MHz from the Olimex board is the output when I ask the PLL to output 25.175 MHz (which results in 25.312 MHz with the icepll suggested settings). You can see fast and severe ghosting which probably explains the very unstable image I got.

So, the good news is that my coding was good but the bad news is that this board is either defective or it's PCB design isn't good for a stable PLL output). It also explains why I had trouble to obtain a PLL Lock I think.

The funny thing is that I abandoned the Alchitry board because I had no confidence in the build quality... When I received it, it didn't want to start up. Then I discovered a tiny solder bridge on one of the expansion connectors. After removing it, the FPGA worked but it's very hard to see if there are other solder bridges with such tiny components. At that time I already made that VGA/PS2/SRAM board (my first 4 layer PCB) which seemed to work.

Around the same time, I discovered the Olimex solution with SRAM on the same board as the FPGA and their VGA/PS2 expansion board. I had good experience with Olimex in the past, so I decided to switch to this solution to avoid any potential hardware problems there still might have been with the Alchitry board... As it turns out, I might better stayed with the Alchitry to avoid a few, very frustrating evenings.