Generate and digitize arbitrary waveforms

Support
1

Hello,

I would like to know if anyone has already try to generate and digitize arbitrary waveforms with a RF SoC and espically with the RF-SoC 4x2 ? In other words, I would like to use RF ADC/DAC as standard ADC(digitizer in baseband)/DAC (AWG in baseband) at GSPS.

I’m fully aware that such an objective requires some HDL developements.
Best regards,

Christian Jammes

1 Like
2

Hi @cjammes,

Welcome to the PYNQ community.

I suggest you review this project GitHub - Xilinx/RFSoC-MTS: A PYNQ overlay demonstrating AMD RFSoC Multi-Tile Synchronization (MTS).

Mario

1 Like
3

Hi @marioruiz I’m trying to use the same project (on the RFSoC 4x2) to generate arbitrary waveforms at higher sample rates. The default design runs at 4GSPS on both ADCs and DACs.
The limits of the RFSoC 4x2 are 5GSPS for the ADCs and 9.85GSPS for the DACs and I want to reach that sample rates.

I managed to run the Jupyter notebooks 5GSPS (ADC) at 8GSPS (DAC) by updating the block design from Vivado and building it again. It works as expected when I inspect the oscilloscope. However, when I try to push beyond that sample rate (i.e. 9 or 9.85, or even 10 GSPS), the oscilloscope clearly shows that the DAC is still producing signals at 8 GSPS.

These are the steps I followed to update the DAC from Vivado (to get first 8GSPS and then more):

  • opened the RF Data Converter block
  • Basic > RF-DAC > 16 samples per AXI4-Stream Cycle and “No DUC to Fs/2” for all the DAC tiles
  • System clocking > I selected the new sample rate
  • I updated the data width of the port connected to match the 16 samples (previously 8 in the original design): hier_dac_replay, axis_broadcaster.

Do you have any idea why is it still emitting signals at 8GSPS even though my RFDC is configured for 9, 9.85 or 10 GSPS? Is it possible that I’m misconfiguring something or could it be because of a wrong clock setting in the jupyter notebook (LMK and LMX)?

These are the system clocking settings and DAC configs for 8GSPS

image
image1236×777 67 KB

1 Like
4

While the following for 9.85 GSPS:

image
image1236×777 77.3 KB

6

Hi @rameloni
I’m trying to replicate what you’ve done. I followed the steps you described and have the same settings as in your screenshots for 8GSPS. However when I attempt to synthesise and implement I get different bus width errors (see below)

image
image727×346 7.54 KB

I fixed these issues, however once the bitstream generated I had negative slack time errors in the setup timing of the deepCapture module.
Are these issues you also came across? If so how did you resolve them?
Kind regards, Tom

7

I have since solved all the issues I was having before and figured I should elaborate on how I fixed the current issues.

To get up to 8GHz
First I followed the proposed changed by @rameloni to the RFDC block (changing from 8-16 samples per cycle and increasing the sample rate to 8GHz (DAC) and 5GHz (ADC). Ensure you leave the reference clock at 500MHz (more on this later)

After this, expand the hier_dac_player

image
image1052×383 69.2 KB

the axi_bram_ctrl_0 needs to have it’s data width updated to 512. The same needs to be done for the DACRAMstreamer (the blk_mem_gen_0 will update automatically when generating a new synthesis/implementation as it’s set to take params from the axi_bram_ctrl_0). For the DACRAMstreamer, double the number in Mem size bytes. Doing this will require you to also increase the xlconstant_0 block, double this number as well.

Then in Address controller update the axi_bram_ctrl to be double the size (in the picture I have increased to it’s maximum possible size, but to test I started by doubling it)

image
image1007×534 172 KB

After this adjust the axis_clock_convertor, axis_dwidth convertor, and axis_register slice to appropriate sizes (64 bytes before the dwidth convertor and 32 after the convertor).

I then found to get it working properly, I had to delete the axis_broadcaster_0. I am not sure if this was an issue with my board of the IP block itself, but increasing the input to 64 byte and the outputs to 32 bytes resulted in it causing a strange phase jumping that completely messed up the output. As I only needed 1 DAC I routed the output of the hier_dac_player directly to the s20_axis pin on the usp_rf_data_convertor_1

This allowed me to successfully generate signals up to 4GHz on the output of DAC_A

To get to 9.85GHz
The reason setting the sampling rate higher then 8 won’t do anything is the axi streaming clock (the one that dictates how fast samples are passed to the data convertor) is running at 500MHz, and since the maximum number of samples being passed in per clock cycle is 16, the fastest you’ll ever be able to go with this overlay is 8GHz. The bottle neck here isn’t the sample clock, it’s the axi stream clock and how fast it can pass data to the rf data convertor.

It is possible however to increase the spead of that clock. It is set by the on board clock chip (LMK04828 or LMX2594, not sure which one it actually pulls from for the stream clock) which the MTS overlay automatically configures when you load it. These are set by text files that can be found in the MTS overlay. I believe these are generated by a Texas Instruments software and it should be possible to make your own and try get them to run faster so you can pass samples in faster. I have not attempted this yet though as I am currently working on being able to get DAC_A and DAC_B to operate independently with their own buffers. If I manage this I will likely reply here again or make a new post detailing that

2 Likes