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.

LMK04610: Can't generate Sysref Pulses while bypassing both PLL1 and PLL2

Part Number: LMK04610

Hello,

I have been facing an issue with the use of the LMK04610.
I am using the LMK04610 on both the LMK04610 evaluation board and a specific board.

The aim is to configure some outputs in order to generate specific clock frequency (e.g. : 104MHz) while bypassing both PLLs to keep phase noise as low as possible, but we also would like to be able to generate SYSREF pulses on SPI programming. Since the SYSREF_REQ also is clocked by PLL clock, it's not possible to use bypass mode (Clock Distribution Mode).
Thus we choose to configure the LMK04610 device in Single loop PLL2 operating mode (ref = CLKINx, Oscout =PLL2_output) while also enabling PLL2_CLKin to OUTCHX.

We tested this configuration on the LMK04610 evaluation board with TICS PRO software with the following settings:

• PLL2 settings
o CLKin0 = 624MHz,
o PLL2_RDIV = 6
o PLL2 PD = 104MHz < 250Mhz
o PLL2 OSC = 5928Mhz (VCO frequency range : 5870 MHz to 6175 MHz)
o PLL2_PRESCALER = 3
o PLL2_NDIV = 19
o PLL2 CLKOUT0=CLKOUT1=5928/6= 1976MHz

• CHANNELS/OUTPUTS

CLK outputs
o 16 bit CHANNEL DIVIDER = 6=> 624/6= 104MHz
o CHx_SYSREF_REQ/SYSREF_EN=0, SYNC_EN=1

SYSREF outputs
o 16 bit CHANNEL DIVIDER = 12=> 624/12=52MHz
o SYSREF Pulse counter = 1, CHx_SYSREF_REQ/SYSREF_EN=1, SYNC_EN=1
o PLL2_REF_DIGCLK_DIV = 32 ,
o PLL2 PD =104MHz/32=3.25Mhz < « sysref output frequency : 52MHz »


The problem is that the PLL2 isn't locked. As suggested in another thread : "Please note that it is not possible to trigger a SYSREF pulse in distribution mode unless a clock is present on the output of the PLL2 prescaler, implying a need to lock PLL2 (regardless of whether PLL2 is used)." Still, we seem to observe satisfying results.

What do you think about this configuration? Could we use this settings even if the PLL2 isn't properly locked?

We tested the same setup on our specific board, we obtained the same results except that after 1 sysref pulse generation the GLOBAL_SYSREF bit is stuck at 1.
According to the datasheet, the GLOBAL_SYSREF bit is cleared automatically after fulfilling the SYSREF request (self clearing bit). When we try to rewrite GLOBAL_SYSREF to 0 it doesn't work either.
Global sysref being at 1, we can no more trigger sysref pulse. This problem doesn't happen with the evalboard.

Here is a copy of the register programming.

Could you please provide us some support and let us know what we are missing?

Best regards,

Philippe

