Hi, I am working with the RFSoC 4x2 board and would like increase the DAC sampling rate to 9.8 GSPS as advertised in the manual. I looked at past forums and it seems it can be set using xrfdc driver but I am confused how this would be done. Thanks alot.
I’ve just recently started working with PYNQ, vs. bare metal RFSoC… but I believe you can change the DAC rate using the initialise_dac() function.
E.g. from this notebook: rfsoc_qsfp_offload/boards/RFSoC4x2/rfsoc_qsfp_offload/notebooks/rfsoc_offload_board.ipynb at master · strath-sdr/rfsoc_qsfp_offload · GitHub , changing the DAC_SAMPLE_FREQUENCY value in this code block should change the DAC rate:
DAC_TILE = 0 # DAC Tile 228
DAC_BLOCK = 0 # DAC Block 0
DAC_SAMPLE_FREQUENCY = 4915.2 # MSps
DAC_PLL_FREQUENCY = 491.52 # MHz
DAC_FC = 0.0
ol.initialise_dac(tile=DAC_TILE,
block=DAC_BLOCK,
pll_freq=DAC_PLL_FREQUENCY,
fs=DAC_SAMPLE_FREQUENCY,
fc=DAC_FC
)
Though note that changing the DAC_PLL_FREQUENCY won’t automatically reconfigure the clock chips (you need to create a new LMK and LMX register file for the corresponding frequencies).
And also note regarding the 9.8 Gsps rate - that’s only supported in Datapath Modes 2-4. From a lot of the examples I’ve seen, it seems most use Mode 1 (Full Nyquist DUC), which is limited to 7 Gsps.
I can’t speak much about the initialise_dac() function in PYNQ, but based on my experience using the RFSoC 4x2 in bare metal, I can add some context regarding the 9.8 GSPS rate.
You can indeed only reach 9.8 GSPS by using Datapath Modes 2 to 4. This is because these modes enforce an inherent 2x interpolation. Essentially, it relies on oversampling, so your baseband data rate isn’t actually 9.8 GSPS :
As you can see here, these datapath modes impose an ‘effective interpolation’ of 2x. Therefore, whatever base interpolation level you configure is multiplied by 2, which allows the DAC output to reach the 9.8 GSPS hardware limit.
I might be slightly off since I’m only an intern and just figuring this out through hands-on experience with the board, but this is how I understood it.
Hi @DogP ,
@Alexandre_Chfr is right. If you check their overlay.py, you would see which configs they are updating. If you check their block design, you would see why they gave those values. So, you need to change the values in Vivado to run at 9.8 GSPS.
Best
@mtsanic I don’t completely follow what you’re saying… the first line of initialise_dac() calls:
self.rfdc.dac_tiles[tile].DynamicPLLConfig(1, pll_freq, fs) which I believe ends up calling the RFdc driver API XFRdc_DynamicPLLConfig() : AMD Technical Information Portal .
That function configures the RF-ADC and RF-DAC PLL: AMD Technical Information Portal . From that, the PLL output frequency is Fs = (Fin/R)*(FBDiv/M) . The two arguments passed into the function are pll_freq (reference frequency) and fs (desired sample rate). pll_freq is just an input to the equation (it needs to know what the reference frequency is), and from that, it computes the other values to make fs, using the valid PLL parameters:
| Reference Divider (R) | Feedback Divider (N) | Output Divider (M) | VCO Frequency (GHz) |
|---|---|---|---|
| 1 to 4 | 13 to 160 | 1, 2, 3, 4, 6, 8,… (even numbers ≤ 64) | 7.863 to 13.76 |
Note that while R can be 1-4, the datasheet says it’s only characterized for 1, and the phase noise performance is best at 1.
Anyway, as stated in PG269:
The operating parameters of the PLL are set using the AMD Vivado™ IDE to specify the default PLL configuration or by the RFdc driver API if runtime adjustment of the PLL is required. The PLL must first be enabled in the Vivado IDE if runtime adjustment using the API is required.
Vivado is used to specify the default PLL configuration, but I believe the RFdc driver API is what PYNQ is providing access to with the initialise_dac() function, allowing runtime adjustment of the PLL.
Have you actually tried changing the sample rate with the initialise_dac()function? While I haven’t done an extensive characterization, I have set the sample rate only by changing parameters to initialise_dac(), and have done several tests creating tones at offset frequencies using various sample rates, and having them appear at the correct frequency on a spectrum analyzer… as well as creating wideband noise, and watching the bandwidth increase/decrease with the change in requested sample rate. So I’m fairly certain that the functionality of setting sample rates at runtime actually works.
Specifically regarding the 9.8 Gsps rate, as I mentioned above, that’s only available in Datapath Modes 2-4 (I believe the default PYNQ uses Mode 1), so changing the mode will also be required… and of course supporting whatever data rates are required.
Hi,
Thanks for the insightful and detailed answer, I honestly have learned a lot from it. From what I gathered, you can change the sampling frequency based on the given modes and clock frequencies.
I didn’t use this design before, just went with your question. I realized the differences between our systems, I am working with real data with MTS enabled, which I believe requires additional steps. I will test out when I have the time for it.
Best