Trying to port the solution to Zedboard + FMCOMMS2

[quicktel]

Hello,

I'm trying to port the solution to Zedboard + FMCOMMS2. After many trial, I'm still failing to do so... What would be the best way forward following you ? I tried using the ANTSDR project but it is based on CMOS and after converting to LVDS I ran into a lot of timing issues. I also tried the Pluto project but no luck either.

Would you recommend the start from ZCU102 project ? Any way forward to adapt timing requirement ?

Regards,

[ofontbach]

Hi @quicktel,

Actually, you can find the base ADI firmware for the zedboard + FMCOMMS2 here. Thus, my recommendation is to modify it to add our logic on top of it. This can be fairly easily done by creating new scripts that will be a mix of those originally provided by ADI and our TCL scripts. As you say, I'd probably recommend to use our scripts to build the ZCU102 project. When doing so, make sure to pay attention to the fact that the zedboard has a 7000-family zynq device, so you'll need to make sure to instantiate the right RAMB elements - that is, add

CONFIG.PARAM_MEM_TYPE {ramb36e1}

when instantiating the DAC timestamp enabler block in the corresponding line of the TCL script that you're modifying.

Let us know how it goes and you're welcome to ask more specific questions if you find problems during the porting.

Regards,

[vagrant313]

Hi, Thanks for the details, one major difference to antsdr is its xdc file timing is relaxed due to cmos so, its period is 16.25 and the zedboard project xdc has period 4.

antsdr
create_clock -name rx_clk -period 16.27 [get_ports rx_clk_in]

zedboard
create_clock -name rx_clk -period 4 [get_ports rx_clk_in_p]

I have followed the steps you have described above!

1. base ADI firmware for the zedboard + FMCOMMS2 here
2. use the tcl scrip and generate the full vivado project, and tested theere is no timing error.
3. add srs ip folder in the project
4. manually added all the SRS IPs in the ip repo only

and Still I am getting timing errors.

I am attaching the bd here for your review, and it would be great if you let me know if there is something wrong, or should be connected differently, Thanks

https://drive.google.com/file/d/1Fwtk7kGHUN9jEAWH2DBxRp3_zwj0H6Kr/view?usp=share_link

Overall, if this project gets through it can be added to this repo for more audience as well.

Thanks,

[ofontbach]

Hi @vagrant313,

The 4 ns constraint comes from ADI's firmware and is related to some calibration procedures that the RF IC does at the start. Furthermore, I'm assuming that in the zedboard, like in the zcu102 case, the clock that arrives to the FPGA from the RF IC is 2x the sampling rate (for 1 antenna configuration) - you'll need to confirm this by looking at the device tree and/or the AD9361 IP configuration. Although this constraint could be relaxed (e.g., 4 ns allows for 4x the maximum sampling rate needed for LTE, which would be 20 MHz BW for a 2 antenna configuration), in principle it should not be required (but you could always try it as a last resort).

From the PDF you lined is certainly a little difficult to assess the correctness of your design - not only because the figure (and text) is quite small (e.g., is quite hard to validate all clock connections), but it's also impossible to verify the configuration of your IPs. In theory, if you just reused our TCL then all should be good.

A few tips that might help:

• I see that the zcu102 project does use the default values for the DAC timestamp enabler block. Try reducing the amount of memory used, by adding the following to its instantiation in the TCL (I'm assuming that with the Zed you won't go over 1.4 MHz BW, so probably 4x 2000 sample packets would suffice) - this should result in a lower RAMB utilization (and related control logic):

CONFIG.PARAM_BUFFER_LENGTH {4} \
CONFIG.PARAM_MAX_DMA_PACKET_LENGTH {2000} 

• Take a look at the timing results of the implementation and see which paths/signals are the troublesome ones. Adding some additional constraints to those might help. Also, make sure that all clocks are connected as they are supposed to be (e.g., generate the zcu102 project and verify your block design against it).
• Play with the synthesis and implementation configurations. You'd be surprised how much they affect the results (e.g., add retiming, change the goals of the algorithms to timing, etc.).
• The HDL firmware version I linked above is the latest one, but for the zcu102 we are pointing to the 2019.2 branch. Try using the 2019.2 version of the HDL firmware too.

Regards,