LMK04821: difficulty setting up fixed digital delay

Hello,

Sorry for the delay, we will respond in 24 hours.

Regards,
Hao

Hello zvoros,

First, keep in mind that this is the fixed digital delay. No matter how many times the synchronization procedure is repeated, the phase between the two outputs should be reproducible to the same offset as long as the digital delay registers are the same value between synchronizations.

The substitute divide values can be thought of as explicitly telling the divider how long to hold the output high or low. For fixed digital delay this is essentially irrelevant because the output state is muted while the digital delay is counted. However, this becomes important for dynamic digital delay, where the output is not muted during the phase update. For dynamic digital delay, it makes sense to specify the number of VCO cycles that the output clock should remain high/low during the delay shift cycle, to better control the duty cycle of the shift period.

In the example given, the delay values sum to 8 and 9, implying that the first clock should be delayed by 8 VCO cycles and the second clock should be delayed by 9 VCO cycles. In fixed digital delay, all you will see is a single-cycle VCO delay extra before the second clock starts up, relative to the first clock. In dynamic digital delay, you will see that the second clock has a single clock cycle in which the output remains low for 5 VCO cycles, effectively creating one VCO cycle of delay on the second clock relative to the first clock.

Give me a little bit more time to decipher the register write sequence you provided; I believe I understand what's being done, but I'd like to confirm by duplicating your programming on a board in our lab. I'll aim for later today to provide an update.

Regards,

Derek Payne

Greetings Derek,

Many thanks for your feedback!

Derek Payne said:

First, keep in mind that this is the fixed digital delay. No matter how many times the synchronization procedure is repeated, the phase between the two outputs should be reproducible to the same offset as long as the digital delay registers are the same value between synchronizations.

This is clear, and this is what we need: our setup is static in the sense that once we know what the parameters are, we are not going to change them. 

I also forgot to mention in my original post that we are trying to get this done in the nested zero-delay dual-loop configuration, as shown in Fig. 20 of the data sheet. We come in with a 50-MHz reference signal, and want to generate 12.5 MHz, and 100 MHz out of this. The outputs should be phase-locked with the reference. We close the PLL through the 12.5-MHz SYSREF. 

We can set pretty much everything, frequencies, global digital delay of SYSREF, local digital delays of the SYSREF outputs, local analogue delays of both the device clock, and the SYSREF output. The only thing missing is the local digital delay of the device clock. We would like lo be able to delay the phase with respect to the SYSREF over 360 degrees, i.e., 10 ns. The analogue delays alone don't get us there. 

I have also noted that the our original sequence, which was the implementation of the instructions in Section 9.3.3. of the data sheet, didn't work reliably. I think one step was missing. I have modified the code, and now we have this: 

async function write_phase() {
    // write phase of channel 0, 0x101
    write_phase_register(257)
    await sleep(300)

    // write phase of channel 2, 0x109
    write_phase_register(265)
    await sleep(300)

    // clear 0x106
    registers['262'] = 0
    write_phase_register(262)
    await sleep(300)

    // clear 0x10e
    registers['270'] = 0
    write_phase_register(270)
    await sleep(300)

    // clear 0x144:0, 0x144:1, 0x144:7
    registers['324'] = 0
    write_phase_register(324)
    await sleep(300)

    registers['323'] = 145
    write_phase_register(323)
    await sleep(200)
    // toggle 0x143:5
    registers['323'] = 177
    write_phase_register(323)
    await sleep(2000)
    registers['323'] = 145
    write_phase_register(323)
    await sleep(3000)
    registers['323'] = 17
    write_phase_register(323)
    await sleep(200)
   
    // set 0x106:7
    registers['262'] = 128
    write_phase_register(262)
    await sleep(300)

    // set 0x10e:7
    registers['270'] = 128
    write_phase_register(270)
    await sleep(300)

    // set 0x144:0, 0x144:1, 0x144:7
    registers['324'] = 131
    write_phase_register(324)
    await sleep(300)

    console.log('wrote phase sequence')
}

With this, we can reliably set everything, except the digital delays of the device clocks. 

Zvoros,

As far as I can tell, the second sequence is doing everything correctly to set the fixed digital delays - when I test your SYNC procedure in the lab with different CNTH/CNTL values I get the expected device clock to SYSREF phase variation. I did notice that you have both CNTH/CNTL registers for 0/2 outputs set to 0 in the first block of settings, and that your sync procedure writes these registers but doesn't explicitly update them. Are you updating these as you go and trying to check the phase position of device clocks with respect to SYSREFs? For example if you perform the synchronization routine with CNTH+CNTL=4 vs if CNTH+CNTL=5, you should see a single VCO cycle difference of device clock to SYSREF phase.

Regards,

Derek Payne

Greetings Derek,

Thanks for your reply!

Derek Payne said:

I did notice that you have both CNTH/CNTL registers for 0/2 outputs set to 0 in the first block of settings, and that your sync procedure writes these registers but doesn't explicitly update them.

So, does this imply that a step is missing?  Or do you mean that you don't find the registers['265'] = ... statement in this section:

  // write phase of channel 2, 0x109
    write_phase_register(265)
    await sleep(300)

The GUI callback writes the appropriate value into the register array, hence the missing registers['265'] = ... statement. Here is the stream of values that land on the LMK, when we want to change the phase of DCLKout0, and DCLKout2: 

[65928]
[67960]
[67072]
[69120]
[82944]
[82833]
[82865]
[82833]
[82705]
[67200]
[69248]
[83075]

The first two numbers are the 0x101, and 0x109 registers, plus their respective values. These correspond to 136, and 120, i.e., these should give us digital delays equal to 16 (8 + 8), and 32 (16 + 16) VCO cycles. 

If, instead of what can be seen above, we write 

[65894]
[67960]
[67072]
[69120]
[82944]
[82833]
[82865]
[82833]
[82705]
[67200]
[69248]
[83075]

we should get 12 (6 + 6), and 32 (16 + 16) VCO cycles, respectively, i.e., if we measure the phase between SDCLKout1, and DCLKout0, we should see an extra phase shift of approx. 2400 ps (we run on the 3-GHz VCO with a divider of 2). Yet, there is absolutely nothing.

I presume, the settings of the second output are irrelevant, since we are measuring phases between SDCLKout1, and DCLKout0, and we trigger the oscilloscope on SDCLKout1. The phase of SDCLKout1 is locked to the 50-MHz reference signal, as it should be.

I believe, we can also rule out problems with the communication between the PC and the LMK, because all other settings result in changes that we would expect. I understand that we are working with a custom piece of hardware and out own software, and not the evaluation board, but I think we a number of debug options, and all seem to indicate that we are all right in this regard. 

Zvoros,

Thanks for the clarification, I meant the registers['265']=... portion and it is clear to me that the appropriate registers are being written to change the delay. No step missing there.

Upon double-checking, I don't see a write to register 0x139 (313) to change the state of the SYSREF_MUX. The original value you used to program the SYSREF_MUX is to continuous SYSREF, which suggests that the SYSREF divider output is being used as the SYNC signal instead of the toggling of the SYNC_POL bit. While historically I haven't seen issues with using the SYSREF divider output as its own source, but it doesn't seem like this was your intention, and I suspect it might be part of the cause of your trouble. Do results change if SYSREF_MUX is set to 0 (normal SYNC) during the SYNC procedure, before clearing the bits in 0x144?

Regards,

Derek Payne