External 10 MHz Reference Clock for ZCU208 via Simulink HDL IP Core Generation

You could try the RFSoC Explorer API command below, which allows you to program the Texas Instruments LMK04828 onboard the CLK104.

>> Avnet_RFSoC_Explorer('help','CLK104')

[error_flag, data, msg] = Avnet_RFSoC_Explorer('Program_CLK104_LMK', <option>)

  Programs the Xilinx CLK104 LMK04828 PLL with the configuration specified

  by <option>. All predefined <option> set ADC and DAC RefClk = 245.76 MHz.

  Valid <option>:

    'Xilinx Default'

    '122.88MHz REFCLKOUT, 10MHz TCXO REF'

    '122.88MHz REFCLKOUT, 10MHz EXT REF' 

    'custom_TCS.txt'

  A custom LMK04828 configuration file can be created using Texas Instruments

  TICSPRO utility, saved as TEXT format with filename custom_TCS.txt, and

  located in the same directory as the RFSOC Explorer app.

Thanks for the info on the method to select the external 10 MHz reference clock using the RFSoC Explorer API commands. In my application, I would like to make the external 10 MHz as the reference clock to the CLK104 board after loading my own bit file from the Simulink HDL Coder IP Core design flow using ZCU208 board. I tried your suggestion of using the API command after loading my bit file, I could not get it to work correctly. Does the RFSoC Explorer API command work on my own design image/bit file?

In one Xilinx posting, I read about the usage of the RFSoC APU to program the CLK104 module through the I2C/SPI interface. With the Simulink HDL Coder IP design flow using the Avnet RFSoC Explorer board support package, how do I insert the C-code for the APU commands? What is the best way to change the reference clock source (CLK104 SPI command) through the Simulink design flow?

dchien said:

I tried your suggestion of using the API command after loading my bit file, I could not get it to work correctly.

Can you post the MATLAB error you are seeing when you try the API command?

dchien said:

Does the RFSoC Explorer API command work on my own design image/bit file?

The APIs were not made to work in the HDL Coder workflow, but conceptually it should work if you are using the Avnet ZCU208 HDL Coder support package for Simulink (info here). It may not work with every custom bitstream you create in HDL Coder, but I tested with the default bitstream (located here) and the API successfully programmed CLK104.

Open a serial terminal to the zcu208 and check that an application called "rftool" is running:

   zynqrf> top | grep rftool

Let me know what you find.

/Matt

Matt, thanks for your step-by-step help. I have the rftool confirmed in the terminal as shown below.

zynqrf> top | grep rftool
  918     1 root     S    78572  1.9   3  0.0 /usr/bin/rftool
 1952  1898 root     S     1888  0.0   3  0.0 grep rftool

Please help me with the detail steps to switch the 10 MHz clock source.Thanks.

AMD Xilinx authored rftool. You can inquire on their forum.

mbrown said:

Can you post the MATLAB error you are seeing when you try the API command?

I can successfully run my DUT_setup_rfsoc.m script by itself or run the Avnet_RFSoC_Explorer API commands independently to configure the clock with custom_TCS.txt. However, I cannot run them one after another.

Here are my errors when I run the DUT_setup_rfsoc.m script first and followed by the API commands. The error message below “...” are removed RFTool commands not shown here because it is a long list. After the DUT_setup_rfsoc.m is complete, it releases the rfobj object. I don’t understand why the target cannot be connected.

Connected to RFTool
…
SetFabClkOutDiv
SetupFIFO 1 0 1
SetupFIFO
Disconnected from RFTool
>> release(rfobj)
>> Avnet_RFSoC_Explorer('startup');
Target board [3] ZCU208
Opening Avnet RFSoC Explorer...
Failed to connect to target at 169.254.184.100
>> [STATUS, DATA] = Avnet_RFSoC_Explorer('ipconfig', '169.254.184.100');
Failed to connect to target at 169.254.184.100
Warning: No TCP Connection

However, when I run the API commands firsts then the DUT_setup_rfsoc.m next, I have the following errors.

Error using comm.internal.xczuxdr.TcpipClass.TCPIP_Base/setupImpl
Cannot create a communication link with the remote server. Please check the input arguments(ADDRESS and PORT) and make sure the server is running.
Additional Information: No connection could be made because the target machine actively refused it
See related documentation for troubleshooting steps.

