05-01-2020 12:14 PM
I used a ZC706 board as a CPRI master, and it worked well. No I have ported the code to an Ultrascale+. I have a few errors on the HDLC link, so I have looked at the hdlc_tx_enable and hdlc_rx_data_valid signals on the scope. During 10 milliseconds they behave as expected (depending on the HDLC rate), then during 10 milliseconds they are constant zero, then again they behave as expected, ...
Thank you for your help
05-19-2020 11:11 PM
Please try to run CPRI hardware demo design.
05-27-2020 04:00 AM
06-18-2020 05:55 AM
Sorry for my late answer. I would prefer not to start from the demonstration design, because on the other side of the CPRI link my design is working well, and the demonstration design is quite different from mine.
I have 2 boards linked by CPRI. The clocks synchronize well. The "Status Code and Alarm Register (0x0)" reads alternatively 0x0F and 0x11 on both sides, if I try to read every 10 ms (my reading is not perfectly synchronized). As written above, on the scope it seems that everything is good for 10 ms, then the link is down for 10 ms, alternatively. I can exchange HDLC data, when I am lucky.
06-18-2020 06:36 AM
I have output some debug signals. On the attached scope image,
So arround the end of a 10 ms chunk, I see local_lof, local_rai and stat_alarm high.
06-18-2020 07:53 AM - edited 06-18-2020 07:56 AM
I have changed my debug signals. Channels 0 to 7 are from the CPRI slave, 8 to 15 are from the master.
and similarly from 8 to 15 for the master. So the local_lof and local_rai appears first on the slave side. Nevertheless it seems that the link works well for 10 ms. And my slave board works well with another master.
08-06-2020 06:49 AM
I use CPRI (8.10) and Vivado 2019.1.
(note that with Vivado 2018.1 and CPRI 8.9 I have a design working well on the ZC706.)
I observe also that the master changes the nodebfn_tx_nr, then 66.666 µs later (one hyperframe) the slave signals "local_lof", " local_rai" and so on. The link is down for 10 ms.
08-06-2020 07:18 AM
08-07-2020 01:53 AM
The issue in 2018.1 is due to a shift in the rx strobe, which was driven to nodebfn_tx_strobe. It brings resync every 10ms.
How do you generate nodebfn_tx_strobe in your design? can you capture nodebfn_tx_nr, nodebfn_tx_stobe and iq_tx_enable signals?
08-07-2020 02:36 AM
08-07-2020 02:58 AM
As for the fact there is a known issue related to nodebfn_rx_strobe for slave core, can you upgrade your slave side to 2018.3 and later version? And then see if the issue is fixed or not.