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/1659619/lmk04828-ep-review-and-suggest-correction-for-hardware-design/6429076Sun, 26 Jul 2026 08:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:075be8c9-c0ce-426e-8cf0-bcd8c9fd993bGAURAV UPADHYAYDear Michael Srinivasan Thanks for your support and guidance. Could you please share software configuration for LMK04828B also? Best Regards, Gauravhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667537/lmx2694-ep-lmx2694srtctep-pll-not-locking-issueSat, 25 Jul 2026 08:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3e781cd5-c216-4ea8-990f-7080554ab641Maharajan PPart Number: LMX2694-EP Dear Team, I am using LMX2694SRTCTEP, When reading Register R110, i obtain a value of 0x0759 (binary: 0111 0101 1001). According to the LMX2694 datasheet, bits [10:9] indicate the VCO status, and the reported value corresponds to "Unlocked (fVCO High)". Could you please help us understand the possible reasons for this condition? We would also appreciate your guidance on the recommended debugging steps or any configuration changes required to resolve this issue and achieve a stable PLL lock We are in middle of debugging and need to be solved very urgently, So i kindly request to get a response from your side as soon as possible, Thank you and best regards, Maharajan PLMX2694-EPhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666898/cdce62005-cdce62005-40-mhz-output-consistently-shifted-by-approximately-180-degrees-from-40-mhz-reference-after-sync/6428951Sat, 25 Jul 2026 01:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:316cd166-7d9b-4867-966e-62ed724e4554Jaryd DukesHi Shinji, The synchronization of the outputs can be accomplished by toggling the SYNC pin, or Bit (R8.8), or by changing any output divider values, so these actions are functionally the same and you should be able to synchronize by changing the output divider register for any output. If your OUT0 is consistently shifted by 180° and the shift is repeatable after power cycling , then there is a deterministic phase relationship between the input and output and the synchronization procedure may be working as expected, with the output divider resetting to a half-cycle offset relative to the reference. Would you be able to try adjusting the digital phase adjust ( PH0ADJC) register bits to provide a static 180° offset in the digital logic to account for this shift you are seeing? The output coarse phase adjust settings should be listed in the datasheet as well (tables 14-19). Once the offset is programmed, the phase relationship should remain repeatable across power cycles and PLL relocks, provided the device remains in lock. Best, Jarydhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667415/lmk5b33216-i2c-address-is-not-getting-detected/6428950Sat, 25 Jul 2026 00:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fa7b4487-f1db-411f-95f0-b12cdfa150f8Connor LewisHi Abhishek, Thanks for reaching out, we should be able to look into this early next week.https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666881/cdce913-q1-power-sequence/6428935Fri, 24 Jul 2026 23:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:76d83ecc-d693-4244-909f-08c7d3bb2ccaNirmal KarthikHi Hirata, No Power Sequence requirements. It is recommended that you set XIN/CLK and ramp VDDOut to 3.3V though before pulling VIN about 1.8V. Please note that this can be found on page 22 of the datasheet in the section entitled "8.3 Power Supply Recommendations ". Best, Nirmal Karthikhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1665080/lmk5b33216-lmk5b33216-high-temperature-70-c-when-driving-ads6445-clkp-clkm-with-lvds/6428913Fri, 24 Jul 2026 22:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9483d66f-4f68-4e37-8464-a70fd076f5f6Jaryd DukesHi Daniel, In your configuration it looks like all 16 outputs that you are generating from the LMK5B33216 are identical and are sourced from the same PLL. Powering down all other APLLs/DPLLs should save some power and result in lower thermal dissipation, so I don't think it would be necessary to replace the 1 device with 2x LMK5B12212 devices. Would you be able to send the TICS Pro configuration file you are using to program the part so we can see if there is any further thermal optimization we can perform? Best, Jarydhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667507/lmx2572evm-lmx2572-confirming-full-assist-force-bypasses-vco-calibrationFri, 24 Jul 2026 21:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7d77967a-c795-48cb-ba3c-3ea2aac95a7eJohn RoulstonPart Number: LMX2572EVM Other Parts Discussed in Thread: LMX2572 Follow-up to: “LMX2572: Follow up question” and “LMX2572: VCO Sub-Band Boundaries, FCAL_EN=0 Autonomy, and FastLock at Band Extremes”. We're implementing Full Assist (SNAA336 §3.3, confirmed applicable to LMX2572 by Noel Fung) between two tones 5 MHz apart (700 and 705 MHz test case). VCO_SEL_FORCE, VCO_CAPCTRL_FORCE, and VCO_DACISET_FORCE are all set, and bench calibration confirms VCO_SEL, VCO_CAPCTRL, and VCO_DACISET are identical at both tones — so only the N-divider changes per hop. Using the LMX2572 EVM with Reference pro and TICSPro script in Burst mode. On the bench, the Vtune step response for this forced hop (N-divider write only, FORCE registers untouched) is visually indistinguishable — same amplitude, same settling shape — from an ordinary unforced retune done manually via the PLL page (full VCO calibration search). Loop filter step response is governed by loop bandwidth rather than acquisition mechanism, so this comparison can't tell us whether FORCE is actually suppressing the calibration search. Question With FORCE set and only the N-divider subsequently written, is the retune guaranteed to be a pure divider-value change with no internal calibration/search state machine invoked? Is there a register bit or status flag we can read back to confirm directly that no calibration event occurred on a given write? Separately: since the Vtune shape looks the same either way, what timing signature should differ between a FORCE-bypassed hop and a full calibration-search hop (e.g. total time from the N-divider write to Lock Detect assertion) — so we can verify this on a scope? See trace. This is Vtune at 20usec/Div. Does not look like full assist tuning.LMX2572LMX2572EVMWireless Infrastructurehttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667495/tlc555calc-pspice-file-transfer-to-simetrixFri, 24 Jul 2026 19:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fed1421b-6cdb-47d7-8f15-45e03d8e4071jacob scariaPart Number: TLC555CALC Other Parts Discussed in Thread: TLC555 Hi, I am encountering the following errors while attempting to run a simulation in SIMetrix 12.0 using the TLC555 PSpice model file. If possible, could you please help me identify and resolve the issue? The error messages are listed below: Thank you for your assistance. Best regards, Jacob Following the the version i used Simulation model TLC555x and TLC556x PSpice Model (Rev. E) SLFJ002E.ZIP (25 KB) - PSpice Model Errors found during the run. Simulation aborted *** ERROR *** Error in parameter expression '0.3/(VT*(log(1+0.005/(U3.XD8.ISZ))))' (Line ref: TLC555_6.LIB,491) Unknown parameter 'VT' *** ERROR *** Error in parameter expression '0.3/(VT*(log(1+0.005/(U3.XD7.ISZ))))' (Line ref: TLC555_6.LIB,491) Unknown parameter 'VT' *** ERROR *** Error in parameter expression '0.3/(VT*(log(1+0.005/(U3.XD2.ISZ))))' (Line ref: TLC555_6.LIB,491) Unknown parameter 'VT' *** ERROR *** Error in parameter expression '0.3/(VT*(log(1+0.005/(U3.XD1.ISZ))))' (Line ref: TLC555_6.LIB,491) Unknown parameter 'VT' *** ERROR *** Error in parameter expression '0.3/(VT*(log(1+0.005/(U3.XD4.ISZ))))' (Line ref: TLC555_6.LIB,491) Unknown parameter 'VT' *** ERROR *** Error in parameter expression '0.3/(VT*(log(1+0.005/(U3.XD3.ISZ))))' (Line ref: TLC555_6.LIB,491) Unknown parameter 'VT' *** ERROR *** Error in parameter expression '0.3/(VT*(log(1+0.005/(U3.XD6.ISZ))))' (Line ref: TLC555_6.LIB,491) Unknown parameter 'VT' *** ERROR *** Error in parameter expression '0.3/(VT*(log(1+0.005/(U3.XD5.ISZ))))' (Line ref: TLC555_6.LIB,491) Unknown parameter 'VT' *** ERROR *** Error in parameter expression 'U3.XMN3.VTON/(VT*(log(1+U3.XMN3.IDIN/(U3.XMN3.IS))))' (Line ref: TLC555_6.LIB,400) Unknown parameter 'VT' *** ERROR *** Error in parameter expression 'U3.XMN5.VTON/(VT*(log(1+U3.XMN5.IDIN/(U3.XMN5.IS))))' (Line ref: TLC555_6.LIB,400) Unknown parameter 'VT' *** ERROR *** Error in parameter expression 'U3.XMp9.VTOHP/(VT*(log(1+U3.XMp9.IO/(U3.XMp9.IS))))' (Line ref: TLC555_6.LIB,338) Unknown parameter 'VT' *** ERROR *** Error in parameter expression 'U3.XMp6.VTOHP/(VT*(log(1+U3.XMp6.IO/(U3.XMp6.IS))))' (Line ref: TLC555_6.LIB,338) Unknown parameter 'VT' *** ERROR *** Error in parameter expression 'U3.XMp5.VTOHP/(VT*(log(1+U3.XMp5.IO/(U3.XMp5.IS))))' (Line ref: TLC555_6.LIB,338) Unknown parameter 'VT' *** ERROR *** Error in parameter expression 'U3.XMp1.VTOP/(VT*(log(1+U3.XMp1.IDIN/(U3.XMp1.IS))))' (Line ref: TLC555_6.LIB,365) Unknown parameter 'VT' *** ERROR *** Error in parameter expression 'U3.XMp1.CN*(0.6)*(U3.XMp1.XJN)*(U3.XMp1.COX)' (Line ref: TLC555_6.LIB,385) Illegal forward reference to parameter 'U3.XMp1.COX' *** ERROR *** Error in parameter expression 'U3.XMN2.CCG*(0.6)*(U3.XMN2.XJNCG)*(U3.XMN2.COXCG)' (Line ref: TLC555_6.LIB,170) Illegal forward reference to parameter 'U3.XMN2.COXCG' *** ERROR *** Error in parameter expression 'U3.XMN1.CCG*(0.6)*(U3.XMN1.XJNCG)*(U3.XMN1.COXCG)' (Line ref: TLC555_6.LIB,170) Illegal forward reference to parameter 'U3.XMN1.COXCG' *** ERROR *** Model 'U3.XD5.DZ_18V', parameter 'eg': Cannot evaluate expression '8*(U3.XD5.Nz)*(VT)' Unknown parameter 'VT' *** ERROR *** Model 'U3.XD6.DZ_18V', parameter 'eg': Cannot evaluate expression '8*(U3.XD6.Nz)*(VT)' Unknown parameter 'VT' *** ERROR *** Model 'U3.XD3.DZ_18V', parameter 'eg': Cannot evaluate expression '8*(U3.XD3.Nz)*(VT)' Unknown parameter 'VT' *** ERROR *** Model 'U3.XD4.DZ_18V', parameter 'eg': Cannot evaluate expression '8*(U3.XD4.Nz)*(VT)' Unknown parameter 'VT' *** ERROR *** Model 'U3.XD1.DZ_18V', parameter 'eg': Cannot evaluate expression '8*(U3.XD1.Nz)*(VT)' Unknown parameter 'VT' *** ERROR *** Model 'U3.XD2.DZ_18V', parameter 'eg': Cannot evaluate expression '8*(U3.XD2.Nz)*(VT)' Unknown parameter 'VT' *** ERROR *** Model 'U3.XD7.DZ_18V', parameter 'eg': Cannot evaluate expression '8*(U3.XD7.Nz)*(VT)' Unknown parameter 'VT' *** ERROR *** Model 'U3.XD8.DZ_18V', parameter 'eg': Cannot evaluate expression '8*(U3.XD8.Nz)*(VT)' Unknown parameter 'VT' *** WARNING *** Model 'TLC555_6.TLC55X_NMOS_HV_TLC555_6.TLC55X_NMOSD_HV': Unknown parameter 'LAMBDA' *** WARNING *** Model 'TLC555_6.TLC55X_PMOS_HV_TLC555_6.TLC55X_PMOSD_HV': Unknown parameter 'LAMBDA'TLC555CALCTLC555https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667415/lmk5b33216-i2c-address-is-not-getting-detectedFri, 24 Jul 2026 13:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d4c61071-f5b2-4ab4-bb6a-c4e31839bda6Abhishek ManojPart Number: LMK5B33216 Hi Team, Please find the attached schematics of LMK5B33216RGCR. The I2C address of the clock IC is not getting detected. Below are the observations: The CLK_GEN_SCLK and CLK_GEN_SDATA signals are directly connected to the I2C controller for detecting the I2C address. Proper continuity is verified between the clock IC SCL/SDA pins and resistors R1785/R1786. The voltage measured at resistors R1785 and R1786 is 3.3 V. The CLK_ADDR signal is pulled to ground (probed and confirmed) to configure the I2C address as 0x64. The 49 MHz clock from the XO crystal is present and verified. The CLK_PD# signal is at 3.3 V (probed and confirmed). GPIO1 is connected to ground for I2C mode operation (probed and confirmed). GPIO0 and GPIO2 are left floating, as the default clock outputs are not used and custom output clock frequencies are required. Since probing directly at the IC pins is difficult, the voltage across the decoupling capacitors of all power rails was checked, and all rails are measuring 3.3 V. The I2C communication was checked using a logic analyzer. For the configured IC address 0x64, the device is not providing an acknowledgement (ACK). Even after verifying the above points, the I2C address is still not detected. Kindly review the attached schematic and provide your feedback on any additional checks or possible causes for this issue. LMK Clock schematics 1.pdf Regards, AbhishekLMK5B33216Medical & healthcarehttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666557/lmk00105-maximum-specified-value-of-the-current-for-each-output/6428089Fri, 24 Jul 2026 09:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:306dd5fa-1c23-40fc-9e2a-f5982f809297Takashi ImaiHello Michael-san, Thank you for your reply. I will inform the customer of the contents of your reply. I would like to close this thread if the customer understands. Thanks & Regards, T.Imaihttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667331/lmx2572-phase-adjustment-capability-of-lmx2572Fri, 24 Jul 2026 09:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:48ec84a6-f562-4078-8378-5e4ce152c665EGEMEN YILDIRIMPart Number: LMX2572 Dear TI Team, I want to design a multi channel transmit array which will be integrated to an antenna array in order for beam scanning purposes. My main motivation is to generate the RF signal on each channel rather than generating a central RF, distributing to all channels and adjusting the phase. So, while generating the RF on each channel I need to be able to adjust the phase. Rather than using DDS, PLL usage seems to me much more economical since I will not produce complicated waveforms and DDS components seem to be much more expensive. As far as I have investigated the application notes and datasheets, phase adjustment capability of the LMX2572 is limited in terms of phase range at a single adjustment especially if you are using the channel divider at the output. In the datasheet the phase value is given as: 360° × (MASH_SEED / PLL_DEN) × (P / CHDIV) My question is that, is there a restriction for phase adjustment in the range of 0-360? I mean one will be able to adjust the phase in the full range of 0-360 with multi steps if necessary, right? Also what is the approximate time duration it takes to set the phase for just a single adjustment step? Best regards, Egemen YILDIRIM Best regards, Egemen YILDIRIMLMX2572https://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/6427810Fri, 24 Jul 2026 04:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e9cf2997-499f-4f9a-ae52-cc2f589abb35Michael SrinivasanHi Gilles, I will get to your questions tomorrow. Thanks, Michaelhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1667206/pspice-for-ti-discrepancy-between-the-pin-numbers-in-the-datasheet-and-the-model-pin-numbers-for-the-ti-pspice-model-tlc555_6Fri, 24 Jul 2026 04:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0d4492de-9904-437c-9a70-aa935f3e60bcRound ROUNDPart Number: PSPICE-FOR-TI Other Parts Discussed in Thread: TLC555 The pin numbers for the TLC555_6 library provided in PSPICE for TI differ from those in the datasheet. Will the model still work properly if I wire it based on the “Pin Name”?PSPICE-FOR-TITLC555https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666898/cdce62005-cdce62005-40-mhz-output-consistently-shifted-by-approximately-180-degrees-from-40-mhz-reference-after-sync/6427654Fri, 24 Jul 2026 00:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1cee4990-6d1c-4f06-b973-bede08ab8764Shinij YokotaHi Jaryd, Thank you for the update. I appreciate you looking into this and look forward to your response next week. Best regards, Shinji Yokotahttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666821/lmk5b33216-lmk5b33216-spi-control/6427608Thu, 23 Jul 2026 23:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:59b9efd1-c799-4ce7-bbc0-3614a5cb56ecJaryd DukesHi Tim, Just to be clear, is your issue strictly with the SPI readback, or are you not able to communicate in either direction with the part? To confirm this, you could try to send SPI commands to change the output of the part, for example. Are the waveforms you attached probed from the SDIO pin reading back from the part, or are these waveforms what are being sent into the device? Also when you program R59 to 0xF, you are selecting GPIO2 as the SPI readback SDO, which is a 4-wire SPI function. In 3-wire SPI the SDIO pin should function as both transmit and readback. If you're issue is with the SPI readback, could you try programming this register to a different function to see if you can observe the readback on the SDIO pin? Best, Jarydhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1660960/lmk05028-2-loop-tcxo-dpll-mode/6427572Thu, 23 Jul 2026 22:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2dac85d9-d185-42be-b0c3-8bb4592e22ceConnor LewisHi Takumi-san, Happy to help, and I hope that the configuration I sent over works on your setup. In my configuration, I started from the EVM default configuration in TICS Pro before going through the start page configuration. It looks like there are quite a few registers which are different compared to the initial configuration you sent over, so I haven't been able to isolate which specific registers prevent your original configuration from locking to the TCXO. It's possible that there was a field with an incorrect value that got copied over if you created the .tcs in a previous TICS Pro version.https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666898/cdce62005-cdce62005-40-mhz-output-consistently-shifted-by-approximately-180-degrees-from-40-mhz-reference-after-sync/6427431Thu, 23 Jul 2026 20:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:28be1c05-08ef-49ba-85de-9e6661f7fd70Jaryd DukesHi Yokota-san, We are currently looking into your request, I will get back to you early next week with responses to your questions. Best, Jarydhttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1665999/tlc555-regarding-propagation-delay/6427101Thu, 23 Jul 2026 16:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:77f40d55-a9e3-491e-a9e8-c179cdb7524eRon MichallickDH, This tool uses one Diodehttps://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1666984/lmx2581e-rf-output-impedance-above-2ghz/6427053Thu, 23 Jul 2026 15:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:20b01450-8391-4dd7-ad4a-4ebdfa31527dNoel FungHi There, The output impedance of a synthesizer is never pure resistive, if you use 50Ω pull-up at the output, the output impedance will get close to 50Ω. You may also consider to add a 3dB pad between the synthesizer and mixer to get a better matching.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/6426973Thu, 23 Jul 2026 15:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ea14aee4-0514-4f27-965f-a2df503987bdGilles AminotHi Michael, Thank you for the earlier response — the ~7.5 ps post-power-cycle drift figure and the confirmation that nested zero-delay mode guarantees a deterministic input-to-output phase relationship were both very helpful. I'd like to follow up specifically on the setup/hold requirement for the divider-reset SYNC, because it drives a multi-board architecture decision. Context / constraints: I'm using the AMD CLK104 module (LMK04828B, U2) on ZCU208 boards, 8 boards total, driven from a common 10 MHz reference distributed to each board. On the stock CLK104, CLKin0 is occupied by the 10 MHz INPUT_REF_CLK (via the J11 SMA), and CLKin1 by the on-board TCXO. That leaves the CMOS SYNC pin (via the J42 SMA) as the only available input for the external SYNC/divider-reset signal — I cannot use the high-speed CLKin0 path you'd normally recommend for SYNC, since it's taken by the reference. The LMK04828B is run in nested 0-delay mode, PLL2 locked, VCO at 2.4576 GHz (so ½ VCO period ≈ 200 ps). The goal is a deterministic, repeatable divider reset that is coherent across all 8 boards, so that after MTS the inter-board sample-clock phase alignment holds to a tight budget. Questions: You noted the SYNC setup/hold must be met to "no more than one half of the period of the VCO." For the LMK04828B specifically, is that ½-VCO-period (~200 ps) setup/hold referenced to the CMOS SYNC pin the correct number to design to, or is there a different figure when SYNC arrives on the CMOS pin versus CLKin0? Does any re-clocking configuration relax this? I've seen the SYSREF re-clocking / D-flip-flop mechanism described in the multi-LMK sync app notes (e.g., SYSREF_MUX = re-clocked, SYNC_1SHOT_EN). My question is whether re-clocking the incoming SYNC by the SYSREF divider actually relaxes the input setup/hold requirement (e.g., to the SYSREF-divider period rather than the VCO period), or whether the setup/hold to the internal capturing clock still has to be met at the ½-VCO level regardless — with re-clocking only affecting output determinism, not the input timing window. I want to make sure I don't design around a relaxation that doesn't actually exist. Practically, how do multi-board ZCU208/CLK104 MTS designs meet the ½-VCO SYNC setup/hold on the CMOS SYNC pin? Since the SYNC is asynchronous to each board's VCO, is the intended approach to (a) generate the SYNC coherently with the 10 MHz reference and place its edge to maximize setup/hold margin, (b) accept that some boards may reset one VCO cycle off and rely on a subsequent step to resolve it, or (c) something else? If the edge must be placed relative to the reference, what alignment tolerance is acceptable? How many SYNC pulses are needed for a deterministic reset in a one-shot configuration (SYNC_1SHOT_EN = 1) — a single edge, or is a multi-pulse sequence recommended for robustness across devices? And does the SYSREF divider need to be synchronized separately from the device-clock dividers, or does a single SYNC event handle both? Reconciling the two competing needs on the LMK04828B. I understand the LMK04832 offers an easier PLL1 R-divider SYNC (100 ns setup/hold), but it lacks analog delay on the DCLK outputs — which I need for per-output fine skew trim to meet the inter-board budget. The LMK04828B gives me the DCLK analog delay (25 ps step) but appears to have the harder ½-VCO-period SYNC requirement on the CMOS pin. Is there a way to get both on the LMK04828B — i.e., a SYNC/divider-reset approach that achieves deterministic multi-board reset without requiring the ~200 ps setup/hold on the CMOS SYNC pin, while retaining DCLK analog delay for skew trimming? For example, does using the SYSREF-request / continuous-SYSREF path, or a particular SYNC_MODE/SYSREF_MUX configuration, provide an easier timing path while keeping DCLK ADLY available? Any measured or characterized data on device-to-device divider-reset repeatability under a common reference would also be very helpful for our timing budget. Thanks again, Gilles