cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
670 Views
Registered: ‎02-09-2010

CPRI. HDLC link changes every 10 milliseconds

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
xczu29dr-ffvf1760-2-e

Tags (3)
0 Kudos
14 Replies
Highlighted
Moderator
Moderator
563 Views
Registered: ‎01-10-2019

Hi tcachat@metraware.com,

Please try to run CPRI hardware demo design.

Thanks,
Rahul Khatri
---------------------------------------------------------------------------------
Please Kudo or Accept as a solution, If this Post helped you.
---------------------------------------------------------------------------------
0 Kudos
Xilinx Employee
Xilinx Employee
517 Views
Registered: ‎08-02-2007

FYI tcachat@metraware.com 

In CPRI Lounge : KCU105, VCU108 and ZCU102 boards are supported by CPRI demonstration designs. In older releases the KC705, ZC706, VC709, AC701, KCU105, VCU108 and ZCU102 boards are supported. 

0 Kudos
Highlighted
462 Views
Registered: ‎02-09-2010

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.

0 Kudos
Highlighted
455 Views
Registered: ‎02-09-2010

I have output some debug signals. On the attached scope image,

  • 8= local_los,
  • 9= local_lof,
  • 10= local_rai,
  • 11=remote_los,
  • 12=remote_lof,
  • 13= remote_rai,
  • 14= stat_alarm,

So arround the end of a 10 ms chunk, I see local_lof, local_rai and stat_alarm high.

TEK00041.PNG
0 Kudos
Highlighted
447 Views
Registered: ‎02-09-2010

I have changed my debug signals. Channels 0 to 7 are from the CPRI slave, 8 to 15 are from the master.

  • 0= local_los,
  • 1= local_lof,
  • 2= local_rai,
  • 3= stat_alarm,
  • 4= stat_code(0)
  • 5= stat_code(1)
  • 6= stat_code(2)
  • 7= stat_code(3)

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.

TEK00042.PNG
0 Kudos
Highlighted
325 Views
Registered: ‎02-09-2010

I have just tested further. I can even exchange IQ data, but only for 10 ms working, 10 ms off, and so on.

Can anyone help?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
316 Views
Registered: ‎08-02-2007

tcachat@metraware.com 

Which version are you using? If you try latest version CPRI, do you see this issue?

0 Kudos
Highlighted
303 Views
Registered: ‎02-09-2010

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.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
298 Views
Registered: ‎08-02-2007

@rkhatri 

The IP behavior changes between 2019.1 and 2018.1, due to a known issue : https://www.xilinx.com/support/answers/71369.html

0 Kudos
Highlighted
291 Views
Registered: ‎02-09-2010

Sorry. To be complete, my slave is designed with Vivado 2017.4, CPRI 8.8. Is it incompatible?
The known issue you mentioned concerns CPRI 8.9 in Vivado 2018.1, but with that version I have apparently no problem.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
190 Views
Registered: ‎08-02-2007

tcachat@metraware.com 

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?

0 Kudos
Highlighted
182 Views
Registered: ‎02-09-2010

Thank you xud. On the slave side I have a simple
nodebfn_tx_strobe_s <= nodebfn_rx_strobe_s;
nodebfn_tx_nr_s <= nodebfn_rx_nr_s;
And I was happy with that until now.
Is it better to generate the nodebfn_tx_* independently ? (with a counter, similarly to the master)
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
175 Views
Registered: ‎08-02-2007

tcachat@metraware.com 

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.

0 Kudos
Highlighted
140 Views
Registered: ‎02-09-2010

I started yesterday to upgrade my slave design to 2019.1. It takes hours... Now it is done, but the result is not better.
0 Kudos