LMK04832: LMK04832 programming

Beni Falk said:

1. Register 0x16e does not appear in Table 5, however it does appear in Table 77. Does it actually exist?

Yes, it actually exists. It controls PLL2_LD_TYPE (0x16E[2:0]) and PLL2_LD_MUX (0x16E[7:3]).

Beni Falk said:

2. TICS Pro software (version 1.6.10.0) includes the HSg_PD field (in the clock outputs diagram). This field is mapped to register 0x103 bit 6 (for clock output group 0_1). This field also appears in SNAU282 (LMK04832SEPEVM User's Guide from September 2022) in section 2.1.1.

 

However this field is not defined in the datasheet - there it is specified as  reserved with POR value 1.

Which is correct?

The field exists, but should be programmed to 1. I'm not sure what it does, but I recall it was an experiment for a glitchless half-step transition in dynamic digital delay that ultimately was not required, and activating it simply wastes current.

Beni Falk said:

a) Is the datasheet correct (i.e., digital delay offset for the sake of SYSREF to clock synchronization for clock divider value 6 is different from the offset needed to synchronize different clock outputs)? Or is there an error in one of these tables?

Genuinely, I have no idea how these tables were derived, and I have little confidence in their accuracy. These tables are being heavily revised and additional context is being added as part of a datasheet update that is in-progress as we speak.

We have recently discovered that divide values > 1 and < 8 do not exhibit consistent digital delay behavior at different clock distribution frequencies, with a transition between different behaviors occurring somewhere in the range of 1.6GHz (but it varies substantially between devices, maybe ±20% from recent experiments). What's more, for certain divider values, the expected delay is unpredictable a priori due to internal setup and hold issues in the divider reset process. The delay value is self-consistent, i.e. if you program the digital delay to a value, it will always produce the same phase offset after a reset; but the actual phase offset relative to any other clock in the system does not follow any predictable algorithm.

The graph below is a little busy, but it illustrates the problem: the line colors represent different DCLKX_Y_DIV values, the X axis represents different DCLKX_Y_DDLY and DCLKX_Y_HS values (enough to get at least two full delay revolutions out of the largest divide tested), and the Y axis represents the relative delay from SYSREF to device clock rising edge measured from matched length cables at an oscilloscope. For divide-by-8 and a few others we get a predictable sawtooth pattern that increments linearly and predictably. Divide-by-2, 3, and 5 have strange and unpredictable excursions.

Lest you get the impression that divide-by-6 and divide-by-7 are valid, consider the upper end of the delay range, where divide-by-6 demonstrates a similarly unpredictable pattern, and (if you count closely; (1019%7) != (20%7) ) divide-by-7 has somewhere slipped a few cycles. Divide-by-2 is omitted, for visual clarity near the last points on the graph. Only divide-by-4 and divide-by-8 appear to follow the expected pattern.

So in short, I have no idea what the SYSREF to device clock phase for a case such as divide-by-6 will be. Provided the clock distribution frequency is well above or well below 1.6GHz (note all integrated VCO frequencies are well above the questionable range), I can measure the SYSREF to device clock phase in the lab, or you can measure it in the lab, for a given set of delay values, and it will be consistent, across devices, from power cycle + sync to power cycle + sync. I can confirm that divide-by-4 and divide-by-8 or greater behaves as expected, and an a priori result could be derived for these divide values (but I don't have it at the moment - I think it is pending in the datasheet update though). I can also confirm that dynamic digital delay for device clocks always works as expected - so if you only characterize one value, and can accept some wait time while the dynamic digital delay corrects the offset of the clock to the desired value, this should be reliable. Finally, I can confirm that half-step works correctly in all cases, for all device clock divides, subtracting half a cycle. I recommend an empirical approach to find the desired phase relationship.

Beni Falk said:

b) What is the necessary adjustment when using clock divider value 1? Or is digital delay only applicable when clock divider value is greater than 1?

