This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] LMX2572:载波的强大杂散2.5-2.8MHz 偏移

Guru**** 2387080 points
Other Parts Discussed in Thread: LMX2572EVM, LMX2572
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1046040/lmx2572-strong-spur-2-5-2-8-mhz-offset-from-carrier

器件型号:LMX2572

我们在定制 IC 上使用 LMX2572来生成3.2GHz 或4GHz 的固定输出。  我们的设计使用与 LMX2572EVM 评估板相同的原理图和几乎相同的布局。  我们还使用与评估板相同的值对定制板上的 PLL 进行编程。  虽然评估板上的输出频谱符合预期、但我们具有强大的杂散、并且自定义板中载波的相位噪声偏移约为2.5MHz 至2.8MHz。 我们正在寻找一些指导、以了解当评估板不工作时、我们为什么会在定制设计中使用这些杂散-我们可以告诉定制板上的设计、包括所有组件值和寄存器设置与评估板相同。  我们还尝试在这两种情况下使用相同的基准信号、并在电源噪声是源的情况下、使用定制板上的3.3V 电压为评估板供电。

下面显示了自定义电路板上 PLL 输出的测量。

我们已经尝试了各种各样的 CP 增益设置、它们不会影响大杂散的幅度和频率。  我们还修改了所使用的3.3V 电源上的旁路电容数量、并更改了共享同一电源的其他组件的活动状态-但这些都没有改变输出频谱。  我们还尝试使用两个不同的10MHz 基准信号、然后使用来自与 LMX2572配对的评估板的100MHz 基准(在更改适当的寄存器设置以与100MHz PFD (而不是10MHz)配合使用之后)。  我们还尝试更改乘法器和 VCO 倍频器设置、但这些都不会影响大杂散。  当使用其他 VCO 输出(3.2GHz、3.6GHz、4GHz)时、杂散具有一致的偏移、并且我们尝试了仅整数运算和一些不同的 FRAC-N 配置、但这些对杂散没有影响。

我们测量了 PLL 周围所有引脚的频谱、除 VrefVCO (引脚36)和 VrefVCO2 (引脚29)外、包括电源在内的所有引脚看起来都非常干净。  这两个引脚都具有~2.5MHz 的强谐波以及我们在生成的输出频谱上看到的更高谐波。  在 VbiasVCO 引脚(3和27)上、我在相同频率下看到的功率杂散要低得多。  这些引脚上的所有电容器的值与评估板相同、在 PLL 附近具有与接地相同的紧密连接。  我们还测量了每个电容器的接地侧、并确认它们都正确连接、并且该区域的接地干净。

我们使用 FPGA、使用这些寄存器设置并按此顺序对定制板上的 PLL 进行编程(请参阅下文)。  我们在使用 TICsPro 对评估板进行编程时使用了相同的寄存器设置。  除了~2.5MHz 杂散和比我们在评估板上看到的更高近端相位噪声、PLL 也是按照我们的预期工作、并锁定到正确的频率。   

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'h50000;
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;//之前为 f0
PLL_CONFIG_Vector[80]<= 24'h2DCE3F;//之前为 ce1f
PLL_CONFIG_Vector[81]<= 24'h2C1F60;//之前为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;//WAS105为0205
PLL_CONFIG_Vector[89]<= 24'h240020;//WAS00C8为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;//WAS0004
PLL_CONFIG_Vector[117]<= 24'h082000;
PLL_CONFIG_Vector[118]<= 24'h0700B2;
PLL_CONFIG_Vector[119]<= 24'h06C802;
PLL_CONFIG_Vector[120]<= 24'h0538C8;//WAS30C8
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;

