UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
4,224 Views
Registered: ‎04-02-2019

ZCU111 RFDC API Example Design

Jump to solution

Hi,

I have been trying to execute the 'xrfdc_read_write_example' within the rfdc_v5_0 API for the ZCU111 evaluation board. I am having issues with the 'XRFdc_In16' function defined within the file 'xrfdc_hw.h'. Whenever this function is called, the program execution halts. Diving a bit deeper, it hangs on the 'atomic_load' function called within. 

 

Some implementation notes that may be of use:

ZCU111 with NON-MTSDesign_8x8 Xilinx example design

Vivado 2018.3

Baremetal design (Standalone BSP and FreeRTOS BSP tested)

 

If anyone has insight on this problem it would be greatly appreciated.

 

Thanks,

Stephen

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
690 Views
Registered: ‎04-02-2019

回复: ZCU111 RFDC API Example Design

Jump to solution

I believe I have found a workaround for this issue.

The workaround is to build the BSP first as a seperate entity from the HW platform, then create the application project. I'm not sure why the SDK application project generated BSP doesn't work as I have not had any issues in the past. For some reason this wasn't necessary for the pre-built hardware files either. 

I would like to note as well for anyone working with this design that it seems that the definitions of '__baremetal__' and 'XPS_BOARD_ZCU111' were not being recognized in lower level files such as the clocking header and .c file. They must be manually added within each instance or defined within the compiler flags manually.

Regards,

Stephen

6 Replies
Community Manager
Community Manager
4,106 Views
Registered: ‎08-30-2011

回复: ZCU111 RFDC API Example Design

Jump to solution

Hi Stephen,

I will have a try at my side and get back to you later. thanks,

 

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
Community Manager
Community Manager
4,090 Views
Registered: ‎08-30-2011

回复: ZCU111 RFDC API Example Design

Jump to solution

Hi

I used the existing HDF in pre-build folder built the SDK project to take a quick test. It seems no problem at my side to run "xrfdc_read_write_example"...

Is it possible for you to try the existing HDF as what I did so we could align from here?

image.pngSnipaste_2019-04-15_18-20-58.png

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
4,075 Views
Registered: ‎04-02-2019

回复: ZCU111 RFDC API Example Design

Jump to solution

Hi,

Thank you for the reply.

I have built the SDK project from the precompiled HDF, and it runs properly.

I confirmed that the SW setup is identical to the Vivado compiled project, so I suspect that there may be a disconnect between the Vivado compiled HW and the example SW. I have attached a text file with the UART readout from the pre-compiled SDK.

For reference, the Vivado HW compiles successfully. It was sourced from the tcl scripts within the 'scripts' folder in the NON-MTS_8x8 design. I will try to see if I can locate the source of the problem within the Vivado design. I have not made any modifications, and was under the impression that the precompiled HDF and the generated hardware files should be identical.

It may be helpful if you have any details of the changelog to see if there are any changes in the Vivado project after the pre-compiled HDF.

Thank you again,

Stephen  

Community Manager
Community Manager
3,924 Views
Registered: ‎08-30-2011

回复: ZCU111 RFDC API Example Design

Jump to solution

Hi Stephen,

Thanks for the update.

Good to hear that you can properly run the code with pre-compiled HDF.

It seems that there is something different between Pre-compiled HDF and Vivado complied HDF which is supposed to be the same.

I will try to figure out at the same time with you and update here later. Thanks,

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
764 Views
Registered: ‎04-02-2019

回复: ZCU111 RFDC API Example Design

Jump to solution

Hi,

I wanted to give a second update for further clarification.

I extracted the block diagram from the precompiled HDF file, and compiled within Vivado. I am experiencing the same issue as initially posted. 

However I am not sure if there is still a disconnect between the precompiled delivered .bit file, .hwh files, etc. and the block diagram which could explain this behavior. 

If those files and the block diagram build scripts are identical platform builds, I suspect that the issue may be Vivado related rather than design related. 

Regards,

Stephen

0 Kudos
Highlighted
691 Views
Registered: ‎04-02-2019

回复: ZCU111 RFDC API Example Design

Jump to solution

I believe I have found a workaround for this issue.

The workaround is to build the BSP first as a seperate entity from the HW platform, then create the application project. I'm not sure why the SDK application project generated BSP doesn't work as I have not had any issues in the past. For some reason this wasn't necessary for the pre-built hardware files either. 

I would like to note as well for anyone working with this design that it seems that the definitions of '__baremetal__' and 'XPS_BOARD_ZCU111' were not being recognized in lower level files such as the clocking header and .c file. They must be manually added within each instance or defined within the compiler flags manually.

Regards,

Stephen