Once the hardware requirements detailed above for Sysref and clocking are
met, there are two API functions required to perform MTS on a device. The first, XRFdc_MultiConverter_Init is used to setup which tiles are
to be synchronized and from Vivado Release 2021.1. The second is the reference tile,
which is used as the basis for calculating latency mismatch across FIFOs.
As part of the MTS process, Sysref is distributed to each tile and scanned by each sampling clock period (T1) in use in the clock system of the targeted tile set. This ensures RFDC sub-system can safely capture Sysref on each RFDC tile. In first and second generation of RFSoC devices, all sampling clocks of tile set were required to be scanned when in use. RFSoC Gen3 provides the ability to forward clocks using the on-chip clock distribution, there are multiple clock distribution scenarios which mean that only a subset of available tiles need to be scanned in a device. In general, when using on-chip clock forwarding feature, you should set the sampling clock source tile which is distributing the clock as the reference tile. In first and second generation of RFSoC devices, the reference tile parameter can be left at the default value of 0.
The MTS process can then be completed using the second API function XRFdc_MultiConverter_Sync. This API function will
distribute sysref signal to each tile, determine the optimal capture code and align
FIFOs to achieve synchronization across tiles. Refer to
Zynq UltraScale+ RFSoC RF Data Converter LogiCORE IP
Product Guide (PG269) for details.
When this is complete, the metal log can be viewed to check the procedure to capture Sysref on both the analog and PL side completed as expected and that FIFO alignment has also been achieved. This will also provide debug information in the case where MTS is not functioning as expected.
An example of a typical metal log for the case where we are distributing a sampling clock using on-chip RF-PLL from ADC Tile 2 to all other ADC Tiles using a ZU48DR device is shown below (DTC scan codes are incomplete).
Info:
DTC Scan PLL
Info: ADC2:
13220000000000011322000000000011132200000000001112220000*0000011#2220000000
Info:
DTC Scan T1
Info: ADC2:
0000000000000000000000000000000011132220000000000000000000000000#0*00000000
Info: ADC0:
000000000000000000000000000001132220000000000000000000000000000*00#00000000
Info: ADC1:
00000000000000000000000000000001132220000000000000000000000000000*#00000000
Info: ADC3:
000000000000000000000000000000001112222000000000000000000000000000#*0000000
Info: ADC0: Marker: - 9, 8
Info: ADC1: Marker: - 10, 4
Info: ADC2: Marker: - 10, 4
Info: ADC3: Marker: - 10, 4
Info: SysRef period in terms of ADC T1s = 384
Info: ADC target latency = 116As can be seen in the log, the DTC (Delay Tap Chain) scan on the Sysref, is only performed for the PLL in ADC2. The 0’s in each scan represent a safe area in which to sample Sysref and the 1’s, 2’s and 3’s represent the Sysref edge as scanned in the DTC. The # represents the starting scan point and is always set to tap 64 out of 128 for the reference tile. The * represents the safe sampling point determined by the scan. This is used as the starting point for subsequent tiles.
In the above example, lengths of chains of 1’s, 2’s and 3’s are fine. Longer chains of 1’s, 2’s and 3’s in the scan can indicate too much jitter is present on the Sysref capture, it will error out with DTC scan failed. If a reliable sampling point cannot be attained, MTS cannot perform effectively.
After the DTC scan, information on the marker counter value and the location of the marker in the FIFO is shown. Referring to the log above and for ADC0, the marker counter value is 9 and the marker location is word 8. The marker counter values should be reasonably close in value for each tile and the marker location should be within the width of the FIFO. For example, if the FIFO width is set to 12, then a marker location of 14 indicates that the FIFO may be in under/overflow or that there is an issue with the PL clocking setup which warrants further investigation.
The Sysref period is reported in terms of T1’s. Incorrect values here can indicate an issue capturing Sysref in the PL. Ensure all clocking requirements are met and the recommended Sysref capture scheme is utilized as detailed in Zynq UltraScale+ RFSoC RF Data Converter LogiCORE IP Product Guide (PG269).
Finally, the ADC/DAC target latency is reported which is the maximum latency through the tiles after FIFO adjustments have been made. A small piece of code can be added to report latencies and adjustments made for all tiles.
// Report Overall Latency in T1 (Sample Clocks) and Offsets (in terms of PL words) added to each FIFO
metal_log(METAL_LOG_INFO,"\n=== Multi-Tile Sync Report ===\n\n");
for(i=0; i<4; i++) {
if((1<<i)&DAC_Sync_Config.Tiles) {
XRFdc_GetInterpolationFactor(RFdcInstPtr, i, 0, &factor);
metal_log(METAL_LOG_INFO," DAC%d: Latency(T1) =%3d, Adjusted Delay Offset(T%d) =%3d\n", i, DAC_Sync_Config.Latency[i], factor, DAC_Sync_Config.Offset[i]);
}
}
for(i=0; i<4; i++) {
if((1<<i)&ADC_Sync_Config.Tiles) {
XRFdc_GetDecimationFactor(RFdcInstPtr, i, 0, &factor);
metal_log(METAL_LOG_INFO," ADC%d: Latency(T1) =%3d, Adjusted Delay Offset(T%d) =%3d\n", i, ADC_Sync_Config.Latency[i], factor, ADC_Sync_Config.Offset[i]);
}
}Info: ADC0: Latency(T1) = 116, Adjusted DelayOffset(T1) = 8
Info: ADC1: Latency(T1) = 116, Adjusted DelayOffset(T1) = 0
Info: ADC2: Latency(T1) = 116, Adjusted DelayOffset(T1) = 0
Info: ADC3: Latency(T1) = 116, Adjusted DelayOffset(T1) = 0It is important to note that latency here refers to latency through the FIFO relative to when analog Sysref and Digital Sysref are detected at either side of the FIFO and is not a true representation of latency through the tile.