conf_624MHz.txt
0x0000	00
0x0001	00
0x0002	00
0x0003	46
0x0004	38
0x0005	03
0x0006	11
0x0007	00
0x0008	00
0x0009	00
0x000A	00
0x000B	00
0x000C	51
0x000D	08
0x000E	00
0x000F	00
0x0010	1E
0x0011	00
0x0012	04
0x0013	00
0x0014	00
0x0015	08
0x0016	28
0x0017	00
0x0018	00
0x0019	29
0x001A	3A
0x001F	00
0x0020	78
0x0021	00
0x0022	78
0x0027	14
0x0028	08
0x0029	14
0x002A	08
0x002B	00
0x002C	80
0x002D	00
0x002E	14
0x002F	08
0x0030	01
0x0031	0C
0x0032	00
0x0033	00
0x0034	43
0x0035	10
0x0036	03
0x0037	14
0x0038	43
0x0039	10
0x003A	03
0x003B	00
0x003C	02
0x003D	18
0x003E	63
0x003F	00
0x0040	63
0x0041	18
0x0042	03
0x0043	00
0x0044	06
0x0045	00
0x0046	06
0x0047	00
0x0048	06
0x0049	00
0x004A	0C
0x004B	00
0x004C	06
0x004D	00
0x004E	06
0x004F	00
0x0050	0C
0x0051	00
0x0052	0C
0x0053	00
0x0054	30
0x0055	00
0x0056	0D
0x0057	18
0x0058	3F
0x0059	61
0x005A	0A
0x005B	02
0x005C	CA
0x005D	00
0x005E	00
0x005F	61
0x0060	A8
0x0061	00
0x0062	78
0x0063	00
0x0064	40
0x0065	00
0x0066	00
0x0067	00
0x0068	00
0x0069	00
0x006A	09
0x006B	01
0x006C	07
0x006D	08
0x006E	3F
0x006F	06
0x0070	00
0x0071	00
0x0072	1A
0x0073	00
0x0074	13
0x0075	00
0x0076	06
0x0077	01
0x0078	FF
0x0079	00
0x007A	86
0x007B	A0
0x007C	08
0x007D	00
0x007E	00
0x007F	34
0x0080	00
0x0081	00
0x0082	00
0x0083	00
0x0084	0F
0x0085	01
0x0086	01
0x0087	00
0x0088	40
0x0089	00
0x008A	00
0x008B	40
0x008C	00
0x008D	00
0x008E	00
0x008F	40
0x0090	00
0x0091	00
0x0092	80
0x0093	80
0x0094	04
0x0095	00
0x0096	10
0x0097	20
0x0098	20
0x0099	80
0x009B	00
0x009C	20
0x00AB	00
0x00AC	00
0x00AD	00
0x00AF	01
0x00B0	01
0x00BE	03
0x00F6	00
0x00F7	00
0x00F9	07
0x00FA	D7
0x00FC	00
0x00FD	00
0x00FE	00
0x00FF	00
0x0100	00
0x0101	00
0x0102	00
0x0103	00
0x0104	00
0x0105	00
0x0106	00
0x0107	00
0x0108	00
0x0109	00
0x010A	00
0x010B	00
0x010D	00
0x010E	00
0x0110	00
0x0111	00
0x0112	00
0x0115	00
0x0116	00
0x0117	00
0x0119	00
0x011A	00
0x0124	08
0x0127	24
0x0128	21
0x0129	25
0x012A	21
0x012B	04
0x012C	25
0x012D	24
0x012E	21
0x0130	05
0x0131	05
0x0133	05
0x0134	05
0x0135	05
0x0138	05
0x0139	05
0x013A	05
0x013C	05
0x013D	05
0x0140	01
0x0141	09
0x0142	40
0x0143	00
0x0145	00
0x0146	00
0x0149	00
0x014A	00
0x014B	00
0x014C	00
0x014E	C8
0x0150	00
0x0151	04
0x0152	07
0x0153	00

  • Hello Philippe,

    Thus we choose to configure the LMK04610 device in Single loop PLL2 operating mode (ref = CLKINx, Oscout =PLL2_output) while also enabling PLL2_CLKin to OUTCHX.

    So do I understand on the Operating Modes page, you pressed "Single Loop PLL2" (red or green button).  Then Bypass1 (green) or Bypass 2B (blue) button?

    What do you think about this configuration? Could we use this settings even if the PLL2 isn't properly locked?

    I think you are on the right path.  However I don't think there is a reason to settle for PLL2 not locking properly, so we should identify and correct the issue.

    According to the datasheet, the GLOBAL_SYSREF bit is cleared automatically after fulfilling the SYSREF request (self clearing bit). When we try to rewrite GLOBAL_SYSREF to 0 it doesn't work either.
    Global sysref being at 1, we can no more trigger sysref pulse. This problem doesn't happen with the evalboard.

    Ok, thanks for this information.

    Are you satisfied with the phase noise performance of the buffered outputs?

    Do you happen to have the .TCS file from TICS Pro you could attach?

    If we need to attempt re-production of this issue, is next week acceptable?

    73,
    Timothy

  • Hello Timothy,

    Thank you for your quick reply.

    So do I understand on the Operating Modes page, you pressed "Single Loop PLL2" (red or green button).  Then Bypass1 (green) or Bypass 2B (blue) button?

    Not exactly. We followed the LMK04610 Evaluation board guide and choose in the GUI: Operating Modes tab, the Single loop PLL2 operating mode (green ref = CLKINx, Oscout =PLL2_output). Then in the GUI : PLL2 controls tab we changed the settings for PLL2_BOTTOM and PLL2_TOP to CLKin.

    Are you satisfied with the phase noise performance of the buffered outputs?

    Yes. When the PLL1 and PLL2 are bypassed, the phase noise meets our performances specifications.

    Do you happen to have the .TCS file from TICS Pro you could attach?

    Please find below a copy of the .TCS file used.

    conf_624MHz.tcs

    If we need to attempt re-production of this issue, is next week acceptable?

    Yes, it's not urgent as we won't focus our effort on this subject next week. You could have a certain amount of time and leeway if you need to reproduce the issue. I will wait for your investigations and results.

    Best regards,

    Philippe

  • Ok, very good Philippe.  I'll keep you posted.

    73,
    Timothy

  • Hello Philippe,

    it is ok that PLL2 is not locked for SYSREF generation. But it should be locked.

    Not exactly. We followed the LMK04610 Evaluation board guide and choose in the GUI: Operating Modes tab, the Single loop PLL2 operating mode (green ref = CLKINx, Oscout =PLL2_output). Then in the GUI : PLL2 controls tab we changed the settings for PLL2_BOTTOM and PLL2_TOP to CLKin.

    Before enabling the bypass mode, does the PLL2 lock in this state?

    Regards,

    Julian

  • Philippe,

    We haven't heard from you in a while, so I'm going to mark this thread as resolved. You can make another post to re-open the thread if you still have questions on this topic.

    Regards,

    Derek Payne

  • Hi Derek,

    Sorry for the delay, Philippe is in vacation since beginning of May until the end of this week. He will be working on this as soon as he will come back.

    Thank you for your support.

    Best regards,

    Dilan

  • Hi Derek,

    I am sorry for the inconvenience. I am back and will resume the investigation about this problem starting this week. Should I make another post to re-open the thread?

    Best regards,

    Philippe

  • Hi,

    I don't know if the thread is still active. Thanks for your help concerning the unlocked PLL2.

    it is ok that PLL2 is not locked for SYSREF generation. But it should be locked.
    Before enabling the bypass mode, does the PLL2 lock in this state?

    The PLL2 isn't locked before enabling the bypass mode.

    Were you able to re-produce the issue? Is there any other test we could do?

    Since we are able to generate sysref, it isn't a blocking problem on our part.

    Also, I would like to ask for your help concerning the second problem described :

    We tested the same setup on our specific board, we obtained the same results except that after 1 sysref pulse generation the GLOBAL_SYSREF bit is stuck at 1.
    According to the datasheet, the GLOBAL_SYSREF bit is cleared automatically after fulfilling the SYSREF request (self clearing bit). When we try to rewrite GLOBAL_SYSREF to 0 it doesn't work either.
    Global sysref being at 1, we can no more trigger sysref pulse. This problem doesn't happen with the evalboard.

    Best regards,

    Philippe

  • Hi Derek,

    I made others post in order to re-open the thread but maybe I've made a mistake and answered my own post.

    I don't know if the thread is still active. Thanks for your help concerning the unlocked PLL2.

    it is ok that PLL2 is not locked for SYSREF generation. But it should be locked.
    Before enabling the bypass mode, does the PLL2 lock in this state?

    The PLL2 isn't locked before enabling the bypass mode.

    Were you able to re-produce the issue? Is there any other test we could do?

    Since we are able to generate sysref, it isn't a blocking problem on our part.

    Also, I would like to ask for your help concerning the second problem described :

    We tested the same setup on our specific board, we obtained the same results except that after 1 sysref pulse generation the GLOBAL_SYSREF bit is stuck at 1.
    According to the datasheet, the GLOBAL_SYSREF bit is cleared automatically after fulfilling the SYSREF request (self clearing bit). When we try to rewrite GLOBAL_SYSREF to 0 it doesn't work either.
    Global sysref being at 1, we can no more trigger sysref pulse. This problem doesn't happen with the evalboard.

    Best regards,

    Philippe