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.

LMK04828: Glitchless half step sometimes glitches

Part Number: LMK04828

I have DCLKout10_HSg_PD = 0, DCLKout10_MUX = 3 (with DCLKout10_DIV = 5, VCO_MUX = 0), and I am applying the half step adjustment by writing to DCLKout10_HS (to be precise, writing 00 or 40 to register 12C).  Unfortunately "glitchless" doesn't describe the behaviour I'm seeing, see the capture below:

Am I configuring things wrong, or is the description "glitchless" a trifle over optimistic?

  • Hello Michael,
    Glitchless half step will ensure that there is no cycle with glitch or very small duty cycle. The half cycle shift is applied when the clock phase is low, that's you see the low phase for another half cycle. This is expected behavior.
    Best regards
    Puneet
  • I beg your pardon? I see an entire missing output clock cycle. I don't call that a glitchless half cycle step. Don't forget that the "half cycle" is a half cycle of the VCO0 clock, not the divided output clock.

    This behaviour is intermittent and very unpredictable. If you think this is expected and documented behaviour, I suggest you think again. Sometime dropping a complete clock cycle, sometimes not ... interesting and unhelpful behaviour.

    For what it's worth, the "glitchless" analogue delay is indeed glitchless, and similarly "glitchless" Dynamic Digital Delay is reliable and glitchless ... for increasing phase, but not decreasing phase (see posting elsewhere).
  • Hello Michael

    My apologies, I understand your issue now. For Half step to work reliable, you should be using DCLKout10_MUX = 1. Please try that. If you are still not seeing the proper behavior, please post your TICSpro config file or register configuration.


     

    Best regards
    Puneet

  • Well, that was interesting.  This is what I see:

    Here is my register configuration:

    PLL[000] <= 80
    PLL[100] <= 00
    PLL[101] <= 55
    PLL[102] <= 55
    PLL[103] <= 00
    PLL[104] <= 00
    PLL[105] <= 00
    PLL[106] <= f9
    PLL[107] <= 30
    PLL[108] <= 00
    PLL[109] <= 55
    PLL[10a] <= 55
    PLL[10b] <= 00
    PLL[10c] <= 20
    PLL[10d] <= 00
    PLL[10e] <= f0
    PLL[10f] <= 11
    PLL[110] <= 05
    PLL[111] <= 33
    PLL[112] <= 33
    PLL[113] <= 07
    PLL[114] <= 00
    PLL[115] <= 00
    PLL[116] <= 01
    PLL[117] <= 01
    PLL[118] <= 00
    PLL[119] <= 55
    PLL[11a] <= 55
    PLL[11b] <= 00
    PLL[11c] <= 00
    PLL[11d] <= 00
    PLL[11e] <= f9
    PLL[11f] <= 01
    PLL[120] <= 05
    PLL[121] <= 55
    PLL[122] <= 55
    PLL[123] <= 00
    PLL[124] <= 00
    PLL[125] <= 00
    PLL[126] <= f1
    PLL[127] <= 00
    PLL[128] <= 05
    PLL[129] <= 55
    PLL[12a] <= 55
    PLL[12b] <= 07
    PLL[12c] <= 00
    PLL[12d] <= 00
    PLL[12e] <= 01
    PLL[12f] <= 03
    PLL[130] <= 05
    PLL[131] <= 55
    PLL[132] <= 55
    PLL[133] <= 00
    PLL[134] <= 00
    PLL[135] <= 00
    PLL[136] <= f1
    PLL[137] <= 30
    PLL[138] <= 00
    PLL[139] <= 00
    PLL[13a] <= 0c
    PLL[13b] <= 00
    PLL[13c] <= 00
    PLL[13d] <= 08
    PLL[13e] <= 03
    PLL[13f] <= 0b
    PLL[140] <= 00
    PLL[141] <= 00
    PLL[142] <= 00
    PLL[143] <= 91
    PLL[144] <= 00
    PLL[145] <= 7f
    PLL[146] <= 10
    PLL[147] <= 1b
    PLL[148] <= 02
    PLL[149] <= 42
    PLL[14a] <= 02
    PLL[14b] <= 16
    PLL[14c] <= 00
    PLL[14d] <= 00
    PLL[14e] <= 00
    PLL[14f] <= 7f
    PLL[150] <= 03
    PLL[151] <= 02
    PLL[152] <= 00
    PLL[153] <= 00
    PLL[154] <= 78
    PLL[155] <= 00
    PLL[156] <= 0d
    PLL[157] <= 00
    PLL[158] <= 96
    PLL[159] <= 00
    PLL[15a] <= 0d
    PLL[15b] <= df
    PLL[15c] <= 20
    PLL[15d] <= 00
    PLL[15e] <= 00
    PLL[15f] <= 0b
    PLL[160] <= 00
    PLL[161] <= 3d
    PLL[162] <= 45
    PLL[163] <= 00
    PLL[164] <= 01
    PLL[165] <= 7d
    PLL[171] <= aa
    PLL[172] <= 02
    PLL[17c] <= 15
    PLL[17d] <= 33
    PLL[166] <= 00
    PLL[167] <= 01
    PLL[168] <= 7d
    PLL[169] <= 59
    PLL[16a] <= 20
    PLL[16b] <= 00
    PLL[16c] <= 00
    PLL[16d] <= 00
    PLL[16e] <= 13
    PLL[173] <= 00
    PLL[143] <= 11
    
    # Switch DCLKout10_MUX as advised
    PLL[12b] <= 05
    
    # Repeat the following two assignments
    PLL[12c] => 00
    PLL[12c] => 40
    

    I would note that, at least according to my understanding of figure 7 of SNAS703 (or figure 12 of SNAS605AR) selecting DCLKoutX_MUX = 3 should produce glitchless half-step operation so long as DCLKoutX_ADLY_MUX is set to 1 (which it is).

  • Drat: obvious error in the register log, the last two lines should be assignments, not readouts. Actually, my code does read/modify/write cycles, which I was trying to elide (but only from line 121 above onwards), but I have previously verified that this makes no difference.

    For what it's worth, here are my device identification registers:

    PLL[003] => 06
    PLL[004] => d0
    PLL[005] => 5b
    PLL[006] => 20
    PLL[00c] => 51
    PLL[00d] => 04
  • Hi Michael
    Let me check your configuration.
    Glitchless half step is only ensured in DCC&HS path. For this to work, Digital Delay should be enabled (DDLY_PD=0), DCLKoutX_ADLY_MUX=1, and SYNC should be enabled.
    Best regards
    Puneet
  • > Let me check your configuration.

    Yes, please do.  I have set everything as you have asked ... which you would have been able to tell if you'd actually looked at the register settings you asked me to provide.

    Can I suggest you let someone who understands this device well have a close look at the second oscilloscope trace I posted in this thread.  It is extremely ugly and quite reproducible.  Whether this is

    1. a fault in my device
    2. a programming error on my part
    3. outside of specified behaviour

    needs to be identified.  If 1 I'm out of luck, if 2 please help, if 3 please fix the documentation!

  • I'd be grateful for a follow up on this. I can confirm this behaviour (at 500 MHz output clock) on three different systems. I've asked for a colleague working with a different system running at 352 MHz output to see if they see the same behaviour and will update.
  • Dear Michael,

    my apology for the delay getting back to you on this issue.

    After verification, It turns out we do have an issue with the glitch-less feature. We have not found a work around with this feature. I am looking into this and see what can be done. Would you be able to work without that feature?

    Regards, Simon.
  • Thank you for your response, it's very much appreciated, and I'm grateful for the confirmation that it is a problem with the feature.

    Yes, I can work without the feature.  I have enough control over the clocking delay with a combination of dynamic digital delay (phase delay only, sigh, see related posting) and the analogue delay.  The half-step seemed to provide an extra convenience, but I guess I'll have to delete it from my interface.

  • Hello Michael,
    Like Simon mentioned, there is no workaround found for glitchless HS. Your register configuration led us to investigate and we were able to reproduce the behavior you posted in two pictures.
    We will be removing this glitchless feature from the datasheet. I apologize for the inconvenience.
    Best regards
    Puneet