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.

LMX2594: Problem with reference input

Part Number: LMX2594


Hello,

I am using an FPGA development board that contains the LMX2594 chip. On the board, there is the option to provide the LMX2594 with an on-board reference, or an external reference. The on-board reference works, because my design boots and I can see the firmware work, however the external reference does not seem to work because my design doesn't boot and the firmware doesn't work. So I wanted to ask about my external reference clock setup. I feed in a single-ended 10MHz sine wave at 0dBm (around 0.6Vpeak) into the OSCinP pin, and do not provide an input to the OSCinN pin. My board design programs the LMX with the appropriate register/data values, as attached. It seems like I am doing something wrong with the reference clock, I just can't figure out what. Do you have any ideas?

Thanks

R112	0x700000
R111	0x6F0000
R110	0x6E0000
R109	0x6D0000
R108	0x6C0000
R107	0x6B0000
R106	0x6A0000
R105	0x690021
R104	0x680000
R103	0x670000
R102	0x663F80
R101	0x650011
R100	0x640000
R99	0x630000
R98	0x620200
R97	0x610888
R96	0x600000
R95	0x5F0000
R94	0x5E0000
R93	0x5D0000
R92	0x5C0000
R91	0x5B0000
R90	0x5A0000
R89	0x590000
R88	0x580000
R87	0x570000
R86	0x560000
R85	0x55D300
R84	0x540001
R83	0x530000
R82	0x521E00
R81	0x510000
R80	0x506666
R79	0x4F0026
R78	0x4E0003
R77	0x4D0000
R76	0x4C000C
R75	0x4B09C0
R74	0x4A0000
R73	0x49003F
R72	0x480001
R71	0x470081
R70	0x46C350
R69	0x450000
R68	0x4403E8
R67	0x430000
R66	0x4201F4
R65	0x410000
R64	0x401388
R63	0x3F0000
R62	0x3E0322
R61	0x3D00A8
R60	0x3C0000
R59	0x3B0001
R58	0x3A8001
R57	0x390020
R56	0x380000
R55	0x370000
R54	0x360000
R53	0x350000
R52	0x340820
R51	0x330080
R50	0x320000
R49	0x314180
R48	0x300300
R47	0x2F0300
R46	0x2E07FC
R45	0x2DC0DF
R44	0x2C1F02
R43	0x2B03E0
R42	0x2A0000
R41	0x290000
R40	0x280000
R39	0x2703E8
R38	0x260000
R37	0x250204
R36	0x24031F
R35	0x230004
R34	0x220000
R33	0x211E21
R32	0x200393
R31	0x1F43EC
R30	0x1E318C
R29	0x1D318C
R28	0x1C0488
R27	0x1B0002
R26	0x1A0DB0
R25	0x190624
R24	0x18071A
R23	0x17007C
R22	0x160001
R21	0x150401
R20	0x14E048
R19	0x1327B7
R18	0x120064
R17	0x11012C
R16	0x100080
R15	0x0F064F
R14	0x0E1E70
R13	0x0D4000
R12	0x0C5001
R11	0x0B0018
R10	0x0A10D8
R9	0x090604
R8	0x082000
R7	0x0740B2
R6	0x06C802
R5	0x0500C8
R4	0x040A43
R3	0x030642
R2	0x020500
R1	0x010808
R0	0x00241C

  • Hello Cameron,

    First, when using the input pins single-ended, the unused pin should be terminated to GND through 0.1µF and 50Ω in series. Second, ensure that the on-board oscillator is not switching while the external reference is brought in, as this may be creating crosstalk or affecting the reference monotonicity.

    I reviewed the registers and I see that you have MASH_RESET_N held low - this is holding the fractional divider in reset, so it may not be able to lock to the VCO frequency you appear to have programmed (7999.92MHz). Is this intentional?

    Note that 10MHz sine wave with 0.6Vpk amplitude will have a slew rate of SR = 2π * f * Vpk = 6.28 * 1e7 * 0.6 = about 0.038V/ns; this slew rate may be too low to lock the device or it may impact the slew rate. I see that the on-board oscillator appears to be a higher slew rate format which could explain why the on-board reference works but the external does not. If you have a 10MHz square wave source, or an RF divider that can reduce a higher-frequency external source, you could test this to see if it locks.

    Regards,

    Derek Payne

  • Derek,

    Thank you for such a quick response! The on-board oscillator was already disconnected via the removal of the 0.1uF capacitors, so I know that's not affecting things. However the necessity of grounding the unused pin is good to know, I had thought that maybe that was taken care of on the board, but I'm guessing not.

    I did not mean to have the MASH_RESET_N held low, so I changed that and will see next week how that changes things.

    Before making the original post, I had tried with 160MHz, but that didn't work either, but that makes sense due to the lack of the grounding on the unused pin. 

    I'll get the changes made to the board and see what happens next week, I'll let you know.

    Thanks again 

  • Derek,

    Turns out I had misunderstood the circuit on the board, and the unused pin is actually connected to ground via a series 50ohm resistor and 0.1uF cap. I tried setting the MASH_RESET_N high, but that didn't change anything. I tried that with the 160MHz oscillator as well as with a 10MHz square wave. Do you have any other ideas? 

    Thanks

  • Hi Cameron,

    What is your on-board reference clock frequency? if the external reference clock frequency is same as on-board reference clock frequency, will it lock?

    Look like your on-board reference clock can be disabled with the OE pin, could you disable it to eliminate possible interference?

  • Cameron,

    After you set MASH_RESET_N high, did you either load all registers again or toggle the FCAL_EN bit? This would be required since the MASH was in reset and the VCO failed to calibrate to the correct frequency.

    Are you programming the device with OSCin applied? The internal state machine requires the OSCin signal to be applied, and a lot of SPI will not work unless OSCin is applied prior to programming. 

    Regards,

    Derek Payne

  • Noel and Derek,

    Thanks for the replies. I believe that I have successfully programmed the LMX to generate the desired clock via the off-board reference clock. However I don't think that the output clock is synched with the reference clock.

    I see that there is the register VCO_PHASE_SYNC, would enabling that during programming phase sync the output clock with the reference clock? Are there other registers that I could read back to determine if the output is phase synced/locked to the reference clock? 

    For reference, this chip is used on an FPGA board, and the scripts that program the LMX run during startup at the very beginning, before the rest of the board boots up, so I can't rerun the scripts after that.

    Thanks,

    Cameron

  • I realized that maybe my issue is that the frequency I was generating was 249.995MHz instead of 250MHz, which is leading to a lack of synchronization with my system. Could you verify that these register settings are appropriate for producing 250MHz from 160MHz? I believe it should be fine, but I don't know about the Fraction being 0/1. 

    Thanks!

    R112	0x700000
    R111	0x6F0000
    R110	0x6E0000
    R109	0x6D0000
    R108	0x6C0000
    R107	0x6B0000
    R106	0x6A0000
    R105	0x690021
    R104	0x680000
    R103	0x670000
    R102	0x663F80
    R101	0x650011
    R100	0x640000
    R99	0x630000
    R98	0x620200
    R97	0x610888
    R96	0x600000
    R95	0x5F0000
    R94	0x5E0000
    R93	0x5D0000
    R92	0x5C0000
    R91	0x5B0000
    R90	0x5A0000
    R89	0x590000
    R88	0x580000
    R87	0x570000
    R86	0x560000
    R85	0x55D300
    R84	0x540001
    R83	0x530000
    R82	0x521E00
    R81	0x510000
    R80	0x506666
    R79	0x4F0026
    R78	0x4E0003
    R77	0x4D0000
    R76	0x4C000C
    R75	0x4B09C0
    R74	0x4A0000
    R73	0x49003F
    R72	0x480001
    R71	0x470081
    R70	0x46C350
    R69	0x450000
    R68	0x4403E8
    R67	0x430000
    R66	0x4201F4
    R65	0x410000
    R64	0x401388
    R63	0x3F0000
    R62	0x3E0322
    R61	0x3D00A8
    R60	0x3C0000
    R59	0x3B0001
    R58	0x3A8001
    R57	0x390020
    R56	0x380000
    R55	0x370000
    R54	0x360000
    R53	0x350000
    R52	0x340820
    R51	0x330080
    R50	0x320000
    R49	0x314180
    R48	0x300300
    R47	0x2F0300
    R46	0x2E07FC
    R45	0x2DC0DF
    R44	0x2C1F22
    R43	0x2B0000
    R42	0x2A0000
    R41	0x290000
    R40	0x280000
    R39	0x270001
    R38	0x260000
    R37	0x250204
    R36	0x240032
    R35	0x230004
    R34	0x220000
    R33	0x211E21
    R32	0x200393
    R31	0x1F43EC
    R30	0x1E318C
    R29	0x1D318C
    R28	0x1C0488
    R27	0x1B0002
    R26	0x1A0DB0
    R25	0x190624
    R24	0x18071A
    R23	0x17007C
    R22	0x160001
    R21	0x150401
    R20	0x14E048
    R19	0x1327B7
    R18	0x120064
    R17	0x11012C
    R16	0x100080
    R15	0x0F064F
    R14	0x0E1E70
    R13	0x0D4000
    R12	0x0C5001
    R11	0x0B0018
    R10	0x0A10D8
    R9	0x090604
    R8	0x082000
    R7	0x0740B2
    R6	0x06C802
    R5	0x0500C8
    R4	0x040A43
    R3	0x030642
    R2	0x020500
    R1	0x010808
    R0	0x00241C
    

  • Cameron,

    Whoops... I asked about the VCO frequency, but perhaps I should've asked about the output frequency instead.

    The divider settings look correct for 160MHz in, 250MHz out. That said, there are a few other optimizations I would make:

    • Set FCAL_HPFD_ADJ = 2 (150<=Fpd<=200). This is the high-pass filter on the FPD input, and if it's too low for the programmed FPD, the PLL may perform strangely.
    • ACAL_CMP_DLY set to 16, because this improves VCO phase noise after calibration (changes the number of state machine clock cycles, in this case Fosc cycles, used to measure the VCO amplitude for correct level calibration)
    • Since you're not using the fraction, you can set MASH_ORDER = 0 (integer mode) which disables the fraction entirely.
    • Changing MASH_ORDER=0 for integer mode should go along with changing PFD_DLY_SEL=1 (changes the duration of the PFD pulses. The MASH works by dynamically adjusting the N-divide value by some pseudorandom magnitude of VCO cycles as determined by the MASH order, so as the MASH order increases we need to make the FPD pulses longer to help smooth and overlap the PFD pulses for better charge balance and lower spurs. Integer mode doesn't make any dynamic adjustments to the N-divider, so the pulse duration at the PFD can be as short as possible without issues.)

    I've attached the .tcs file from TICS Pro with my changes below. This file should work to produce 250MHz from 160MHz input.

    LMX2594_250MHz_160MHzext_TI.tcs

    Regards,

    Derek Payne

  • Fantastic, thank you for the thorough edits and TICS file! I'll give that a shot next week and hopefully mark this as resolved!