Clock & timing forum - Recent Threads

LMX2694-EP: LMX2694-EP RFOUTB_P amplitude variation between power cycles (from 400 mVpp to 480 mVpp)

Kobayashi Toshio — Tue, 06 Oct 2026 10:25:50 GMT

Part Number: LMX2694-EP

Hello,

I have a question regarding RFOUTB_P output amplitude variation on the LMX2694-EP.

Configuration

- LMX2694-EP
- RFOUTB configured according to Section 8.1.4.1, “Resistor Pullup,” of the datasheet
- RFOUTB pulled up to +3.3 V through a 50-ohm resistor
- Single-ended operation
- RFOUTB_P used as the output after AC coupling
- RFOUTB_N AC-coupled and terminated with 50 ohm
- R45 (OUTB_PWR) = 0x0A
- Input clock = 155.52 MHz
- Output clock = 1244.16 MHz
- Oscilloscope input impedance = 50 ohm
- Ambient temperature ≈ 25°C
- PLL lock confirmed before each measurement

Observation

The RFOUTB_P output is a square wave.

The amplitude is typically about 440 mVpp, measured as the voltage difference between the logic-high and logic-low levels using a 50-ohm-terminated oscilloscope.

The measurement is performed at the end of an approximately 1 m coaxial cable connected to the RFOUTB_P output.

However, after power-up, the measured amplitude sometimes varies from approximately 400 mVpp to 480 mVpp, even though the register settings and operating conditions remain unchanged.

The output frequency remains correct at 1244.16 MHz, and PLL lock is always achieved.

This variation is mainly observed after the device has been powered off for an extended period, such as overnight.

When the device is power-cycled after only a few minutes, the amplitude is generally very repeatable, and little variation is observed.

Questions

Is a startup-to-startup amplitude variation from approximately 400 mVpp to 480 mVpp expected in this configuration?

Could this behavior be related to internal calibration, startup conditions, or temperature dependence, even though PLL lock and the output frequency remain normal?

What RFOUTB_P amplitude is typically expected with OUTB_PWR = 0x0A?

Is there a recommended method, setting, or procedure to improve amplitude consistency across power cycles?

We are currently evaluating a downstream clock receiver in our application and would like to understand whether this level of amplitude variation is within the expected characteristics of the device.

Thank you for your support.

Best regards,

RE: LMX2694-EP: LMX2694-EP RFOUTB_P amplitude variation between power cycles (from 400 mVpp to 480 mVpp)

Noel Fung — Tue, 06 Oct 2026 22:26:36 GMT

Hi There,

When the device is up and running for some time, as the device is consuming current, the device is getting hotter, so the output power will be smaller than initial. On the EVM, the power change is much less than 1dB.

Your power change is more than 1dB, I don't think this is normal.

Could you provide your scope plot? Was the measurement taken on customer board? What is the board temperature?

RE: LMK03328: LMK03328 deterministic phase relationship between reference-bypass 27 MHz and PLL-generated 74.25 MHz outputs

Jaryd Dukes — Tue, 06 Oct 2026 22:25:41 GMT

Hi Kyohei-san,

The 1ns propagation delay will vary somewhat with PVT, but we do not spec a max/min for this parameter. For a given device at stable temperature and supply, the delay should be essentially constant during operation.

The bypass path is purely combinational (no PLL or divider in the signal path), so the propagation delay itself should be between power cycles for the same device under the same conditions.

