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

CPRI. HDLC link changes every 10 milliseconds

Jump to solution

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
1 Solution

Accepted Solutions
xud
Xilinx Employee
Xilinx Employee
558 Views
Registered: ‎08-02-2007

tcachat@metraware.com 

Sorry - I missed your last reply.

I just measured your iq_tx_enable, the timing doesn't look correct to me. As you can see in the screenshot, the intervals between two adjacent iq_tx_enable is 36 cycles.

If your CPRI clock frequency is 153.6 MHz, then it's 234.375 ns.

xud_0-1600761356743.png

For CPRI, if you don't want it to be resync every 10ms, you need to ensure it's 260ns, around 40 cycles for 153.6Mhz

xud_1-1600761592888.png

 

View solution in original post

0 Kudos
25 Replies
rkhatri
Moderator
Moderator
1,562 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
xud
Xilinx Employee
Xilinx Employee
1,516 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
1,461 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
1,454 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
1,446 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
1,324 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
xud
Xilinx Employee
Xilinx Employee
1,315 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
1,302 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
xud
Xilinx Employee
Xilinx Employee
1,297 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
1,290 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
xud
Xilinx Employee
Xilinx Employee
1,189 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
1,181 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
xud
Xilinx Employee
Xilinx Employee
1,174 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
1,139 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
xud
Xilinx Employee
Xilinx Employee
957 Views
Registered: ‎08-02-2007

tcachat@metraware.com 

Can you capture iq_tx_enable, nodebfn_tx_*, nodebfn_rx_*, stat_code, basic_frame_first_word in the same ILA please? 

0 Kudos
890 Views
Registered: ‎02-09-2010

Dear @xud 

I was away for a few days. Here are the capture on the slave side.

The capture clock is the CPRI clock at 153.6 MHz. The trigger is at the lost of the link.

ILA_CPRI_slave.png

ILA_CPRI_slave_zoom.png

Thank you

Edit: It is strange that both nodebfn_*_nr gets to zero. I can observe that several times, with different previous values.

ILA_CPRI_slave_2.png

 

 

0 Kudos
879 Views
Registered: ‎02-09-2010

On the Master side, the nodebfn_tx seems correct

ILA_CPRI_maste.png

0 Kudos
848 Views
Registered: ‎02-09-2010

Following the above ILA pictures, I concentrated on the nodebfn_tx_*. Until now my iq_tx_gen.vhd was essentially the one of the IP Example Design, except for the IQ data, and it worked well with the ZC706. Yet on the master side I have tried to reset the bfn counter when the link is lost, and I get a different result (still unsatisfactory). In the below scope image, I have changed the signals on the master side:

  • 8= local_los,
  • 9= local_lof,
  • 10= local_rai,
  • 11= nodebfn_tx_nr_m(0),
  • 4= stat_code(0)
  • 5= stat_code(1)
  • 6= stat_code(2)
  • 7= stat_code(3)

Signals on the slave side (0-7) are the same as above.

TEK00044.PNG

I do not have periodically 10 ms up 10 ms down any more. One can observe that the slave loses the link (either for a short or a long time) just after the nodebfn_tx_nr_m changes. The master also loses the link for a short time. The picture can be different, with the master losing the link for a long time about 4 ms after the trig.

The link can stay down for more than 400 ms.

0 Kudos
xud
Xilinx Employee
Xilinx Employee
775 Views
Registered: ‎08-02-2007

tcachat@metraware.com 

The image doesn't look clear, when ILA is open, can you go to menu bar, click File -> Export ILA data, and then upload ila file. 

0 Kudos
xud
Xilinx Employee
Xilinx Employee
772 Views
Registered: ‎08-02-2007

tcachat@metraware.com 

From your last reply, 11 doesn't look correct to me, if it's nodebfn_tx_nr, it should be a number, not single bit logic, and it should last for 10ms. From the image, the falling edge comes earlier than 10ms, which causes stat_code loses sync.

0 Kudos
751 Views
Registered: ‎02-09-2010

Dear @xud 

Please find attached the exported ILA records, with two examples for the slave side, and two for the master side. I came back the the 2020-08-26 version of the code (same as the ILA screenshot above).

On the (physical) scope, I am limited to 16 logic signals, so I chose only the LSB of nodebfn_tx_nr_m, which changes every 10 ms.

PS: <<The attachment's cpri_slave.ila content type (application/octet-stream) does not match its file extension and has been removed.>> I hope a ZIP file is allowed...

0 Kudos
xud
Xilinx Employee
Xilinx Employee
684 Views
Registered: ‎08-02-2007

tcachat@metraware.com 

I notice there is problem with tx_nodebfn_strobe/nodebfn_rx_strobe_s in slave ILA. What's your ILA clock freq? I need to check if there is an issue with basic_frame_first_word, or the issue is to do generated iq_tx_enable.

 

xud_0-1599231155340.png

The tx_strobe timing looks good in master ILA, but the nodebfn_rx_nr looks strange. I think we need to fix the timing in slave tx_nodebfn_strobe firstly.

If you want to use nodebfn_rx_strobe_s to drive  nodebfn_tx_strobe_s, and iq_rx driven to iq_tx.

Please note there is one cycle difference between basic_frame_first_word/iq_rx and iq_tx_enable/iq_rx.

Can you try to use independent  tx_nodebfn_strobe on slave, and see if you can get expected iq_tx_enable? Please try this test on v2019.1.

0 Kudos
673 Views
Registered: ‎02-09-2010

Dear @xud,
my ILA clock frequency is 153.6 MHz, it is the CPRI clock, the "clk_out" from the slave IP.

In the slave I used a simple
nodebfn_tx_strobe_s <= nodebfn_rx_strobe_s;
nodebfn_tx_nr_s <= nodebfn_rx_nr_s;

Now I have tried to generate the nodebfn_tx_* independently. I still have the 10 ms toggle. Attached are tree ILA data on the slave side. The duration of the strobe seems better. Trying a few times, nodebfn_rx_nr_s goes to zero shortly after nodebfn_rx_strobe_s is active, and then the link is lost.

I am using v2019.1

Thanks

0 Kudos
xud
Xilinx Employee
Xilinx Employee
559 Views
Registered: ‎08-02-2007

tcachat@metraware.com 

Sorry - I missed your last reply.

I just measured your iq_tx_enable, the timing doesn't look correct to me. As you can see in the screenshot, the intervals between two adjacent iq_tx_enable is 36 cycles.

If your CPRI clock frequency is 153.6 MHz, then it's 234.375 ns.

xud_0-1600761356743.png

For CPRI, if you don't want it to be resync every 10ms, you need to ensure it's 260ns, around 40 cycles for 153.6Mhz

xud_1-1600761592888.png

 

View solution in original post

0 Kudos
547 Views
Registered: ‎02-09-2010

Thanks a lot @xud 

You are right, the problem is here. To be more precise, the previous iq_tx_enable are regularly spaced by 40 cycles, but the nodebfn_tx_strobe_m goes high to early, which probably breaks everything. My generation of nodebfn_tx_strobe_m was wrong (was done in advance). Strangely the same code worked well on the ZC706.

0 Kudos