https://e2e.ti.com/support/clock-timing-group/clock-and-timing/ Products covered in this section are Clock Generation & Distribution, Memory Interface, Registers, Real Time Clocks and Timers. en-USTelligent Community 13https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1669118/lmk04832-lmk04832-spi-interface-cannot-read-back-data/6434567Thu, 30 Jul 2026 14:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:906e9ef3-0ef5-4b7b-8cca-053806adbd0fDerek PayneDo you have SPI_3WIRE_DIS disabled (0x0[4] = 0)? Is NLSX5014 capable of bidirectional open-drain signaling with the chosen pull-up? The datasheet indicates the input driver should be capable of driving 2mA, but 4.7kΩ pull-up on a 3.3V supply is only 0.7mA. I wonder if the open-drain current is not high enough in the SDIO logic-HIGH output state, and the voltage change produced by the SDIO logic-LOW output state is too small, which prevents the bidirectional circuit from detecting a direction change. You could try a smaller pull-up, e.g. 1kΩ, on SDIO pin, to satisfy the 2mA input driver requirement. You could also try setting SDIO_RDBK_TYPE to push-pull instead of open-drain (0x149[6] = 0 instead of 1), which should source more than enough current to reliably trigger the direction change.https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1669118/lmk04832-lmk04832-spi-interface-cannot-read-back-dataThu, 30 Jul 2026 12:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:de85448c-bcc3-45e0-83ad-b480f3000630jeno.zhangPart Number: LMK04832 Hello, The FPGA is connected to LMK04832 through level conversion. The schematic diagram and test waveform are as follows. The FPGA can write to LMK04832 normally through the level conversion chip, and LMK04832 can output the clock normally. But there is no response when reading back the data. Please help analyze the reasons. Thank you.Industrial AutomationLMK04832https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1662259/lmx2594-can-we-configure-lmx2594-differential-rf-output-power-is-10dbm/6434115Thu, 30 Jul 2026 06:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1f55c3d7-661d-466a-b39f-856006bdb6d5Jifei ChenHello， what's the RF output impedance of LMX2594 EVB circuit? I want to have 50R output impedance at RF output terminal. thanks! ...https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1662259/lmx2594-can-we-configure-lmx2594-differential-rf-output-power-is-10dbm/6434110Thu, 30 Jul 2026 06:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e28ee80d-dd9a-43e5-af40-c5f39cdaa620Jifei ChenHello， what's the RF output impedance of LMX2594 EVB circuit? I want to have 50R output impedance at RF output terminal. thanks!https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1668928/lmx2820-phase-shift-between-outputsThu, 30 Jul 2026 06:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:43d4140a-ffb6-411c-8300-2ae56e695a1eKonstantin BatechkoPart Number: LMX2820 hello Is it possible to achieve a 90° phase shift between outputs A and B in the LMX2820? Or is there another synthesizer with VSO that can implement this phase shift? Thank you.LMX2820https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1668731/cdce62002-cdce62002-possibility-of-increased-pll-lock-time-near-the-lower-vco-operating-limit/6433798Thu, 30 Jul 2026 00:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4004f3da-6b32-4c50-a095-468c94b8f2b5Sandra SabaHi Ishiwata, i will look into the issue and get back to you early next week with some feedback. in the meantime please help share over email a register readback and the schematics. Best, Sandrahttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667999/lmk04228-clock-generator-selection/6433795Thu, 30 Jul 2026 00:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7c9c8003-c47f-4d3f-9d77-5855176a9b05Michael SrinivasanHi Nishant, Unfortunately, we do not have any automotive grade differential oscillators. What might work instead would be one of our automotive grade oscillators, like the CDC6C-Q1, being sent through a SN65LVDS9638. Thanks, Michaelhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666881/cdce913-q1-power-sequence/6433797Thu, 30 Jul 2026 00:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:466a6dfc-41f0-42c8-a0f8-0bf43820a422Sandra SabaThanks, i am still looking into the issue and will have some feedback by next week Best, Sandrahttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1668807/lmk05318-hcsl-differential-output-range/6433574Wed, 29 Jul 2026 20:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:078a0fad-a8dd-406d-bcef-4ba717cc5beaConnor LewisHi Faizul, We don't have a spec for crossing point voltage on this device. The differential peak-peak voltage will be 2 * (VOH - VOL). Let me know if you have any other questions on this.https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433567Wed, 29 Jul 2026 20:07:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c3ec9931-6fe8-4fdd-bb94-cc9ed2483c80Derek Payne[quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"]Yet your written guidance says the SYSREF-divider feedback re-times the SYNC to the SYSREF-divider edge with a valid window of almost a full SYSREF period, issued at GCD(input, outputs) — which for us is 78.125 kHz. Can you reconcile these?[/quote] We can re-time the SYNC event with a large valid window. But if the SYSREF divider timing is still unknown with respect to the input, having a larger SYNC window doesn't help establish a single deterministic input-to-output phase. A bit further down the flowchart, we ask F ZDM % F OSC == 0, and if not, SYNC is not possible because the R-divider randomizes input-to-output phase with R possible combinations. In your case, 9.765625MHz % 10MHz != 0, so you are unable to reliably synchronize because of the many possible phases of the R and N dividers. You'll notice that the same flowchart for the LMK04832 indicates that SYNC is possible with this configuration, because the R-divider can be reset. [quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"](a) Is the SYSREF-divider SYNC-retime mechanism valid despite the 125-phase ambiguity — e.g., because the ambiguity is granular in whole SYSREF periods (102.4 ns = exactly 256 sample periods at 2.5 GSPS) and therefore acceptable or correctable downstream — or does the ambiguity defeat multi-device determinism?[/quote] The ambiguity defeats multi-device determinism. Again, this could be solved with R-divider SYNC on LMK04832, but with LMK04828 you are unable to synchronize given this frequency plan. [quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"](b) Which flowchart leaf/Type does our configuration actually land on?[/quote] Type III.a, SYNC Not Possible. Require Input-to-output determinism? YES Use ZDM? YES f OUT % f ZDM == 0 for all f OUT ? YES OSCIN doubler used? NO f ZDM % f OSC == 0? NO Result: Type III.a, SYNC Not Possible [quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"](c) If this frequency set cannot achieve a deterministic relaxed-window SYNC on the LMK04828B, one option we're considering is moving the distributed reference itself into the power-of-2 family: CLKin0 = 156.25 MHz (= VCO/16, generated centrally by our clock-distribution unit from its OCXO) with VCXO = 156.25 MHz . That gives, with SYSREF-divider feedback: PLL1 R1 = 16, N1 = 1 (PFD = 9.765625 MHz), max(N,R) % min(N,R) = 0, and — since the flowchart identifies the non-resettable N-divider as the source of phase randomization — N1 = 1 should eliminate the input-to-output ambiguity entirely. PLL2 becomes R2 = 1, N2 = 16 (PD = 156.25 MHz), also satisfying your condition. SYNC would be issued at GCD = 9.765625 MHz with the ~102.4 ns window. Does this configuration land on a deterministic leaf and achieve the relaxed window — and do you see any issue with the R1 = 16 (R > 1) side given the LMK0482x's lack of R-divider SYNC, or is that concern eliminated when N1 = 1? If you would recommend a different change instead (different SYSREF frequency, different feedback/SYNC structure), we're open to it.[/quote] This doesn't change the terminal leaf: you are still in Type III.a, SYNC Not Possible, because f ZDM % f OSC != 0. Your SYSREF divider on each device would be locked to one reference edge of the 156.25MHz clock, but you have no control over which of the 16 possible valid edges. Again, this is a problem resolved with R-divider reset on LMK04832. As an alternative, you could pre-divide the 156.25MHz source and distribute 9.765625MHz to each LMK04828 CLKIN0. This satisfies f ZDM % f OSC == 0, and you end up in Type I SYNC where SYNC timing has been trivialized (only one valid phase for the entire system). Synchronization aside, I think the switch to 156.25MHz VCXO is a good idea. Technically, 125MHz or 100MHz are also valid options - in nested ZDM, the VCXO is only fed forward into PLL2 reference, so any frequency which locks PLL2 is satisfactory. 156.25MHz is also the highest frequency I recommend providing to PLL2 phase detector (technically it's 1.25MHz over the limit in the datasheet, but this limit has some generous margin and 156.25MHz will present no problems), which is beneficial to performance - the higher phase detector frequency will reduce in-band noise by around 10log(156.25/20) = 8.9dB compared to the 20MHz suggested originally. [quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"]Does the condition need to hold on the PLL2 pair specifically, on PLL1, or on the composite, for single-phase determinism in nested ZDM with the SYSREF divider fed back?[/quote] The condition holds at whichever phase detector must produce repeatable input-to-output determinism. In nested ZDM this is the phase detector of PLL1. This is one of the unique benefits of nested ZDM - the conditions at PLL2 phase detector are largely irrelevant, as long as it locks, and the user is free to optimize for performance. By contrast, it is generally very challenging to achieve input-to-output determinism with a cascaded configuration because of the lack of control over the divider phase within PLL1. I'm not sure a cascaded use case can be reliably aligned. There might be some pathological edge cases (REF == VCXO, R1 == N1 == 1) combined with ZDM on PLL2 that could be supported, but generally PLL1 has either R or N > 1. For your use case, if we stick with nested ZDM, the conditions only needs to hold at PLL1 phase detector. [quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"](a) PLL1 uses external loop-filter components on CPout1, sized for the current 160 MHz VCXO's tuning gain — these presumably need re-sizing for a new VCXO with different Kv. What's the recommended method/tool for redesigning the PLL1 external filter (Clock Design Tool? PLLatinum Sim? a worksheet?), and can you advise a starting point given a target PLL1 bandwidth in the usual 10–300 Hz jitter-cleaning range?[/quote] PLLatinum Sim works best. From what I can tell, a nested ZDM configuration behaves identically in simulation to a cascaded configuration, so the two PLLs can be designed as though they are independent and cascaded - design PLL1 first with the desired VCXO, then cascade this into PLL2. Normally, the PLL1 loop bandwidth is selected such that the reference noise is substituted above the loop bandwidth with the VCXO noise. This isn't necessarily 100Hz - sometimes the reference is really good, and we want as little of the VCXO noise as possible, hence we open the loop bandwidth a lot more, maybe to 1kHz. At some point, the 1/f noise of PLL1 will be worse than the slope of the VCXO. If you know the reference and VCXO performance and the gain of the VCXO, and your reference is better than your VCXO, you can load these parameters into PLLatinum Sim, and locate the point where the PLL noise and VCXO noise intersect, and target the loop bandwidth to that point or just a bit before it. In terms of general usage for PLLatinum Sim, I have the following advice: Second order loop filter is probably sufficient for PLL1, unless your reference comes in with spurs that need to be filtered. Since your phase detector frequency is constrained by ZDM, your available loop bandwidth pivots are the loop filter components and the charge pump gain. You can decrease charge pump gain to help reduce the size of loop filter components needed for smaller bandwidths, but be careful that the charge pump gain is still sufficient to drive the leakage impedance of the VCXO VTUNE node. PLLatinum Sim will reset the VCO gain whenever a handful of parameters are changed (in most cases, this is to look up integrated VCO gain at a given frequency, but it is counterproductive when using external VCXO). Under the options menu, uncheck "Main Diagram Updates Performance Metrics" when working with PLL1 to make it save the Kvco value. This option should be reapplied for PLL2 (if it isn't automatically reapplied). The default X-axis and Y-axis settings for PLL1 are not very helpful, I recommend adjusting the X-axis and Y-axis on the Phase Noise tab (uncheck Autoscale Axes) so you can see the whole phase noise curve. [quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"](b) PLL2's loop filter is internal/register-programmable — what internal filter settings (R3/R4/C3/C4) would you recommend at the new PD (100 or 156.25 MHz)? If it helps, we can pull the CLK104's populated PLL1 filter values from the board schematic as the baseline.[/quote] I recommend leaving them at defaults unless there are specific VCXO spurs to be cleaned up. We don't see that much benefit to the third and fourth order components in PLL2 in general. [quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"]With the SYSREF divider selected via FB_MUX as the internal 0-delay feedback in nested mode — the CLK104 provides no route to FBCLKin, so the feedback must be internal — does that selection place any constraints on the SYSREF-sourced outputs (CLKout3/9/11), e.g., divider or delay settings that must be held common with the feedback path?[/quote] The feedback path comes directly from the divider output, before the SYSREF_MUX, and is a buffered copy. So there are no constraints on the SYSREF-sourced outputs. [quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"]You cautioned that a low SYSREF-divider frequency in the feedback path can limit performance. Moving the feedback from CLKout8 (156.25 MHz) to the SYSREF divider (9.765625 MHz) drops the feedback frequency ~16×. Can you characterize or bound the phase-noise/jitter penalty for our configuration (nested ZDM, 2500 MHz VCO, with the VCXO options above)? Is there a feedback frequency below which you would advise against this approach?[/quote] Generally, you will see a 10log(F PD_NEW /F PD_OLD ) change in noise performance below the loop bandwidth from the PLL flat noise contribution, such that performance improves by 10dB/decade or 3dB/octave as phase detector frequency increases. By using nested ZDM, the impact of a reduced phase detector frequency is pushed back to PLL1 with a very low loop bandwidth, and a clean VCXO becomes the dominant noise source above the loop bandwidth of PLL1 but below the crossover frequency with PLL2 flicker/flat noise contribution. I previously mentioned that nested ZDM does not care about the precise alignment of the PLL2 phase detector since it aligns the output directly to the input, so we are free to select a PLL2 reference (VCXO) that gives the highest acceptable frequency to achieve the best in-band performance. 156.25MHz, as mentioned previously, is an excellent choice. 125MHz or 100MHz would also work, at a 1-2dB in-band noise penalty. [quote userid="542142" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332"]Yes, please describe the capcode override procedure you offered. Our inter-board calibration relies on each board's input-to-output phase being repeatable across power cycles (we calibrate per-board residual skew via downstream measurement of the RFSoC DAC output phase), so making the ~200 ps capcode variation static is valuable even in nested mode. Specifically: which registers set the manual capcode; how should the correct capcode be determined per device (per-unit characterization, or one value per frequency/temperature?); and does skipping calibration carry lock-reliability risk over a 25–45 °C operating range?[/quote] I'll reiterate that nested ZDM doesn't care about the alignment at the PLL2 phase detector, so I don't feel this procedure is necessary. Nevertheless, the procedure is below. We break it up into two steps: a discovery phase, and a programming phase. For discovery: Lock PLL2 at the nominal operating temperature, with the desired register settings. Ensure that the LSBs of PLL2_N are written, so that the calibration of the internal VCO completes. Read back the value of the capcode from R396[6:0] (0x18D[6:0]). Record this value for each device (i.e. per-unit characterization). Optionally, this step could be repeated at several different temperatures to help bound the skew variation across temperature. For programming: Write all registers as described in the datasheet, including allowing initial calibration to happen. This is important for VCO amplitude calibration, which improves phase noise by increasing slew rate (without significantly impacting timing). Disable VCO calibration by writing R358[2] = 1 (0x166[2] = 1). Write the recorded capcode, bitwise OR'd with 0x80, to R376 (0x178). The bitwise OR is important, because it enables the override. In your case, over the 25°C to 45°C range, I don't think step 3 of discovery is required. Over a wider temperature range, the VTUNE variation might be large enough that you could bound the overall skew to a narrower window by selecting a new capcode. I'm less certain about how large this window needs to be. If you'd like to investigate on your own, you could monitor VTUNE voltage with a DMM across the operating temperature range with a forced capcode, and see if incrementing or decrementing the capcode at the boundary temperatures gives less input-to-output skew than sticking to one capcode over the whole operating range. I think there is no risk to lock reliability when skipping calibration over 25°C to 45°C range. Each capcode is designed to be usable across ±125°C.https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1668807/lmk05318-hcsl-differential-output-rangeWed, 29 Jul 2026 18:41:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b339bc11-d7ef-4a67-97c7-01293b196dabFaizul BacchusPart Number: LMK05318 Hello, Customer has asked the following: Can you help to clarify the differential output range for HCSL outputs on the LMK05318 datasheet? This is a differential output, however seems to be defined similarly as SE outputs, is there any more specific differential data , such as VPP_DIFF and VOS or Cross over? Thanks very much Faizul BacchusLMK05318https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667852/pllatinumsim-sw-lmx2694-ep-device-is-not-available-in-the-tool/6433382Wed, 29 Jul 2026 17:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f04a80fa-1281-4d98-bb5a-78970261b5d3Maharajan PDear Derek, Thank you for the files, we have tried and implemented this on our design, still PLL is not locking, Could we please have a call tomorrow to discuss this issue in detail to help us debugging this issue and move forward. Thank you and best regards, Maharajan Phttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1668784/cdcv304-ep-maximum-duty-cycleWed, 29 Jul 2026 17:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fd3c56f7-f486-46d0-a9cb-1d67c93f56d6Erika AlejandrePart Number: CDCV304-EP Hik I hope you are well. I would like to know the maximum duty cycle of part number: CDCV304TPWREP, please.cdcv304-ephttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1668648/lmk5b33216-request-for-product-lifecycle-confirmation/6433366Wed, 29 Jul 2026 17:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d777d112-28c8-434b-ad16-a2fff552041dJaryd DukesHi Vaishnavi, Both the LMK5B33216 and the LMK1C1103 are relatively newer devices and we currently have no plans to end support for these parts in the near future. Best, Jarydhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666311/lmk04828-lmk04828b-part-to-part-output-skew-when-two-devices-share-the-same-reference-input-to-output-skew-in-zero-delay-mode/6433332Wed, 29 Jul 2026 16:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8b939291-6959-4827-bc2f-b2b2e70e757cGilles AminotThank you — the SYSREF-divider retimer guidance and the flowcharts are exactly what we needed, and we are proceeding in that direction: nested zero-delay mode, SYSREF divider as the 0-delay feedback, SYNC re-timed to the SYSREF-divider edge. Working through the details against the flowchart raised five follow-up questions. Our configuration, for reference: LMK04828B (on AMD CLK104), nested zero-delay mode PLL1: CLKin0 = 10 MHz external reference; VCXO (OSCin) = 160 MHz; PLL1 PD = 10 MHz PLL2: VCO = 2500 MHz (R2 = 8, N2 = 125, PD = 20 MHz) Outputs: device clocks 156.25 MHz (VCO ÷16) on CLKout0/4/6/8/12; SYSREF 9.765625 MHz (VCO ÷256) on CLKout3/9/11; all HSDS8 0-delay feedback currently CLKout8 (156.25 MHz); planning to move it to the SYSREF divider per your guidance Q1 — Reconciling the flowchart with the SYSREF-retimer guidance (our critical question). Walking our configuration through the LMK0482x flowchart (page 2): we satisfy "fOUT % fZDM == 0 for all fOUT" with fZDM = SYSREF = 9.765625 MHz (156.25/9.765625 = 16). But feeding the SYSREF divider back to PLL1 requires PLL1 dividers satisfying 10/R1 = 9.765625/N1, whose minimal solution is R1 = 128, N1 = 125 (PFD = 78.125 kHz) — and 125/128 are coprime, so max(N,R) % min(N,R) ≠ 0, giving (per the flowchart) min(N,R)/GCD(N,R) = 125 possible input-to-output phase relationships, with a non-resettable N-divider and no R-divider SYNC on the LMK0482x. This appears fundamental to our frequency set: SYSREF = VCO/256 lies in the power-of-2-submultiple family of the 2500 MHz VCO, while the 10 MHz reference (and any VCXO lockable to it) lies in the ×10 MHz family; the two share no usable common divider structure. Yet your written guidance says the SYSREF-divider feedback re-times the SYNC to the SYSREF-divider edge with a valid window of almost a full SYSREF period, issued at GCD(input, outputs) — which for us is 78.125 kHz. Can you reconcile these? Specifically: (a) Is the SYSREF-divider SYNC-retime mechanism valid despite the 125-phase ambiguity — e.g., because the ambiguity is granular in whole SYSREF periods (102.4 ns = exactly 256 sample periods at 2.5 GSPS) and therefore acceptable or correctable downstream — or does the ambiguity defeat multi-device determinism? (b) Which flowchart leaf/Type does our configuration actually land on? (c) If this frequency set cannot achieve a deterministic relaxed-window SYNC on the LMK04828B, one option we're considering is moving the distributed reference itself into the power-of-2 family: CLKin0 = 156.25 MHz (= VCO/16, generated centrally by our clock-distribution unit from its OCXO) with VCXO = 156.25 MHz . That gives, with SYSREF-divider feedback: PLL1 R1 = 16, N1 = 1 (PFD = 9.765625 MHz), max(N,R) % min(N,R) = 0, and — since the flowchart identifies the non-resettable N-divider as the source of phase randomization — N1 = 1 should eliminate the input-to-output ambiguity entirely. PLL2 becomes R2 = 1, N2 = 16 (PD = 156.25 MHz), also satisfying your condition. SYNC would be issued at GCD = 9.765625 MHz with the ~102.4 ns window. Does this configuration land on a deterministic leaf and achieve the relaxed window — and do you see any issue with the R1 = 16 (R > 1) side given the LMK0482x's lack of R-divider SYNC, or is that concern eliminated when N1 = 1? If you would recommend a different change instead (different SYSREF frequency, different feedback/SYNC structure), we're open to it. Q2 — Scope of the max(N,R) % min(N,R) == 0 condition, and a planned VCXO change. Our PLL2 pair is N2/R2 = 125/8, which is coprime, failing your condition on the PLL2 loop. Our PLL1 pair (10 MHz → 160 MHz, effectively 16/1) passes, and the composite 10 MHz → 2500 MHz ratio is exactly 250. Does the condition need to hold on the PLL2 pair specifically, on PLL1, or on the composite, for single-phase determinism in nested ZDM with the SYSREF divider fed back? If PLL2 binds, we plan to replace the CLK104 VCXO — with 100 MHz if we keep the 10 MHz reference (giving R2 = 1, N2 = 25, PLL2 PD = 100 MHz, and PLL1 N = 10 with PD unchanged at 10 MHz), or with 156.25 MHz under the Q1(c) configuration (R2 = 1, N2 = 16, PD = 156.25 MHz). Two loop-filter questions follow: (a) PLL1 uses external loop-filter components on CPout1, sized for the current 160 MHz VCXO's tuning gain — these presumably need re-sizing for a new VCXO with different Kv. What's the recommended method/tool for redesigning the PLL1 external filter (Clock Design Tool? PLLatinum Sim? a worksheet?), and can you advise a starting point given a target PLL1 bandwidth in the usual 10–300 Hz jitter-cleaning range? (b) PLL2's loop filter is internal/register-programmable — what internal filter settings (R3/R4/C3/C4) would you recommend at the new PD (100 or 156.25 MHz)? If it helps, we can pull the CLK104's populated PLL1 filter values from the board schematic as the baseline. Q3 — Constraints on SYSREF-sourced outputs with the SYSREF divider fed back. (Contingent on Q1 resolving favorably.) With the SYSREF divider selected via FB_MUX as the internal 0-delay feedback in nested mode — the CLK104 provides no route to FBCLKin, so the feedback must be internal — does that selection place any constraints on the SYSREF-sourced outputs (CLKout3/9/11), e.g., divider or delay settings that must be held common with the feedback path? Q4 — Phase-noise cost of the 9.765625 MHz feedback. You cautioned that a low SYSREF-divider frequency in the feedback path can limit performance. Moving the feedback from CLKout8 (156.25 MHz) to the SYSREF divider (9.765625 MHz) drops the feedback frequency ~16×. Can you characterize or bound the phase-noise/jitter penalty for our configuration (nested ZDM, 2500 MHz VCO, with the VCXO options above)? Is there a feedback frequency below which you would advise against this approach? Q5 — PLL2 capcode override. Yes, please describe the capcode override procedure you offered. Our inter-board calibration relies on each board's input-to-output phase being repeatable across power cycles (we calibrate per-board residual skew via downstream measurement of the RFSoC DAC output phase), so making the ~200 ps capcode variation static is valuable even in nested mode. Specifically: which registers set the manual capcode; how should the correct capcode be determined per device (per-unit characterization, or one value per frequency/temperature?); and does skipping calibration carry lock-reliability risk over a 25–45 °C operating range?https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1668731/cdce62002-cdce62002-possibility-of-increased-pll-lock-time-near-the-lower-vco-operating-limitWed, 29 Jul 2026 14:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:92fb003b-1b85-4de0-a9a9-40ddebfb1af1Shuji IshiwataPart Number: CDCE62002 Hello, We are using CDCE62002 as a jitter cleaner and investigating a PLL lock-time related issue. According to the datasheet, the VCO operating range is specified as 1.750 GHz to 2.356 GHz. I would like to ask whether operating the VCO close to the lower end of the specified range (around 1.75 GHz) could potentially cause: Failure to achieve PLL lock Excessively long PLL lock times Increased device-to-device or lot-to-lot variation in lock performance In addition, does TI recommend operating the VCO closer to the center of the valid range rather than near the minimum limit? Are there any known limitations, performance degradations, or application notes related to lock behavior when the VCO is configured near the lower operating boundary? We are currently observing a condition where some devices require significantly longer lock times than others under the same configuration, and we would like to understand whether the VCO operating point could be a contributing factor. Have you ever observed lock-time variation dependent on process variation or lot-to-lot variation when operating near the VCO lower boundary? Thank you for your support. Best Regards, IshiwatatvCDCE62002https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667999/lmk04228-clock-generator-selection/6433046Wed, 29 Jul 2026 14:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6cc25a39-f02c-405e-ae13-f6f76f22b968Nishant GuptaI noticed that the LMKD device is available only up to an operating temperature of 85°C. Could you please suggest if there is: An automotive-grade (AEC-Q100 qualified) equivalent, An EP (Enhanced Product) version, or A pin-compatible device that supports an extended operating temperature range up to 125°C? Our application requires operation up to 125°C, so any suitable recommendation would be greatly appreciated. Thank you for your support.https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1668648/lmk5b33216-request-for-product-lifecycle-confirmationWed, 29 Jul 2026 11:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9666775d-d1a8-4355-8789-48d41b298afbvaishnavi poojaryPart Number: LMK5B33216 Other Parts Discussed in Thread: LMK1C1103 Greetings from iWave Systems Technologies Pvt. Ltd. We are evaluating the below Texas Instruments components for use in one of our medical products. Part Numbers: LMK5B33216RGCR LMK1C1103APWR Could you please confirm whether these components are currently active and expected to remain available for supply over the next two years? Additionally, kindly let us know whether there are any planned End-of-Life (EOL) notifications, Product Change Notifications (PCNs), or any other lifecycle changes associated with these parts. If any component is expected to become obsolete or discontinued, kindly recommend suitable replacement parts with equivalent electrical and mechanical specifications. Thank you for your support. We look forward to your response.LMK5B33216LMK1C1103https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1659832/bq32000-when-bq32000-with-high-rs-the-cl-choose/6432499Wed, 29 Jul 2026 06:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:182a0608-2b45-4bea-abc6-a87031ecfb12neko linWe are raising this question because we noticed that after the reflow process, the crystal's series resistance exceeds your specification (70k ohms) and reaches 80k ohms. We would like to ask: when paired with the BQ32000, will a crystal series resistance of 80k ohms, combined with the absence of an external load capacitor (no CL), cause the crystal to fail to oscillate?https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1668447/lmx2582-lmx2582-configuration-for-2-4ghz-2-5ghz-100khz-step-continuous-frequency-sweepWed, 29 Jul 2026 02:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d4c45c09-03aa-4e20-b719-0e199d79354fuser6150974Part Number: LMX2582 Dear TI Technical Support Team, I am currently developing a signal source based on the LMX2582 wideband frequency synthesizer, targeting an output frequency range of 2.4 GHz to 2.5 GHz. The design requires a continuous frequency sweep with a fixed 100 kHz step size. A critical requirement is that the RF output must remain uninterrupted throughout the entire frequency sweeping and switching process, with the instantaneous output frequency deviation strictly limited to a small margin relative to the current or next target frequency. According to the LMX2582 datasheet, the VCO3 core has a native tuning range of 4481 MHz to 5092 MHz. Its subsequent divide-by-2 output path can fully cover the entire 2.4 GHz to 2.5 GHz target band. I would greatly appreciate it if you could confirm whether the LMX2582 can fully satisfy these performance requirements. If feasible, could you also provide a step-by-step, register-level configuration procedure to implement this function properly? Thank you for your assistance.LMX2582