Xrfclk configuration | LMK04828 | Using external 10MHz reference clock

Hello,
I am working on RFSoC4x2 (Gen3 XCZU48DR) with PYNQ version 2.7.0 and vivado 2020.2

My primary requirement is to configure LMK04828 chip onboard to take external 10MHz ref clock input and produce 245.76MHz to feed to LMX2594 chip which, in turn, is generating 409.6MHz. I did generate .tcs (and .txt) configuration file for the same and added the corresponding .txt file (i.e. LMK04828_245.76.txt) in xrfclk package in JupyterNotebook environment (path: /usr/local/share/pynq_venv/lib/python3.8/site-packages/xrfclk). Also, I am setting these clocks using command
xrfclk.set_ref_clks(lmk_freq=245.76,lmx_freq=409.6)

Now the problem is- My design is working even when I am not feeding the external clock to the board which means it’s definitely taking driving_clock from other input pin and I can’t figure out which one .

Could you please guide and help me resolve this issue?

Here is my hex register (.txt) file for the reference and also some snaps which might be helpful for you to understand the issue more clearly.

LMK04828_245.76_clkin1_disabled.txt (2.0 KB)




txt_files_xrfclk

The hex reg file uploaded for the reference has name for personal reference. I rename it and follow standard naming convention when I add that file to xrfclk package.

The RFSoC4x2 provides SYNC to each of the LMX chips. From the schematics the LMX_ADC accepts this at SD_CLK_OUT1 and LMX_DAC at SD_CLK_OUT5. I suggest you contact TI tech support to configure your TICS projects for the settings you need, however, I can point out a few features to notice…

What you will need to do is to set the LMK04828B’s CLKin0 to drive the SYSREF Mux.

image

You were on the right track with the SYNC/SYSREF, but just needed to change the value here:

The TICS GUI is not updating certain things it seems. And I was not able to get the 10MHz reference clock from CLKin0 to drive out the LMXs at the right outputs. So I would reach out to TI support to guide you further on this.

Regards,

Nathan

@kbhopi94 Please provide an update if you are able to get it working. I will need to do this eventually too. I have been experiencing some challenges with the LMK chip on the RFSoC4x2. I also produced a custom file in TICs and programmed the chip with it and it’s not behaving as expected. I talked to Texas Instruments support and they verified the file was correct and they were able to use it to program an LMK04828 eval board and get the correct clock outputs. The eval board for the LMK is a different board design than the RFSoC4x2 so I’m currently combing through that to see if I can figure out the discrepancy. I’ll let you know if I figure anything out.

@kbhopi94 I just discovered I’m not programming the device correctly and that’s why it’s not behaving. I’m still looking for the error but it seems like it’s programming the chips with the default hex files that ship with the PYNQ image instead of the hex file I directed it to. This may be what’s happening to you as well.

Hi Jenny,

Even I gave it a thought but I literally replaced their LMK04828_245.76.txt file (which I suppose takes input from CLKin_1 pin) with mine and I even confirmed whether the changes I made in a replaced file in xrfclk package are getting reflected by checking (and by changing frequency couple of times) unloaded SMA pin (i.e. SDCLKout11) and it’s working. This means it’s definitely reading the file given by me BUT most probably I am not configuring it right to take 10 MHz input from CLKin_0 pin. I will give an update if I get it working.

Cheers,
Kalyani

@njachimi
TI support would be highly appreciated. I will also try to reach out to them. I will see if making the changes you suggested will make it work and update you at the earliest. Thanks!

@JennySmith888 Meanwhile would you mind sharing your tics (.tcs) file and I can see if I can make it work.

Cheers,
Kalyani

@njachimi

Well, I don’t understand one thing here from what you suggested. Changing CLKin0_OUT_MUX option to SYSREF_MUX will block the path from CLKin0 to PLL1 which makes no sense to me as I am getting the desired output frequencies (245.76MHz) to drive LMX chips from PLL1&2 configuration. My requirement is to take ext ref clock of 10 MHz instead of board clock and generate 245.76 MHz frequencies to drive LMX chips. Thanks!

I first examining if I could use the 10MHz input on CLKin0 to be the SYSREF, but I wasn’t able to get it to route out clock distribution. I mentioned that and so what looks like the only option is then to use PLL1. What I haven’t gotten a clear answer on using TICs so I’m currently checking with TI support is how PLL1 steers the RFSoC4x2’s 160MHz VCXO and what settings should be given to PLL1. I’m trying to replicate the loop mode described in the LMK datasheet and shown below:

and in TICS, PLL1 is fed from the 10MHz reference

My next concern is related to the LMX2549s’ that have SYNC inputs. I am not able to provide 10.0MHz. Our LMK04828 via PLL1 should be now using the 10MHz reference you would provide, so both LMX2549s will be provided in-phase clocks, however it would be likely then that a 9.99 or 10.03MHz reference would be sufficient so I would try initially while I can get some clarification from TI.

Regards,

Nathan

Any progress on this? I’d love to use a 10 MHz GPS disciplined oscillator to make a 10 MHz RF SYS REFCLK or SYSREF, along with a nice round sampling rate.

With the LMK, is it possible to use a 10 MHz Ext. Ref. Clk if it’s plugged in, and the 160MHz VCXO OSC IN otherwise? Or do you need to explicitly load one or the other configuration?

As a starting point, is there a repository for the original .tcs files that can be opened in the TICS Pro for RFSoC 4x2’s? For example, the .tcs files that generated LMK04828_500.0.txt and LMX2594_500.0.txt in RFSoC-MTS/boards/RFSoC4x2/xrfclk at main · Xilinx/RFSoC-MTS · GitHub ?

To integrate with and compare to our other astronomy and instrumentation, round numbers and powers of 2 are nice. I’d love 4 GSPS or 5 GSPS. Even the Gen1 4096 MSPS makes nice FFT spectral bins that are 1 MHz wide and a RAM capture that is a microsecond long (or twice these or half of these or whatever). The obsession with 7.68, 122.88, 245.76, 491.52, and 3932.16 MHz seems to stem from the 300 Hz/baud Bell 103 modem from 1962. This factor of 3 seems to have seeped into all comms rates ever since.

Thanks,
Jason