Since digital delay nominally operates on clock distribution path cycles, digital delay with a clock divider value of 1 is inapplicable - regardless of the delay value of other clocks, an output with a divide value of 1 will always have an edge concurrent with the other clock edges. Note that if the divider is bypassed (as in the high-performance CML bypass mode available on even-numbered outputs), as opposed to using the divide-by-1 path through the divider, the alignment becomes pure propagation delay through the device and there are no guarantees about edge alignment.

Beni Falk said:

c) What if we have several clock outputs using different divider values that need to be synchronized --and-- we have SYSREF outputs that need to be properly synchronized to clock outputs. If I understand correctly, need to do the following (for each relevant clock group):

- Adjust clock digital delay per Table 18.

- Adjust SYSREF digital delay per Table 3 using the adjusted DCLKX_Y_DDLY  value calculated in the previous step.

Am I correct?

Ideally, yes. As discussed above, this is impossible for certain cases, and I question the accuracy of that table.

In practice, it is usually more straightforward to bring a clock and a SYSREF to an oscilloscope, configure the divider, perform the SYNC, and empirically align the delays as needed. Most applications need one set of delay values for the lifetime of the application. For the rare cases where both the output frequency and the delay need to be varied across the lifetime of the application, and where divide-by-2, -3, -5, -6, or -7 are required, a single fixed delay value could be selected as the initial, predictable value, and dynamic digital delay could be used to adjust the remainder. In the pending datasheet update, such a scheme is proposed, and I believe we recommend specific digital delay values and offer some predictable guidance.

Beni Falk said:

d) Regarding equation (1) in section 8.3.5 - I need to calculate SCLKX_Y_DDLY given SYSREF_DDLY and DCLKX_Y_DDLY (rather than to calculate SYSREF_DDLY given DCLKX_Y_DDLY and SCLKX_Y_DDLY).

 

The above equation yields the following:

SCLKX_Y_DDLY = DCLKX_Y_DDLY - 1 + DCLK_DIV_ADJUST + DCLK_HS_ADJUST - SYSREF_DDLY

 

Can I use this to calculate SCLKX_Y_DDLY?

 

Note: the example provided in section 8.3.5 is problematic since it assumes SCLKX_Y_DDLY = 2, which is an invalid according to the datasheet. Am I missing something?

SCLKX_Y_DDLY = 2 is a valid value, because SCLKX_Y_DDLY is not SYSREF_DDLY. The global value SYSREF_DDLY must be ≥ 8. The local delay value can be anywhere from 2 to 11. Each channel pair includes one local SCLKX_Y_DDLY block which can be used to adjust the channels relative to each other by some small amount if needed - this is available to correct any per-channel routing length differences. If you can match cable lengths, the SCLKX_Y_DDLY term can typically be ignored, or assumed to be constant and equal across all channels.

It is generally easier to pick a SYSREF_DDLY and compute a valid clock delay, than it is to pick a clock delay and from this derive a SYSREF delay and many other clock delays. The SYSREF is typically one of the slowest clocks in the system (frequently a divide of the GCD of the outputs) and the delay can be varied across its entire period - the delay can always be made larger than one full period of any device clock, so an initial value could be arbitrarily selected that does not constrain any other device clocks, and all linear-behaving delays could be subtracted by an equal amount after the fact to minimize the total time spent in the divider reset state.

For the weird divides, either you can characterize a set of values that linearizes the delay and ensure that the desired SYSREF_DDLY and the final SYSREF_DDLY always have the same value of SYSREF_DDLY % DCLKX_Y_DIV; or you can pick a single known good value for the dividers (perhaps based on a relationship we give you in the future datasheet update) and use dynamic digital delay to adjust the clock dividers after the SYNC event.

Beni Falk said:

4. Clock divider values 2 and 3 - Table 3 and Table 18 include a note saying that to program divide by 2 or by 3, it is necessary to program divide by 4 and then back to divide by 2 or 3.

Assuming that need to program clock divider for output clock group 0_1 to 3. I plan to do the following:

- Write 4 to register 0x100

- Write 0 to register 102 bits 1:0