感谢您的帮助!
Matt

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matt、

    评估板中引脚3、27、29和36的频谱是如何的?

    您是否尝试使用 FPGA 对评估板进行编程?

    有多少 LMX2572存在此问题?  

    如果您关闭 FPGA 并使用 TICS Pro 对 LMX2572进行编程、该噪声会消失吗?  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好,Noel -  

    感谢您的宝贵建议。

    我有四个不同的模块、它们都显示了相同的噪声问题。

    我修改了其中一个模块、以便尝试使用 FPGA 对 PLL 评估板进行编程、并尝试使用评估板 Reference Pro 卡对模块中的 PLL 进行编程。  在这些测试中、我能够确认 FPGA 代码已正确编程评估板 PLL (具有预期的纯净频谱)、并且即使我将 Reference Pro 与 TICsPro 软件一起使用、我的模块中的 PLL 仍有噪声。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    这是我在模块中捕获的评估板 PLL 和 PLL 的频谱。  左上角显示了评估板 PLL、当我没有将其并行连接到模块 PLL SPI 接口时。  左下角是评估 PLL 频谱、当我将频谱监听探针连接到我的模块以查看那里的 PLL 频谱时。  您可以看到、即使在 PLL 模块上、我们也开始看到一些杂散。  右上角是将 SPI 线连接到评估板和模块 PLL 时的评估板 PLL 频谱、右下角是模块 PLL 的频谱。  在所有这些情况下、我们使用的 FPGA 对两个 PLL 进行了编程。

    当我使用评估板(带有 TICsPro 软件的 Reference Pro)对模块上的 PLL 进行编程时、它仍然锁定到正确的频率、并且我仍然看到噪声。  我必须直接从 Reference Pro 板连接 SPI、因为模块 PLL 在使用 PLL 评估板上串联电阻器另一侧的测试点进行编程时遇到了问题。  使用评估板对评估板 PLL 进行编程时、频谱与上面左上角的图相同。

    我还在您提到的所有引脚上收集了频谱。  下面的顶部图显示了我的模块上的引脚3和27以及评估板上的底部引脚3和27的频谱。  两者看起来基本相同、没有任何问题。

    引脚29和36非常不同。  顶部的图是模块、底部是评估板。  模块 PLL 在 VCO 基准引脚上仍然具有看起来像的振荡。

    如果相关、我还收集了进入模块上 PLL 的参考信号的频谱。  左图放大了100MHz 信号、右图显示了1-300MHz 范围内的更宽视图。  这对我来说似乎是可以的。

    我看到的问题似乎与编程无关。  是否有任何可能导致我们在 VCO 基准引脚上看到的振荡的东西?  在布局上、我将这两个引脚分流至接地、其中10uF 电容器非常靠近 IC -我们复制了评估板布局、但使用了0402电容器、而不是评估板中的0603电容器。  在10uF 分流到接地的情况下、这些是非常强的信号。

    还有其他想法吗?

    谢谢!
    Matt

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matt、

    当您使用 TICS Pro 对模块进行编程时、是否关闭了 FPGA?

    您是否使用直流/直流转换器为 LMX 提供电源?

    如果您还没有这么做、您能否在 SPI 接口上添加一个串联电阻(大约100Ω Ω)+并联电容器(1nF)?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好,Noel -  

    我修改了我们的模块、以便能够使用 Reference Pro 板对寄存器值进行编程和读回。  我们模块上的 PLL 看起来是正确获得编程值的。 所有这些都与发送的编程状态匹配、但以下情况除外:

    0x70 7287 这是 VCO_DACISET

    0x6f 018D 这会读回 VCO 校准选择的实际 CAPCTRL 值。  当我编程该值时、它们会匹配。

    0x6E 0C28  

    0x6E 为 VCO 选择和 LD_VTune; 回读: 显示 LD = 10 VCO = 001、因此锁定且 VCO 正确  

    0x6D 9D7D (未使用、只读)

    0x6C 00A1 (未使用、只读)

    0x6B 8801 (未使用、只读)

    我想尝试将 DACISET 强制为不同的值、发现这会改变我看到的杂散的频率偏移。  这是线索吗?

    • 511 (最大值)具有3.8MHz 的杂散偏移
    • 255的杂散偏移为3.36MHz
    • 127的杂散偏移为2.7MHz
    • 63的杂散偏移为2.17MHz
    • 31 (或更低)具有非常微弱的基音

    我还发现、强制 CAPCTRL 值为稍微不同的值有助于实现近端杂散/噪声、但对~2.5MHz 音调没有影响。  偏离校准值的值超过几个值会导致 PLL 解锁。

    在这些测试期间、我关闭 FPGA 的时钟、但 FPGA 仍处于通电状态。  我还将从 LTM4644电源获取3.3V 电压、然后进行滤波。  为了更好地隔离 PLL、我们目前正在构建一个新模块、其中仅包含 PLL 和板上的支持 SMT 部件、 我们将通过实验室电源提供3.3V 电压、并通过 Reference Pro 板进行编程(并通过该板提供100MHz 参考)。  如果我们在这种情况下仍然看到杂散、我将进行更新。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、

    在3.2GHz 至3.6GHz VCO 范围内、校准应该会使您获得 VCO1、但确实如此。

    CAPCTRL 和 DACISET 将不时改变一个位、返回的值看起来在一个原因范围内。 有效 DACISET 范围介于100和300之间。

    因此、我认为校准没有任何问题。

    BTW、CE 引脚是连接到 Vcc 还是连接到 FPGA? 如果是 Vcc、请尝试将其连接到 Vcc 以查看是否有任何幸运。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好,Noel -  

    我们将 CE 引脚连接到3.3V。  但是、事实证明、我们有一个0欧姆电阻器、将 CE 连接到3.3V、而不是100K 电阻器。  也许3.3V 的噪声会导致在 CE 上使用0欧姆跳线时出现问题?

    我还注意到我们的 RampDIR 引脚被拉高而不是拉低、但 RampCLK、SysRefReq 和 SYNC_TP 都被拉低(也使用0欧姆跳线)。  我们还应该拉低 RampDIR 并为所有这些引脚使用~12K 电阻器吗?

    我尝试从我们模块的空白 PCB 开始、仅安装 PLL 和支持部件。  当我使用实验室电源为其供电时、它运行良好(频谱如下所示)。  然后、当我使用我们的模块之一通过一些导线提供的3.3V 电源为该板供电时、我会得到更近端的噪声、但未看到~2.5MHz 杂散。

    现在、我们将修改其中一个完全组装的模块、以便 PLL 的3.3V 与其他所有模块隔离。  这将让我在模块其余部分自供电的情况下尝试为该部分提供实验室电源、然后我可以尝试为 PLL 添加一些内联滤波。  我们还可以使用评估板中的值替换 CE/RampDIR/ETC 的所有0欧姆跳线。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、

    kΩ 几个 k Ω 的上拉或下拉电阻对于数字接口来说应该足够好、但它们无论如何都不消耗电流。

    好的、我发现 CE 引脚对噪声有点敏感、因此最好进行一些滤波。