[quote userid="612118" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1685447/lmk03328-lmk03328-deterministic-phase-relationship-between-reference-bypass-27-mhz-and-pll-generated-74-25-mhz-outputs/6501371"]Within a single power cycle, after the PLL has locked and the device configuration remains unchanged, is their phase relationship stable/repeatable, except for normal clock jitter?[/quote]

Yes. Once the PLL has locked and the configuration is unchanged, the phase relationship between the 27-MHz bypass output and the 74.25-MHz PLL output should still be deterministic within a single power cycle. As mentioned before, the phase relationship will change continuously for these output frequencies since they are not identical, but the relationship would remain deterministic aside from clock jitter.

[quote userid="612118" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1685447/lmk03328-lmk03328-deterministic-phase-relationship-between-reference-bypass-27-mhz-and-pll-generated-74-25-mhz-outputs/6501371"]Since 27 MHz and 74.25 MHz have a frequency ratio of 4:11, their edges have a repeating relationship every approximately 148.148 ns.
Is this understanding correct when the 74.25-MHz clock is generated from the 27-MHz reference?[/quote]

This is correct, each edge should realign every 4 cycles of the 27MHz signal and every 11 cycles of the 74.25MHz signal. This relationship will continue as long as both clocks are locked to the same reference.

[quote userid="612118" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1685447/lmk03328-lmk03328-deterministic-phase-relationship-between-reference-bypass-27-mhz-and-pll-generated-74-25-mhz-outputs/6501371"]If the customer requires a deterministic 27-MHz-to-74.25-MHz phase relationship after every power-up, is there any recommended configuration or alternative approach using LMK03328?[/quote]

Yes for establishing a deterministic phase relationship between the 27MHz and 74.25MHz outputs, it would be best to generate both frequencies through the PLL output dividers combined with the global SYNC function. This would ensure a out-out phase relationship with variation of no more than ±1 VCO clock cycle.

For the configuration without the 27MHz bypass outputs, these outputs can be synchronized with the SYNCN signal.

[quote userid="612118" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1685447/lmk03328-lmk03328-deterministic-phase-relationship-between-reference-bypass-27-mhz-and-pll-generated-74-25-mhz-outputs/6502638"]What is the phase relationship between the 27-MHz reference input and the 74.25-MHz PLL outputs?[/quote]

This relationship is not deterministic, as the LMK03328 does not support a fixed phase relationship between the clock input and the PLL outputs. SYNCN can synchronize outputs relative to each other, but cannot synchronize the reference input to any output.

Best,
Jaryd

LMK03328: LMK03328 deterministic phase relationship between reference-bypass 27 MHz and PLL-generated 74.25 MHz outputs

Kyohei — Mon, 28 Sep 2026 06:09:13 GMT

Part Number: LMK03328

Hi team,

I have a question regarding the device "LMK03328".

Our customer is evaluating the following clock configuration:

External reference input: 27 MHz
Output 1: 27 MHz, using reference bypass if possible
Output 2/3: 74.25 MHz, generated by PLL from the 27-MHz reference
The customer requires the clocks to be frequency synchronized.

Could you please advise on:

What is the phase relationship between the 27-MHz reference input and the 27-MHz reference-bypass output?
What is the phase relationship between the 27-MHz reference-bypass output and the PLL-generated 74.25-MHz output?
Is this phase relationship deterministic across power cycles?
Can SYNC_AUTO or SYNCN guarantee the same phase relationship between the reference-bypass 27-MHz output and PLL-generated 74.25-MHz output after every power-up?
For two 74.25-MHz outputs derived from the same PLL with identical divider and mux settings, what output-to-output phase/skew can be guaranteed after synchronization?

We have checked Section 8.4.17 "Output Synchronization" of the datasheet, but it is not clear whether the synchronization mechanism also guarantees deterministic phase between a reference-bypass output and a PLL-derived output.

Best regards,
Kyohei

LMK04828: PLL1 gets unlocked at higher temperature >52°C

sarojini ravi — Tue, 06 Oct 2026 09:12:21 GMT

Part Number: LMK04828

Hi Team,

We are using LMK04828 chip in dual PLL mode with 25MHz TCXO to CLKIN0 path
and 100MHz VCXO (CVHD-950X-100.000) to OSCIN.
If the LMK is powered on while it is cold it locks instantly and maintains lock above 55°C.
When configured at 52°C PLL1 gets unlocked.Loop filter components connected from CPOUT1 to Volt control pin of VCXO
were verified for any degradation of value as the board testing is done since 4 years.
New LMK chip was replaced in the board then also the same issue persists.
We had a freshly assembled board which had only one difference from issue board that is the CPOUT1 voltage which was 1.78V where as issue board had 2.18V.
Upon looking into the query already raised similar to the issue (refer below link),CLKin_OVERRIDE bit was set to 1 and the issue was solved.
Link:https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1035219/lmk04828-pll1-not-locking-at-package-temp-above-36-c-pll1_dld-oscillates

Inspite of setting Pin select mode to CLKIN0 in the configuration,why should we set this override pin.
Kindly clarify the purpose to set this bit.
Is there any other hardware changes that can be done to solve this issue.

Regards
Sarojini R

RE: LMK04828: PLL1 gets unlocked at higher temperature >52°C

Derek Payne — Tue, 06 Oct 2026 19:03:53 GMT

I don't think we ever identified the root cause, but the fact that CLKin_OVERRIDE bit resolves the problem indicates the root cause is likely the clock switching state machine. CLKin_OVERRIDE bypasses the clock switching state machine logic. In theory, pin mode should also bypass the clock selection state machine logic, but it's possible that there's improperly specified conditions or assumptions that lead to an indeterminate state.

Do you have register settings you can share?

RE: LMKDB1202: Is it acceptable to swap P/N on both the clock inputs and the outputs?

Michael Srinivasan — Tue, 06 Oct 2026 19:00:32 GMT

Hi David,

[quote userid="463532" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1687241/lmkdb1202-is-it-acceptable-to-swap-p-n-on-both-the-clock-inputs-and-the-outputs"]Is it acceptable to swap P/N on both the inputs and the outputs of LMKDB1202 as shown in the schematic?[/quote]

Yes, this is fine.

[quote userid="463532" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1687241/lmkdb1202-is-it-acceptable-to-swap-p-n-on-both-the-clock-inputs-and-the-outputs"]Does this P/N swap have any impact on device performance (such as additive jitter, skew, or mux switching behavior) or on PCIe reference clock compliance?[/quote]

The only change you would have seen would have been a 180-degree phase shift, but since you swapped P and N on the outputs, you will not see any impact on device performance.

[quote userid="463532" url="~/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1687241/lmkdb1202-is-it-acceptable-to-swap-p-n-on-both-the-clock-inputs-and-the-outputs"]Are there any restrictions or recommendations regarding clock polarity for this device, for example, whether the polarity must be preserved end-to-end?[/quote]

I would recommend preserving the polarity from end-to-end just as you have done - there will not be any significant impact to the device, but it will demonstrate a 180-degree phase shift if you do not.

Thanks,

Michael

LMKDB1202: Is it acceptable to swap P/N on both the clock inputs and the outputs?

David Kim2 — Tue, 06 Oct 2026 04:58:03 GMT

Part Number: LMKDB1202

Hello,

We are using LMKDB1202REY as a 2:2 PCIe reference clock mux, as shown in the attached schematic. In this design, the P/N polarity is swapped at both the inputs and the output:

Inputs: For both input pairs (HOST clock and OSC clock), the "_N" net is connected to the positive input pin (CLKIN0/CLKIN1) and the "_P" net is connected to the negative input pin (CLKINB0/CLKINB1).
Output: The positive output pin is connected to the "PCIE_CLK_N" net and the negative output pin is connected to the "PCIE_CLK_P" net.

As a result, the overall polarity from each clock source to the final PCIE_CLK_P/N nets is preserved.

Questions:

Is it acceptable to swap P/N on both the inputs and the outputs of LMKDB1202 as shown in the schematic?
Does this P/N swap have any impact on device performance (such as additive jitter, skew, or mux switching behavior) or on PCIe reference clock compliance?
Are there any restrictions or recommendations regarding clock polarity for this device, for example, whether the polarity must be preserved end-to-end?

Thank you for your help.

LMKDB1104: Slew rate measurement faster than spec

Oliver Lin — Wed, 30 Sep 2026 17:41:35 GMT

Part Number: LMKDB1104

Hi team,

My customer has encountered an issue that our clock buffer is faster than DS listed.

We tried pin mode that can lower the slew rate, but PCIE spec is 4V/ns,

SLEWRATE_SEL = High: Slew Rate is 4.7–4.8 V/ns

SLEWRATE_SEL = Low: Slew Rate is 3.9–4.1 V/ns

It is measured at the end point connection. Is that normal to measure slew rate around 4.7~4.8V/ns. And the trace is around 10 inch.

My understanding the parasitics are going to lower the slew rate, but we are seeing the slew rate is faster than DS listed.

RE: LMKDB1104: Slew rate measurement faster than spec

Oliver Lin — Tue, 06 Oct 2026 18:41:45 GMT

Hi Michael,

Thanks for the clarification, Got other questions

Is there any further steps to take to modify SLEWRATE_CTRL_MODE register? Customer reports to me that write 0x1B and readback with 0x0B.

Any pin or register I need to take care?

AM62P: DDR configuration of 4 GB RAM with TI AM62P5

Roshan Mohammed — Tue, 06 Oct 2026 12:30:21 GMT

Part Number: AM62P

Hi,

I have generated the DDR file for the 4GB Micron MT53E1G32D2FW-046 AAT:C. PFA file.
I choose the 8GB RAM as the reference design and reduced the number of Rank to 1 to change to 4 GB and generated the DDR configuration. Please find the below

I changed the dts file to the below:

memory@80000000 {
/* 4G RAM */
reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
<0x00000008 0x80000000 0x00000000 0x80000000>;
device_type = "memory";
bootph-pre-ram;
};

After flashing, it started booting and the bdinfo is below:
=> bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000080000000
-> size = 0x0000000080000000
DRAM bank = 0x0000000000000001
-> start = 0x0000000880000000
-> size = 0x0000000080000000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x00000000ffe75000
reloc off = 0x000000007f675000
Build = 64-bit
current eth = ethernet@8000000port@1
ethaddr = 44:88:be:dd:e2:77
IP addr = <NULL>
fdt_blob = 0x00000000f7e3fcf0
multi_dtb_fit= 0x0000000000000000
lmb_dump_all:
memory.count = 0x2
memory[0] [0x80000000-0xffffffff], 0x80000000 bytes, flags: none
memory[1] [0x880000000-0x8ffffffff], 0x80000000 bytes, flags: none
reserved.count = 0x5
reserved[0] [0x9b500000-0x9e6fffff], 0x3200000 bytes, flags: no-map
reserved[1] [0x9e780000-0x9fffffff], 0x1880000 bytes, flags: no-map
reserved[2] [0xf6e0d000-0xf6e3dfff], 0x31000 bytes, flags: no-notify, no-overwrite
reserved[3] [0xf6e3eff0-0xffffffff], 0x91c1010 bytes, flags: no-overwrite
reserved[4] [0x880000000-0x8ffffffff], 0x80000000 bytes, flags: no-overwrite
devicetree = separate
serial addr = 0x0000000002800000
width = 0x0000000000000000
shift = 0x0000000000000002
offset = 0x0000000000000000
clock = 0x0000000002dc6c00
arch_number = 0x0000000000000000
TLB addr = 0x00000000ffff0000
irq_sp = 0x00000000f7e3eff0
sp start = 0x00000000f7e3eff0
Early malloc usage: 3b48 / 8000

I have enabled the mtest and done the memory test by using the below commands.

mtest commands are below:

mtest 0x82000000 0x9b000000 0 1
mtest 0xa0000000 0xf6000000 0 1
mtest 0x880000000 0x8ffffff00 0 1

Everything passed, Could you please verify this changes are correct and valid?

Is there any changes to be done in any of the steps which I followed

Regards

Roshan

RE: LMK03328: LMK03328 deterministic phase relationship between reference-bypass 27 MHz and PLL-generated 74.25 MHz outputs

Kyohei — Tue, 06 Oct 2026 10:07:21 GMT

Hi Jaryd-san,

Could you also please check my previous follow-up questions?

In addition, the customer is considering a configuration where the 27-MHz bypass output may not be used.

In that case, the configuration would be:

Reference input: 27 MHz
Outputs: two 74.25-MHz clocks generated from the same 27-MHz reference

Could you please clarify the following?

What is the phase relationship between the two 74.25-MHz outputs?
With the same PLL/divider settings and output synchronization, is their relative phase deterministic, including across power cycles?
What is the phase relationship between the 27-MHz reference input and the 74.25-MHz PLL outputs?
Is this phase relationship deterministic, and is it repeatable across power cycles?

Thank you for your support.

Best regards,
Kyohei

RE: LMX2572LP: Oscin Configuration

Peter heng — Tue, 06 Oct 2026 08:34:41 GMT

thank you for providing the confirmation. i believe the 50ohm is needed only when i have a clock source of 50ohm impedance. i guess usually the Oscin impedance will be high and hence a shunt connected R25=51 is needed to lower the impedance.

LMX2572LP: Oscin Configuration

Peter heng — Fri, 02 Oct 2026 03:58:31 GMT

Part Number: LMX2572LP

hello,i found the reference circuit of the LMX2572LP from the EVM schematic. i plan to use cmos oscillator SXO32C3B481-100.000M(Suntsu) parts. therefore i would like to know do i need to have R35=51ohm connected before the oscillator as shown below.

Pls feel free to provide any other alternative Oscin type with better performance.

Thank you.

LMK04610: oscillator for the LMK04610 CLKin

Satoshi Ishizaki — Tue, 06 Oct 2026 08:26:42 GMT

Part Number: LMK04610

hello

I have a question concerning the input clock for the LMK04610.

Please provide the recommended specifications for the oscillator in the following configuration:
1.Phase jitter
2.Rise/fall time
3.recommended to use an oscillator with an integrated PLL or one without?

Oscillator(100 MHz LVPECL) -> LMK04610 CLKin -> LMK04610 CLKout -> LMX2820 OSCin -> LMX2820 RFout -> 10.4 GHz

Satoshi .I

Regards,

LMK05318B-Q1: source code of Matlab DLL configuration files under NDA

Andrea Pastega — Tue, 15 Sep 2026 09:48:23 GMT

Part Number: LMK05318B-Q1

Hello,
several months ago I started to develop a software configuration library for LMK05318B.
As TI only supplies the TICS PC software for the generation of a specific configuration EPROM image,
while we need to be able to customize the configuration of the clock generation onboard of our devices, based on low power SoC running linux, I analyzed TICS functions to understand how to implement the configuration library.
I also requested technical support several times using TI wiki.

TICS implements most of the configuration using Python files, which are included in the installation path, so it was possible to understand how most the chip configuration works.
The parts related to the DLL bandwidth however uses Matlab compiled executables, so it's not possible to access to the source code directly.
Given our need to be able to change the configuration, the technical support agreed to supply us the Matlab source code "as-is", under NDA.

We started the NDA sign procedure between the TI's and our legal offices, the signed NDA was sent to Eliraz Aran, our assigned TI FAE, in the end of July. She forwarded the signed NDA to TI legal office.

Today I tried to contact Eliraz Aran to finally ask about the LMK05318B Matlab source code, however the email came back with a "non-existant recipient" error, so I don't have a TI direct contact to ask for it at the moment...

How may we proceed?

Thanks

Best Regards

Andrea Pastega

RE: LMK05318B-Q1: source code of Matlab DLL configuration files under NDA

Andrea Pastega — Tue, 06 Oct 2026 07:18:24 GMT

Hello Jaryd,
thanks for the effort!
I didn't receive any email at the moment...

Thanks

Andrea

LMK05318B: Unexpected 1PPS Phase Offset Between PRIREF and OUT7

Serizawa Toshitaka — Fri, 28 Aug 2026 07:08:50 GMT

Part Number: LMK05318B

Hello,

Please provide guidance on the following functionality:
LMK05318B Data Sheet
Section 8.3.16: 1PPS Input-to-Output Phase Alignment (PRIREF-to-OUT7 SYNC)

As an initial step, we configure the device as follows:
- R252[7] DPLL_REF_SYNC_OUT7_EN = 0b1
- R340 to R345 DPLL_REF_SYNC_PH_OFFSET = 0x0

We then perform a PLL reset using the following sequence:
- R12[7] RESET_SW = 0b1
- Wait 1 second
- R12[7] RESET_SW = 0b0

We expect the OUT7 1PPS signal to be aligned with the PRIREF 1PPS signal within a few nanoseconds. However, the phase difference between PRIREF 1PPS and OUT7 1PPS is approximately -200 µs to -500 µs.
Immediately after the software reset is released, the first pulse has a phase difference of within +10 ns. However, it appears that the phase difference becomes significantly larger at some point afterward.
The phase difference changes to either approximately -200 µs or -500 µs each time a software reset is performed. Once it settles, however, it remains fixed at either -200 µs or -500 µs; it does not continuously vary between these values.
This behavior appears to indicate that the PLL locks after adjusting some kind of offset phase.
Could you please explain why the device behaves this way?
Also, please advise us which parameters need to be configured in order to achieve the expected phase alignment.

Best regards,
T.Serizawa

RE: LMK05318B: Unexpected 1PPS Phase Offset Between PRIREF and OUT7

hidetaka hayakawa — Tue, 06 Oct 2026 05:56:32 GMT

We would greatly appreciate it if you could conduct the experiment and share the results with us.

As additional information, we checked whether any noticeable frequency drift occurred on the 19.2 MHz clock during the software reset, but no noticeable frequency drift was observed.

We have attached the captured XO waveform (GREEN) during the software reset. BLUE and RED similarly represent PRIREF and OUT7, respectively.e2e.ti.com/.../sample.mp4

RE: LMK05318B: Unexpected 1PPS Phase Offset Between PRIREF and OUT7

Octo Halsema — Tue, 06 Oct 2026 05:06:25 GMT

Hi hidetaka,

Interesting result.
The oscillator startup time of SIT5501AI is typically 2.5 ms and Time to Rated Frequency Stability is <1.6 seconds.
So there is no warmup problem expected that causes the phase offset.
Somehow the ZDM condition is not met. I will do lab experiment today.

RE: LMKDB1104: Slew rate measurement faster than spec

Michael Srinivasan — Tue, 06 Oct 2026 00:06:08 GMT

Hi Oliver,

I just confirmed with design, this is incorrect. You can both read and write.

Thanks,

Michael

LMK01801BEVAL: Having Trouble with Signal

Qi Liu — Mon, 05 Oct 2026 01:49:02 GMT

Part Number: LMK01801BEVAL

Hi, Ive got this board and I'm just having trouble downsampling my 1 ghz sinusodal (+-400mv) signal going into Clk in 1 to any output on clk out 12 (attempting at 10MHZ). Im wondering if therees any specifications that I am missing. When I have the EN PN cntr in and everythign set to U wire I do get a TTL signal but one that is not correct. When I pull it i get no output and continue to get no output after ptogramming

Best Regards,

Jeremy

RE: LMK01801BEVAL: Having Trouble with Signal

Michael Srinivasan — Mon, 05 Oct 2026 23:39:23 GMT

Hi Jeremy,

Can you reattach the image you shared? I am not able to see it.

Furthermore, can you share how you are configuring your input? You must bias the unused terminal of the input to the midpoint of swing range. You must also make sure you do not violate the VIH and VIL constraints in the datasheet.

You shared that your signal is 800mVpp, which is acceptable. It does need to be biased in such a way such that the low end of its swing is 0.0V or greater (this requires a bias of 400mV or more). The unused pin should be biased to that exact same voltage.

Thanks,

Michael

RE: LMX1205: LMX1205 SYSREFREQ_VCM Register Setting, SYSREFREQ Bias Requirement, and CLKIN Bias Network Necessity

Noel Fung — Mon, 05 Oct 2026 23:29:56 GMT

Hi There,

When SYSREFREQ_VCM = 0, 1, or 2, internal bias voltage will be setup. SYSREFREQ_VCM_OFFSET defines the offset voltage between SYSREFREQ p and N pin.

If SYSREFREQ input is DC-coupled, SYSREFREQ_VCM should be set to 0x3, i.e. no internal bias. Care must be taken that the acceptable Vcm is 1.0V to 2V.

CLKin pins have internal bias, both pin has the same bias voltage. Since CLKin is AC-coupled, if there is no input clock signal, CLKout may be chattering. The external bias network is used to setup an offset voltage between the pins so that CLKout would not chattering even if there is no input clock signal. This network is optional.

LMX1205: LMX1205 SYSREFREQ_VCM Register Setting, SYSREFREQ Bias Requirement, and CLKIN Bias Network Necessity

Hori Shota — Mon, 07 Sep 2026 12:29:45 GMT

Part Number: LMX1205

Hi team,

I have several questions regarding the LMX1205 input biasing recommendations.

Q1: About SYSREFREQ_VCM (Table 6-15 in the LMX1205 datasheet)

My understanding is that SYSREFREQ_VCM does not provide an internal VCM bias. Instead, it is a register setting used to match the common-mode voltage (VCM) present at the SYSREFREQ input pin.

Is this understanding correct?

Q2: SYSREFREQ input biasing

For the SYSREFREQ pin, is an external circuit to bias the input to a specific VCM required?

In the LMX1204 datasheet, a recommended SYSREFREQ biasing circuit is shown. However, I could not find a similar recommendation in the LMX1205 datasheet.

Can the SYSREFREQ pin of the LMX1205 be connected without a dedicated VCM bias network, or is external biasing still required?

Q3: CLKIN bias network

The LMX1205 datasheet recommends a bias network for the CLKIN input. However, I do not see this circuit implemented in the LMX1205 EVM schematic.

Could you please clarify whether the CLKIN bias network is required for normal operation? If not, under what conditions can it be omitted?

Best Regards,

Shota