I am happy to announce the launch of the RFSoC-MTS repository. This repository demonstrates the RFSoC’s Multi-Tile Synchronization (MTS) capability with the ZCU208. The repository is located at: GitHub - Xilinx/RFSoC-MTS: A PYNQ overlay demonstrating AMD RFSoC Multi-Tile Synchronization (MTS).
Multi-tile synchronization is an important capability of the RFSoC enabling beamforming, phased RADAR arrays, massive MIMO and more. In the figure below, data is captured first without MTS (left). The RFSoC tiles run independently from one another. However, if deterministic latency is required and the clocking requirements are met, both DAC and ADC tiles can be synchronized (right). When enabled, MTS allows phase aligned generation of DAC samples and capturing of ADC samples.
The provided overlay and notebook demonstrate this capability by looping back DAC generated samples to the ADC tiles. Samples are generated from an internal DAC RAM and captured to internal memories as shown in the figure below. The overlay also uses the PL DDR4 memory to capture more samples.
8 Likes
Is it available for ZCU111 and/or the 4x2 board as well?
1 Like
Any plans for adding support for MTS across devices with enabled ADC/DAC NCOs?
Hi everyone,
There are no plans yet to release this design for the ZCU111.
You can still use MTS if you use the DAC DUCs and ADC DDCs. However, the settings do need to be identical. Enabling MTS configures a daisy-chain between adjacent tiles. The settings are discussed in PG269.
The wizard for the RF Data Converter will enforce the constraints for MTS. However, it does not validate the user_sysref_adc or user_sysref_dac clocking. PG269 discusses the clock relationships.
But with regards to your NCO question, you can enable the DDC, decimate and perform complex mixing with a “fine” NCO. MTS is still supported and you can still change the NCO frequencies at run-time.
.
Thanks @njachimi How about the RFSoC 4x2 board? Is it supported on that?
Thank you @njachimi , I’ve implemented the digital feature sync procedures in my configuration scripts and I think I got the DAC NCOs to synchronize across two ZCU216 boards but the ADC NCOs seem to not align. I’m sure there is something that I’m missing.
Enabling multi-tile sync across multiple boards is going to require insuring that your SYSREF is distributed properly to each board. It is no secret that the technique used in the RFSoC is based off of the same used for JESD204.
It may be difficult to phase align SYSREF from board to board. It is advisable to provide the SYSREF signal from a clock generator board (ie CLK104), test equipment (ie the 10MHz reference) or another clock distribution chip that can phase align the reference signal throughout the system. Matched length cables, connectors and adapters are a must. So first you should verify that the distributed reference signals are arriving in-phase to each of your boards. Using an oscilloscope with matched length BNC cables can be a quick peace of mind thing to verify.
Below are two references regarding JEDS204 SYS REF alignment issues that may be of help to you moving forward.
-
Synchronizing Multiple ADCs Using JESD204B | Analog Devices
-
https://ez.analog.com/fpga/f/q-a/550189/jesd-204b-multiple-board-synchronization-issue
-
See page 170 of Documentation Portal
Hopefully this gets you aligned.
Regards,
-N
1 Like
Thanks, I have that part already figured out and the SYSREFs from the 2 boards are perfectly aligned to within 20-40 ps.
Hi Aravind,
Some minor changes are necessary to enable this example for the RFSoC4x2. The ADC and DAC tiles have a different clocking configuration that is still MTS capable, however, we have not yet scheduled a release date for this board’s overlay.
Regards,
-N
Hi @njachimi, thanks for the design. I was wondering what you mean by “the settings do need to be identical”. Does it mean if i do DDC at receiver end with NCO freq=-1GHz, then I have to do DUC at Tx side with NCO freq = 1GHz? Or does it mean I must use NCO at Tx if I use NCO at Rx? Thanks!
Hi Tobias,
The RFDC Wizard will quietly turn off the MTS checkbox on you when you have settings that MTS does not service, so you have to iterate a little as you select your ADC and DAC tile settings. MTS is partitioned by DAC and ADC. Across your DAC or ADC tiles, you need identical settings. The NCO frequency itself does not have to be common across your tiles, but only its type Coarse or Fine. For example, if you want MTS enabled for all of your DAC tiles, but use the DUC in 2x interpolation and Fine NCO, all of the DACs part of the MTS array need identical DUC settings. If you need a DAC tile with a different DUC setting then it would not be part of the MTS array. A solution to that would be to just make that DAC channel your last one since MTS requires chaining the tiles together.
Regards,
Nathan
Hi Nathan, @njachimi
Thanks a lot for the swift answer! I see, ADCs and DACs partition the MTS. Such that settings in ADCs won’t affect DACs, but along ADC or DAC tiles settings should be consistent.
Regards,
Tobias
Hi @njachimi ,
I just noticed the XRFdc_MultiConverter_Init function prototype added with the xrfdc_mts.patch patch file matches the version used with usp_rf_data_converter:2.4 but the actual overlay design uses usp_rf_data_converter:2.6 which has an extra argument in the same function.
Similarly, the XRFdc_GetClkDistribution function arguments and XRFdc_Distribution_Settings structure are not updated to match the latest version (v2.6) of the RFDC IP.
Attached are two versions of the xrfdc_functions.c file that correspond to RFDC IP v2.4 & v2.6.
xrfdc_functions_v2p4.c (20.7 KB)
xrfdc_functions_v2p6.c (20.8 KB)
Given the above, does this mean the libxrfdc.so is still built for the older version (v2.4) of the RFDC IP? Any plans for upgrading the driver code?
Thanks,
Shant
1 Like
Is the lack of plans for supporting the ZCU111 because it can’t be done on that board / chip set, or
simply due to focusing the work on fewer platforms?
1 Like
