DAC sampling frequency over 7 Gsps with ZCU208

I received just yesterday the first workaround to bypass the problem. It needs to modify a Matlab file as in the following:

move "configureDACTile" function from line 108 to line 127 in the "CreateRfCfg.m" file.

Execute the following command to obtain the location of the "CreateRfCfg.m" file:

fullfile(matlabshared.supportpkg.getSupportPackageRoot,'toolbox','shared','supportpackages','rfsoc_shared','boards','+ZynqRFSoC','+common','+rfsoc_sw')


Then modify the code at Line 106 as follows:

   for TileId = 0:(rfobj.TotalDACTiles - 1)
       isDAC = true;
%    rfobj.configureDACTile(TileId,PLLSrc,ReferenceClock,DACSamplingRate);
       rfobj.setTileNCOPhaseProp(TileId,MTSEnable,isDAC); %NOTE: We need to explicitly tell the NCO to reset. When using MTS, the setup() routine over-writes this parameter to reset the NCO     
       for ChId = 0:(rfobj.DACChannelsPerTile-1)
           if DACDataPathEn
               switch(args.SysObjStruct.DACDUCMode)
                   case('Full DUC Nyquist (0-Fs/2)')
                       DUCMode = 'FullNyquistDUC';
                   case('IMR Low-Pass (0-Fs/2)')
                       DUCMode = 'IMRLowPass';
                   case('IMR High-Pass (Fs/2-Fs)')
                       DUCMode = 'IMRHighPass';
                   case('DUC Bypass')
                       DUCMode = 'DUCBypass';                       
               end               
               rfobj.configureDACChannel(TileId,ChId,InterpolationFactor,'DUCMode',DUCMode);
           else
               rfobj.configureDACChannel(TileId,ChId,InterpolationFactor);
           end
       end
       rfobj.configureDACTile(TileId,PLLSrc,ReferenceClock,DACSamplingRate);
   end

I noticed that both socModelCreator and HDL Workflow Advisor go ahead in the process, but unfortunately, I have a Vivado error during the project creation:

It seems Matlab is not still able to correctly manage the IMR filter settings. I have to wait for another solution...

Hi McG, Yes changes are needed to Vivado tcl scripts as well, I mentioned this originally.  These changes have been recently implemented and submitted for inclusion in a future release of HDL Coder support package for Xilinx RFSoC Devices.  Unfortunately it is not just a 1 line change to correct this issue, it has to do with how Vivado gets triggered to validate certain properties of the data converters.  The corrections should fix this for both the ZCU216 & ZCU208.

For your situation, I have thought about this but I cannot recommend any work around at this time that I know would work 100%.  You might be able to use HDL Coder Workflow Advisor to go as far as to create a Vivado project with your design except keep the sample rate below 7GHz, then from Workflow Advisor use the link in the Project Create Step to open it up in Vivado and then go and modify the RF Data Converter IP block settings accordingly. Then come back to workflow advisor after you save the Vivado project new settings and try to get it to build the bitstream. The one flaw in doing that might be that there are some other calculations along the way that dictate the sample vector size in the programmable logic and some settings on some of the other programmable logic IP outside the data converter.  When you make the adjustment this way to manually make changes to increase the Fs, you basically want to make sure the programmable logic data/sample widths are not changed.  What you want to do is just make an adjustment after the project creation so that just the clock speed changes.  Keep in mind you will also be restricted to certain fine mixer mode frequencies when using the IMR modes.  You will need to take a look at the AMD-Xilinx PG269 document that explains some of what the IMR mode restrictions are.  So you will also have to also make sure in Workflow Advisor the NCO is set correctly to get a Vivado project to build and then after you tweak the Fs, you may need to adjust your fine mixer frequency again using the Vivado RF data converter IP block settings dialog.  I'd think trying to get as close to 7GHz as possible to get the project to be created would be a good place to start that experiment.  And also, take a look at the RF_init.cfg file and manually and manually correct the SetMixerSettings lines that set the NCO/fine mixer freq.  You'd want to try to edit that before you use Workflow Advisor to program the new bitstream (it also uploads the RF_init.cfg file).  Again, I'm not sure if this will work for your custom design or not, it could just be a waste of time for you to try this.

If I think of anything else I'll update again.

Kind regards

Hi McG, Yes changes are needed to Vivado tcl scripts as well, I mentioned this originally.  These changes have been recently implemented and submitted for inclusion in a future release of HDL Coder support package for Xilinx RFSoC Devices.  Unfortunately it is not just a 1 line change to correct this issue, it has to do with how Vivado gets triggered to validate certain properties of the data converters.  The corrections should fix this for both the ZCU216 & ZCU208.

For your situation, I have thought about this but I cannot recommend any work around at this time that I know would work 100%.  You might be able to use HDL Coder Workflow Advisor to go as far as to create a Vivado project with your design except keep the sample rate below 7GHz, then from Workflow Advisor use the link in the Project Create Step to open it up in Vivado and then go and modify the RF Data Converter IP block settings accordingly. Then come back to workflow advisor after you save the Vivado project new settings and try to get it to build the bitstream. The one flaw in doing that might be that there are some other calculations along the way that dictate the sample vector size in the programmable logic and some settings on some of the other programmable logic IP outside the data converter.  When you make the adjustment this way to manually make changes to increase the Fs, you basically want to make sure the programmable logic data/sample widths are not changed.  What you want to do is just make an adjustment after the project creation so that just the clock speed changes.  Keep in mind you will also be restricted to certain fine mixer mode frequencies when using the IMR modes.  You will need to take a look at the AMD-Xilinx PG269 document that explains some of what the IMR mode restrictions are.  So you will also have to also make sure in Workflow Advisor the NCO is set correctly to get a Vivado project to build and then after you tweak the Fs, you may need to adjust your fine mixer frequency again using the Vivado RF data converter IP block settings dialog.  I'd think trying to get as close to 7GHz as possible to get the project to be created would be a good place to start that experiment.  And also, take a look at the RF_init.cfg file and manually and manually correct the SetMixerSettings lines that set the NCO/fine mixer freq.  You'd want to try to edit that before you use Workflow Advisor to program the new bitstream (it also uploads the RF_init.cfg file).  Again, I'm not sure if this will work for your custom design or not, it could just be a waste of time for you to try this.

If I think of anything else I'll update again.

Kind regards

Hello, it was 2 years ago. Do you have any updated news? Was this ever solved? I am having the same issue with a ZCU216 

Thanks in advance

Hi,  No updated news, but I will re-communicate the issue.  In the thread above is an email addres to reach out to MathWorks or if you have paid support, please approach them with the issue.  MathWorks fully own the ZCU216 support and tools, and most of the affected peices are re-used for the ZCU208 but Avnet doesn't directly control those parts.

Kind regards

Hi, I did reach out to MathWorks and we re-concluded the original poster's issue was resolved.  There was an official trouble ticket created for this issue and the code modifications were officially released for R2023a via the HDL Coder for RFSoC support package.  For the ZCU216, the correct support package is nearly seamlessly installed.  So this shouldn't be a task of chasing down the correct version of the support package, it's a matter of having MathWorks tools at least of version R2023a and having them install the package with the fixes.

There are some additional conditionals of using above 7gsps (IMR mode) for the DACs.  More details can be found in AMD's PG269 document.  This link at least worked when I posted it:  https://docs.amd.com/r/en-US/pg269-rf-data-converter.  See the sections for IMR mode.

If you are abiding by AMD's restrictions and it is still not working for you, please provide some more details of the issues you are seeing.

Kind regards