0
\$\begingroup\$

I have the VC707 FPGA board and an external reference clock (fairly clean 100MHz), that I want to use as a reference for a 200MHz generated clock on my board. Then using this clock to clock my DACs (differential and interleaved). So maybe the DAC3152 or the DAC3154.

Firstly the Input Clock for these DACs is (LV)PECL:

enter image description here

which isn't available in my FPGA settings, so I might go for this alternative, that is mentioned in the datasheet, but not recommended (I think, this might be because the LVDS threshold for sampling clock input is above the recommended):

enter image description here

Would this work? The DACCLK is also internally self-biased, so it might just work with this AC-coupling alone. I'm also looking for an option to get a clean low-jitter clock from the FPGA. TI offers some solutions e.g. buffering CDCLVP1102, but I'm not that experienced to understand this correctly. This will definitely introduce a delay to the signal, which is in my case very critical, since I'm also using a reference clock.

Are there any alternatives to this? I'm also looking into the clocking wizard from Vivado, there might be a way for a low-jitter output on some I/Os, but I want to leave this last.

\$\endgroup\$

2 Answers 2

4
\$\begingroup\$

As far as I know, FPGA are never a good choice to source a clock from, if you care about jitter. And with DACs, you almost certainly do care.

Use a PLL based clock buffer, that provides a synchronous, low-jitter ECL clock and run this into your DAC. Use the FPGA only for the data lines.

\$\endgroup\$
2
  • \$\begingroup\$ That would be hard to do for my design. I need to get the clock to be very accrate at the DACs (8 channels) and even with good routing for LVDS (length-matched) the clocks are going to be almost about 60-100ps a part from each other. If I do this with the FPGA, I might be able to use ODELAY2 to compensate, but if this happened from (e.g. Si5395), I wouldn't be able to do anything about it. How do you see it? \$\endgroup\$ Nov 16, 2023 at 9:11
  • 2
    \$\begingroup\$ @johnny_1010 After a quik view at the 3154 datasheet: The skew between the data lines (incl. DATACLK) on the one hand and the DACCLK on the other hand, doesn't really matter. The data lines merely fill a FIFO, so jitter/skew is not so important. But the DACCLK is what has to be low jitter and skew for all DACs, so take only the DACCLK from a buffer. \$\endgroup\$
    – tobalt
    Nov 16, 2023 at 9:43
1
\$\begingroup\$

If the spec for the DACs calls for an LVPECL clock source, you can easily generate a LVDS/LVCMOS clock output from an FPGA, and then utilize a clock buffer to perform the interface translation for you. There's many options for clock drivers, including the SN65EPT22 which will take an LVTTL signal and translate it to LVPECL (https://www.ti.com/product/SN65EPT22).

I'd recommend ODDRE1 to generate an LVCMOS signal out of the FPGA, and an OBUFDS to generate an LVDS signal. Note the Constraints file will need to denote the signal type of the outputs you choose in conjunction with the PCB circuitry.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks for the suggestion! I'm thinking, that I actually can't afford having a prestage buffer like this, since this might introduce a phase-shift to my clock and the synchrnoization between the all DACs will be corrupted. The ODDRE1 is a great idea, thank you for that! I'm already using the OBUFDS for LVDS and was thinking about doin the circuit with 100Ohm and then AC-coupling. The LVPECL is self-biased (said at least in datasheet), so do you think, this will be a problem? \$\endgroup\$ Nov 15, 2023 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.