- Write 3 to register 0x100

 

Is this the correct way to go? Or do I need to do something else?

If you know that register 102 already has 0 in bits 1:0, you can skip that write. Otherwise, yes, this is correct.

Given the dubiousness above, it is worth pointing out that this is a separate issue - dividers are automatically reset when programming their values, but there is a piece of the divider which is not properly reset when programming the divider to 2 or 3. Programming the divider to 4 effectively resets that portion of the divider, and subsequent programming to 2 or 3 starts from the correct initial state (divide-by-4 does not subsequently modify whatever lingering state needed to be reset). So the sequence of programming to 4 before programming to 2 or 3 is required in any case to guarantee deterministic behavior between sync events.

Beni Falk said:

An additional question (5) - according to Figure 6, OSCout cannot be the output of the FB MUX. However, according to Table 27 (register 0x138 bit 4) one can set FB MUX as OSCout source.

Which is correct?

OSCout is a valid possible output destination from the FB_MUX. The FB_MUX can drive any combination of PLL2_NCLK_MUX, PLL1_NCLK_MUX, and OSCout_MUX simultaneously.

Pending datasheet update has numerous updates to the diagrams to correct a number of inaccuracies, including this one.

Beni Falk said:

2. Regarding the issue of equation (1) - as you have suggested, I want to calculate SCLKX_Y_DDLY given SYSREF_DDLY, rather than the other way around. That equation is formulated to yield SYSREF_DDLY rather than SCLKX_Y_DDLY. Can I use it to deduce SCLKX_Y_DDLY when SYSREF_DDLY is known?

Yes, it should still be usable to deduce SCLKX_Y_DDLY with the caveats mentioned about the validity of the DCLKX_Y_DIV_ADJUST for the questionable divides. Keep in mind that deriving different values for different channels will skew the SYSREF outputs between the channels - if this is the intended behavior for your system, there are no other issues arranging the equation this way.

Beni Falk said:

a) What is the minimal SYNC high pulse width that can safely be used? In case it is relevant, our VCO frequency is 2.56 GHz.

Looking at the implementation, it appears this is an asynchronous reset. The divider is a ripple counter which resets itself after the maximum value, with a pulse lasting approximately one VCO cycle in duration, so I think you can expect one VCO cycle is adequate. I think you can create a pulse much shorter than one OSCin cycle in basically all cases and the R-divider will still reset. However, there may be uncertainty in the exact cycle of the reset if the minimum setup time is not met.

From testing, the R-divider generates a pulse at the phase detector after R-1 OSCin cycles from the reset event clearing (SYNC going logic low).

Beni Falk said:

What are the minimum required setup and hold times?

As opposed to minimum pulse width described above, "setup and hold times" refers to the time before which the SYNC pin must transition to logic high state (setup time) and the amount of time it must stay there (hold time), relative to the OSCin rising edge at the input to the R-divider. We have experimentally measured the setup time across PVT as around 6ns max, 4.5ns min relative to the reference edge at OSCin. As mentioned above, the actual duration of the minimum pulse is on the order of one VCO cycle. If your SYNC pin state transitions are outside of the 4.5ns to 6ns window of uncertainty, I think there are no real concerns about hold time. But if a state transition might occur near this window, it is possible the R-divider reset may be uncertain by one OSCin cycle.

Beni Falk said:

I presume that SYNC_1SHOT_EN (register 0x143 bit 6) can't be used in conjunction with PLL2 R synchronization, or can it?

SYNC_1SHOT_EN is only applicable to the output channel divider and SYSREF divider resets. The pending datasheet update has a diagram which places the one-shot circuit in the correct location relative to other circuits, which is immediately after the SYSREF_MUX. The PLL2 R-divider reset, and for that matter the PLL1 R-divider reset when derived from SYNC pin, both branch immediately after the pin input, before the SYNC_POL inverter. You could use PLL2 R-divider reset and the SYNC one-shot concurrently, but the SYNC one-shot does not affect the R-divider reset paths.

Thanks!