By the way, my terminal connects with the IP address and still works after these errors. When I get the connection or TCP errors, I must reboot my Xilinx board to restart the process. Do you know what is wrong? My goal is to issue RFSoC_Explorer API commands to configure the clock using custom_TCS.txt configuration file then use the DUT_setup_rfsoc.m file afterward to configure my down-conversion and up-conversion frequencies with decimation and interpolation parameters. Thanks.

I believe we fixed this issue with rftool, which is included in a newly released version (v1.0.3) of the 'hdlcoder-zcu208' SD image.

Download here: https://github.com/AvnetDev/hdlcoder-zcu208-zip/releases/tag/v1.03

Let me know if this allows you to connect-disconnect-reconnect

The V1.03 update worked and resolved the failure to connect problem. I can program the clock frequency to 250 MHz using the external 10 MHz clock. Thanks.

I have another question. By default, the HDL Workflow Advisor uses 245.76 MHz as the reference clock. I intend to program the clock at 250 MHz. Through the FPGA synthesis and place & route process, the design meets 245.76 MHz derived clock, not 250 MHz derived clock. Is there a way change the clock value in the design flow so that the FPGA meets the timing properly? Thanks.

Hi dchien,

I am sorry to tell you officially I cannot recommend you do any of this.  Some of the clocking restrictions are due to limitation of the RFSoC and some of them are from how the HDL Coder for RFSoC architects the PL design.

Regarding changing the external clock 104 frequencies, unfortunately workflow advisor does not allow one to input what the external clock frequency actually is.  The timing constraints would therefore not be accurate.  It may work within a certain tolerance and temperatures but it may also crash in strange ways.

Regarding the 245.76 MHz reference clock, this is selected by HDL Coder for you.  The only way to change the frequency that the DUT runs at is to change the Fs and the data vector width for the converters.  The ADC and DAC can have different sample rates but ultimately the PL data sample clock has to match for ADC and DAC; there is only 1 clock for both RX (ADC) and TX (DAC) data samples.  The data vector width is the only thing that can be changed to make those match.  So in the end the Fs for DAC and ADC have to match by a few integer factors.  IMR mode throws in a few more wrinkles and this is mainly from the RFSoC part itself and the way it works.

Unofficially though, what you could do is have HDL Coder generate the hardware design with the parameters it allows you to change.  It leaves behind a complete Vivado project.  You can always open this project and change it.  This can get very tricky though.  For example if you change some of the default data converter settings, Workflow Advisor won't know about them and it generates a script that is executed upon bootup that RFTool executes.  In theory though, if you know what you are doing and keep all that in sync you may be able to do what you want.

Kind regards

Hi dchien,

I am sorry to tell you officially I cannot recommend you do any of this.  Some of the clocking restrictions are due to limitation of the RFSoC and some of them are from how the HDL Coder for RFSoC architects the PL design.

Regarding changing the external clock 104 frequencies, unfortunately workflow advisor does not allow one to input what the external clock frequency actually is.  The timing constraints would therefore not be accurate.  It may work within a certain tolerance and temperatures but it may also crash in strange ways.

Regarding the 245.76 MHz reference clock, this is selected by HDL Coder for you.  The only way to change the frequency that the DUT runs at is to change the Fs and the data vector width for the converters.  The ADC and DAC can have different sample rates but ultimately the PL data sample clock has to match for ADC and DAC; there is only 1 clock for both RX (ADC) and TX (DAC) data samples.  The data vector width is the only thing that can be changed to make those match.  So in the end the Fs for DAC and ADC have to match by a few integer factors.  IMR mode throws in a few more wrinkles and this is mainly from the RFSoC part itself and the way it works.

Unofficially though, what you could do is have HDL Coder generate the hardware design with the parameters it allows you to change.  It leaves behind a complete Vivado project.  You can always open this project and change it.  This can get very tricky though.  For example if you change some of the default data converter settings, Workflow Advisor won't know about them and it generates a script that is executed upon bootup that RFTool executes.  In theory though, if you know what you are doing and keep all that in sync you may be able to do what you want.

Kind regards