- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
We are using the LMX2572 on a custom IC to produce a fixed 3.2 GHz or 4 GHz output. Our design uses the same schematic and almost the same layout as the LMX2572EVM eval board. We also program the PLL on the custom board with the same values as the eval board. While the output spectrum on the eval board looks as expected, we have a strong spur with phase noise around 2.5 - 2.8 MHz offset from the carrier in our custom board. We are looking for some guidance on why we might have these spurs on our custom design when the eval board does not - as far as we can tell the design on the custom board including all component values and register settings is the same as the eval board. We have also tried using the same reference signal for both cases, and also powered the eval board from the 3.3V on our custom board in case supply noise was the source.
A measurement of the PLL output on the custom board is shown below.
We have tried a wide variety of CP gain settings, and they do not affect the magnitude nor frequencies of the large spurs. We have also modified the amount of bypass capacitance on the 3.3V supply we are using, and changing the active state of other components that share the same supply - but none of these things have changed the output spectrum. We have also tried using two different 10 MHz reference signals, and then the 100 MHz reference from the eval board that pairs with the LMX2572 (after changing the appropriate register settings to work with the 100 MHz PFD instead of 10 MHz). We have also tried changing the multiplier and VCO doubler settings, but none of these things impact the large spurs. The spurs have a consistent offset when other VCO outputs are used (3.2 GHz, 3.6 GHz, 4 GHz), and we have tried both integer-only operation, and a few different frac-N configurations, but these have no impact on the spurs.
We measured the spectrum of all pins around the PLL, and all pins including the supplies look very clean except for VrefVCO (pin 36) and VrefVCO2 (pin 29). Both of those pins have the strong ~2.5 MHz and the higher harmonics that we see on the resulting output spectrum. I see a much lower power spur at the same frequencies on the VbiasVCO pins (3 and 27). All of the capacitors on these pins are the same values as the eval board, with the same close connection to ground near the PLL. We also measured the ground side of each of the capacitors, and confirmed they are all properly connected and the ground is clean in that area.
We are using an FPGA to program the PLL on our custom board, using these register settings and in this order (see below). We have used the same register settings when using TICsPro to program the eval board. Besides the ~2.5 MHz spurs and higher close-in phase noise than we see on the eval board, the PLL otherwise is operating how we expect and locks to the correct frequencies.
pll_config_vector[0] <= 24'h7D2288;
pll_config_vector[1] <= 24'h7C0000;
pll_config_vector[2] <= 24'h7B0000;
pll_config_vector[3] <= 24'h7A0000;
pll_config_vector[4] <= 24'h790000;
pll_config_vector[5] <= 24'h780000;
pll_config_vector[6] <= 24'h770000;
pll_config_vector[7] <= 24'h760000;
pll_config_vector[8] <= 24'h750000;
pll_config_vector[9] <= 24'h740000;
pll_config_vector[10] <= 24'h730000;
pll_config_vector[11] <= 24'h727802;
pll_config_vector[12] <= 24'h710000;
pll_config_vector[13] <= 24'h700000;
pll_config_vector[14] <= 24'h6F0000;
pll_config_vector[15] <= 24'h6E0000;
pll_config_vector[16] <= 24'h6D0000;
pll_config_vector[17] <= 24'h6C0000;
pll_config_vector[18] <= 24'h6B0000;
pll_config_vector[19] <= 24'h6A0007;
pll_config_vector[20] <= 24'h694440;
pll_config_vector[21] <= 24'h680000;
pll_config_vector[22] <= 24'h670000;
pll_config_vector[23] <= 24'h660000;
pll_config_vector[24] <= 24'h650000;
pll_config_vector[25] <= 24'h640000;
pll_config_vector[26] <= 24'h630000;
pll_config_vector[27] <= 24'h620000;
pll_config_vector[28] <= 24'h610000;
pll_config_vector[29] <= 24'h600000;
pll_config_vector[30] <= 24'h5F0000;
pll_config_vector[31] <= 24'h5E0000;
pll_config_vector[32] <= 24'h5D0000;
pll_config_vector[33] <= 24'h5C0000;
pll_config_vector[34] <= 24'h5B0000;
pll_config_vector[35] <= 24'h5A0000;
pll_config_vector[36] <= 24'h590000;
pll_config_vector[37] <= 24'h580000;
pll_config_vector[38] <= 24'h570000;
pll_config_vector[39] <= 24'h560000;
pll_config_vector[40] <= 24'h550000;
pll_config_vector[41] <= 24'h540000;
pll_config_vector[42] <= 24'h530000;
pll_config_vector[43] <= 24'h520000;
pll_config_vector[44] <= 24'h510000;
pll_config_vector[45] <= 24'h500000;
pll_config_vector[46] <= 24'h4F0000;
pll_config_vector[47] <= 24'h4E0107;
pll_config_vector[48] <= 24'h4D0000;
pll_config_vector[49] <= 24'h4C000C;
pll_config_vector[50] <= 24'h4B0940;
pll_config_vector[51] <= 24'h4A0000;
pll_config_vector[52] <= 24'h49003F;
pll_config_vector[53] <= 24'h480001;
pll_config_vector[54] <= 24'h470081;
pll_config_vector[55] <= 24'h46C350;
pll_config_vector[56] <= 24'h450000;
pll_config_vector[57] <= 24'h4403E8;
pll_config_vector[58] <= 24'h430000;
pll_config_vector[59] <= 24'h4201F4;
pll_config_vector[60] <= 24'h410000;
pll_config_vector[61] <= 24'h401388;
pll_config_vector[62] <= 24'h3F0000;
pll_config_vector[63] <= 24'h3E00AF;
pll_config_vector[64] <= 24'h3D00A8;
pll_config_vector[65] <= 24'h3C03E8;
pll_config_vector[66] <= 24'h3B0001;
pll_config_vector[67] <= 24'h3A9001;
pll_config_vector[68] <= 24'h390020;
pll_config_vector[69] <= 24'h380000;
pll_config_vector[70] <= 24'h370000;
pll_config_vector[71] <= 24'h360000;
pll_config_vector[72] <= 24'h350000;
pll_config_vector[73] <= 24'h340421;
pll_config_vector[74] <= 24'h330080;
pll_config_vector[75] <= 24'h320080;
pll_config_vector[76] <= 24'h314180;
pll_config_vector[77] <= 24'h3003E0;
pll_config_vector[78] <= 24'h2F0300;
pll_config_vector[79] <= 24'h2E07F1; // was f0
pll_config_vector[80] <= 24'h2DCE3F; // was ce1f
pll_config_vector[81] <= 24'h2C1F60; // was 1F63
pll_config_vector[82] <= 24'h2B0000;
pll_config_vector[83] <= 24'h2A0000;
pll_config_vector[84] <= 24'h290000;
pll_config_vector[85] <= 24'h280000;
pll_config_vector[86] <= 24'h2703E8;
pll_config_vector[87] <= 24'h260000;
pll_config_vector[88] <= 24'h250005; //was 105 was 0205
pll_config_vector[89] <= 24'h240020; //was 00C8 was 0190
pll_config_vector[90] <= 24'h230004;
pll_config_vector[91] <= 24'h220010;
pll_config_vector[92] <= 24'h211E01;
pll_config_vector[93] <= 24'h2005BF;
pll_config_vector[94] <= 24'h1FC3E6;
pll_config_vector[95] <= 24'h1E18A6;
pll_config_vector[96] <= 24'h1D0000;
pll_config_vector[97] <= 24'h1C0488;
pll_config_vector[98] <= 24'h1B0002;
pll_config_vector[99] <= 24'h1A0808;
pll_config_vector[100] <= 24'h190624;
pll_config_vector[101] <= 24'h18071A;
pll_config_vector[102] <= 24'h17007C;
pll_config_vector[103] <= 24'h160001;
pll_config_vector[104] <= 24'h150409;
pll_config_vector[105] <= 24'h145048;
pll_config_vector[106] <= 24'h1327B7;
pll_config_vector[107] <= 24'h120064;
pll_config_vector[108] <= 24'h110095;
pll_config_vector[109] <= 24'h100080;
pll_config_vector[110] <= 24'h0F060E;
pll_config_vector[111] <= 24'h0E1820;
pll_config_vector[112] <= 24'h0D4000;
pll_config_vector[113] <= 24'h0C5001;
pll_config_vector[114] <= 24'h0BB018;
pll_config_vector[115] <= 24'h0A10F8;
pll_config_vector[116] <= 24'h090004; //was 0004
pll_config_vector[117] <= 24'h082000;
pll_config_vector[118] <= 24'h0700B2;
pll_config_vector[119] <= 24'h06C802;
pll_config_vector[120] <= 24'h0538C8; //was 30C8
pll_config_vector[121] <= 24'h040A43;
pll_config_vector[122] <= 24'h030782;
pll_config_vector[123] <= 24'h020500;
pll_config_vector[124] <= 24'h010808;
pll_config_vector[125] <= 24'h00211C;
Thank you for the help!
Matt
Here is the spectrum I captured of the eval board PLL and the PLL in my module. Top left shows the eval board PLL when I do not have it also connected in parallel to my module PLL SPI interface. Bottom left is eval PLL spectrum when I connect a spectrum sniffing probe to my module to look at the PLL spectrum there. You can see that we start to see some of the spurs even on the PLL module. Top right is the eval board PLL spectrum when I have the SPI wires connected to both the eval board and the module PLL, and the bottom right is the spectrum of the module PLL. In all of these cases, both PLLs were programmed by the FPGA we are using.
When I use the eval board (Reference Pro with TICsPro software) to program the PLL on my module, it still locks to the correct frequency and I still see the noise. I did have to wire the SPI directly from the Reference Pro board as the Module PLL was having trouble getting programmed by using the test points on the other side of the series resistors on the PLL eval board. When programming the eval board PLL with the eval board, the spectrum looks the same as the top left plot above.
I also collected spectrum on all the pins you mentioned. The top plots below show spectrum on pins 3 and 27 on my module, and on the bottom pins 3 and 27 on the eval board. Both look basically the same with no issues.
Pins 29 and 36 are very different. Again the top plots are the module and the bottom is the eval board. The module PLL still has what looks like oscillations on the VCO reference pins.
If it is relevant, I also collected spectrum of the reference signal entering the PLL on my module. Left plot is zoomed in on the 100 MHz signal, and the right plot shows a wider view from 1-300 MHz. This seems OK to me.
The issue I'm seeing does not seem to be programming related. Is there anything that could cause an oscillation like we are seeing on the VCO reference pins? On the layout, I have both of those pins shunted to ground with 10uF caps very close to the IC - we had copied the eval board layout, but used 0402 caps instead of the 0603 caps in the eval board. These are very strong signals given the 10uF shunt to ground.
Any other ideas?
Thanks!
Matt
Hi Noel -
I modified our module so I was able to both program and read back the register values with the Reference Pro board. It looks like the PLL on our module is getting the programmed values correctly. All matched the sent programming state, except:
0x70 7287 This has VCO_DACISET
0x6F 018D This reads back actual CAPCTRL value the VCO calibration has chosen. When I then programmed this value they then matched.
0x6E 0C28
0x6E is VCO select and LD_Vtune; readback: shows LD = 10 VCO = 001, so locked and the correct VCO
0x6D 9D7D (Not used, read only)
0x6C 00A1 (Not used, read only)
0x6B 8801 (Not used, read only)
I think tried forcing DACISET to different values, and found that this shifted the frequency offset of the spurs I'm seeing. Could this be a clue?
I also found that forcing the CAPCTRL value to a slightly different value helped the close-in spurs/noise, but had no affect on the ~2.5MHz tones. Going more than a few values away from the calibrated value caused the PLL to unlock.
During these tests I shut off the clock to the FPGA, but the FPGA is still powered up. I'm also getting the 3.3V from a LTM4644 power supply that is then filtered. To better isolate just the PLL, we are currently building up a new module with just the PLL and the supporting SMT parts on the board, and we will supply 3.3V from a lab supply and program via the Reference Pro board (as well as provide the 100 MHz reference from it). I'll update if we are still seeing the spurs even in that case.
Hi Noel -
We have the CE pin tied to 3.3V. However, it turns out we have a 0 ohm resistor tying CE to 3.3V instead of a 100K resistor. Perhaps noise from 3.3V could contribute to problems with using a 0-ohm jumper with CE?
I also noticed our RampDIR pin is pulled high instead of low, but RampCLK, SysRefReq, and SYNC_TP are all pulled low (also with 0-ohm jumpers). Should we also pull RampDIR low and use ~12K resistors for all of those pins?
I tried starting with a blank PCB from our module and only populating the PLL and the supporting parts. When I used a lab supply to power that, it worked great (spectrum shown on right below). When I then used powered this board using 3.3V from one of our modules via some wires, I got more close-in noise but did not see the ~2.5 MHz spurs.
Right now we are modifying one of our fully-populated modules so the 3.3V for the PLL is isolated from everything else. This will let me try out a lab supply for that part while the rest of the module is self-powered, and then I can try adding some in-line filtering for the PLL. We can also replace all of the 0-ohm jumpers for CE/RampDIR/etc with the values from the eval board.
