If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

# CDCLVC1310-EVM: Sine input - square output

Part Number: CDCLVC1310-EVM

Hi
I'm building a clock distribution network using a 10Mhz Rubidium standard as an input signal. The signal is a sine wave (1.5Vpp). The other instruments (that should be provided with this clock reference) require a square input as provided by the circuit. I tried to simply feed the sine signal into the PRI_INP port and got a square output. Unfortunately this only holds true for low supply voltages of up to 1.8V, above that the board does not output a signal at all. In addition the output signal shows non-square like artifacts for all voltages. Hence I'm wondering why I do not observe an output signal above 1.8V (square turns into dirac pulse and vanishes ) and whether the output signal is reliable in terms of frequency and jitter. In other words: can I reliably the circuit board for my particular task below the somewhat arbitrary 1.8V?

Thank you!

• Hello Johannes,

What Vdd are you using?
What Vddo are you using?

I recommend taking a look at the Absolute Maximum Ratings table, the input voltage must lie between -0.5 V and VDD + 0.5 V. Also please take a look at the input characteristics table to determine whether your input signal is valid. Is it single-ended/differential, AC/DC?
• Hello,

Thank you for your quick response.

1.) I'm currently feeding my signal into the PRI_INP (single ended DC). This particular signal has a sine format (atomic clock), 10Mhz, with 1.5Vpp, no offset. For the core supply voltage I chose +3.3V (VDD), and for the output supply voltage +1.6V (VDDO), rather arbitrarily. My goal is to get a square output signal with 10Mhz and 0.25V<Vpp<1.5V. Are my settings correct?

2.) I read about the 2V/ns input edge rate which I am obviously not reaching with the 10MHz sine input. Is that a problem? In which way does it affect the circuit/output signal? Do I have to expect a frequency shift, modified signal? I am wondering since all my devices that are provided with the output signal (input is the sine signal described above) recognize it as a valid reference clock signal, although when looking a the signal with a scope, I am observing strange features that are certainly not square-like. Or can I simply use a different input port (oscillator, PRI_IN) to reach my goal?

• 1.) I'm currently feeding my signal into the PRI_INP (single ended DC). This particular signal has a sine format (atomic clock), 10Mhz, with 1.5Vpp, no offset. For the core supply voltage I chose +3.3V (VDD), and for the output supply voltage +1.6V (VDDO), rather arbitrarily. My goal is to get a square output signal with 10Mhz and 0.25V<Vpp<1.5V. Are my settings correct?

2.) I read about the 2V/ns input edge rate which I am obviously not reaching with the 10MHz sine input. Is that a problem? In which way does it affect the circuit/output signal? Do I have to expect a frequency shift, modified signal? I am wondering since all my devices that are provided with the output signal (input is the sine signal described above) recognize it as a valid reference clock signal, although when looking a the signal with a scope, I am observing strange features that are certainly not square-like. Or can I simply use a different input port (oscillator, PRI_IN) to reach my goal?
• 1) For Vdd = 3.3 V the datasheet lists VIH > 2 V and VIL < 1.3 V. I believe your 1.5 Vpp with no offset will cause issues. A fix for this is using a higher Vpp input, or Vdd = 2.5 V in which case the Vpp requirement is still not met but closer. Please refer to "Single-Ended DC Characteristic (PRI_INP, SEC_INP)" section of the "Input Characteristics" table.

2) The issue you see here may be related to the above, please let me know if the output signal still looks the same after the input Vpp is corrected.
• Hello Johannes,

I received a notification that the above didn't solve your issues. Could you please describe what happened when you tried the above. Additionally oscilloscope screenshots at the input and output, may help further debug the issue.