This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6670 AIF2 connects Xilinx FPGA using CPRI protocol

Expert 2985 points

Hi all,

**************************************************************************************************************************

Now we are trying to transfer IQ data between C6670 and Xilinx FPGA(V6) using CPRI protocol, but we meet some problems. Hope anyone can help us!

1. The pic below shows our situation

In this situation, if the FPGA's CPRI IPcore is configured with master port, does the CPRI link between C6670 and FPGA run OK?

If not, why?

2. If the situation is below,

can the CPRI link run OK?

3. If the both ends of the CPRI link do not run at the common clock and either of them can not use the clock recovered from RX link as its TX clock(like the FPGA CPRI master configuration), can the CPRI link run OK? 

If not, why? From CPRI spec? Or the CPRI protocol does not contain the idle symbol to be used to adjust the clock difference between both ends?

4. Can the C6670's AIF2 use the clock recovered from RX link as its TX clock?

**************************************************************************************************************************

Regards,

Feng 

  • Hi,

    clock synchronization between two boards is the key issue in your case and it can be achieved by

    1. using common clock source (122.88MHz) between board A and B

    2. or designing clock recovery feature from FPGA Rx link and re-use it for Tx link (this is what most CPRI users do)

    AIF2 Rx module doesn't support clock recovery, so you cannot make your second scenario work right with AIF2 to AIF2 connection without common clock.

    Regards,

    Albert

  • Hi Albert, As you mentioned

    "2. or designing clock recovery feature from FPGA Rx link and re-use it for Tx link (this is what most CPRI users do)"

    Could you show me more details why the CPRI needs this? Or why my first scenario will not work well when the FPGA is under master configuration.

     

    Regards,

    Feng

  • Hi Feng,

    CPRI spec chapter 3.5.1 explains how frequency sync can be achieved. you can also see more detail from 3GPP TS 25.104 or 36.104 spec. basically, we normally assume the RE works as a slave and REC as a master of clock sync and we haven't thought about opposite case. That's why we didn't design clock recovery feature for our SoC.

    Hope this could help to you.

    Regards,

    Albert

  • Hi Albert,

    I had seen that about CPRI spec.

    For one AIF2 link there is one TX lane and one RX lane. So far, I think

    (1) If the two part of the CPRI link do not have a common clock, either of the two must be the master using its local clock for TX and the other must be slave using its RX recovered clock for TX

    (2) If the two part of the CPRI link have a common clock, they can use their independent local clocks for their own TX.

    Am I right?

    In some other protocol, like SRIO, I can not see the common refclk design is necessary. But in the PCIe design, I mostly see that the two ends of PCIe using a common refclk.

    What's the difference?Why sometimes using common refclk but others not?

    For CPRI protocol, is it because that the CPRI protocol does not have idle symbols for adjusting the difference of clocks of the two ens of CPRI link?

    You give me advice for see more details form 3GPP spec.

    However I want to know if we do not use the CPRI link to transfer such data like LTE but just other not time-sensitive data between FPGA and C6670, does the CPRI link can work OK when the FPGA has its own local clock and is under master configuration like the first scenario what I describe above.

    In other words, the CPRI link needs one of its two ends retrieves clock from RX lane and re-uses this clock for its TX(when no common clock) but SRIO and SGMII do not have this constraint, is this because that the CPRI does not have idle symbol but SRIO and SGMII have or the 3GPP spec requires the CPRI need this but SRIO and SGMII do not comply with 3GPP?

    Regards,

    Feng

  • Feng,

    AIF2 has streaming based operation with exact radio timing heartbeat while SRIO is packet based and sync between devices is not much critical than IQ streaming interface. exceptionally, PCIe requires common clock source even though it is packet based interface for its special HW design concept.

    using different clock source in AIF2 makes critical clock drift and it will ruin all radio timing between RE and REC. for base station design, base station is a timing master and "Radio Head" is timing slave and that is why most radio head Rx module supports clock recovery based on the incoming frame from base station. if the FPGA is part of radio head, it should have clock recovery feature. if the FPGA is a part of base station, you need to use common clock source for both DSPs and FPGA.   

    (2) If the two part of the CPRI link have a common clock, they can use their independent local clocks for their own TX [TI] you misunderstood one thing. common clock means the two parts has only one united crystal and circuit for the clock generation and there's no need for having independent local clocks for their own TX.

    Regards,

    Albert

  • Sorry for that my question labeled by (2) is wrong because of my carelessness. And thank you to correct my fault.

    The last several questions, from what I understand, the AIF2

    (1) use its local clock for TX

    (2) ues the recovered clock from RX data to latch the RX data

    (3) AIF2 can not use the recovered clock from RX data for TX like the FPGA CPRI slave does what showing in the pic below

    Am I right?

    And can you give me some tips about how the idle symbols in SRIO protocol what CPRI does not have make all the time synchronization things different between SRIO and CPRI?

    Or the idle symbol make no sense with the time synchronization?

  • I'll give you a simple note to remove confusion

    1. AIF2 does NOT have clock recovery feature. it only use reference clock from the board for both Tx and Rx

    2. SRIO and CPRI has totally different spec and concept, so you cannot compare those two directly.

    Regards,

    Albert

     

  • Hi albert,

    As you mentioned,

    "1. AIF2 does NOT have clock recovery feature. it only use reference clock from the board for both Tx and Rx"

    But in the AIF2 doc SPRUGV7D, I see this

    "The Rx Mac converts a two byte wide parallel stream in the 2x_byte clock domain of the received signal that is clocked directly from the SerDes module."

    For the RX FIFO,

    "The FIFO is written using the receive 2x_byte clock from the associated SerDes macro receiver and is read using the system clock (307.2 MHz or 245.76MHz)."

    I think there are two time domain here in RX FIFO, one is the system clock from the SYSCLK pin of DSP then feeds the PLL in AIF2 module showing in the pic below,

    and the other is the 2x_byte clock.

    Is not the 2x_byte clock recovered from the RX data stream? But what is it?

    And according to the pic below

    there is a mon_warp reg for monitoring the clock quality of the 2x_byte clock.

    I always think the 2x_byte clock is the clock recovered from RX data using CDR until I see what you mentioned above.

    Regards,

    Feng

  • I think you are confused.

    Rx MAC has two clock domains as you mentioned and it is changed when the data is in FIFO. However, both clocks are generated by the common clock source from the board not from the incoming CPRI frame.

    sys_clk is generated by Tx SERDES and it is used for both egress and ingress AIF2 operation as a byte level clock.

    2x_byte clock used in Rx SERDES also delivered from SERDES PLL (not recovered from Rx data)

    the PLL diagram you described above is the SoC main PLL and it is used to generate VBUS level clock and not used for sys_clk generation. SERDES has its own PLL inside and it multiplies SYSCLK and the final output clock is used for both Tx, Rx SERDES and even for sys_clk (it is delivered to AIF2 core by Tx SERDES)

    Clock quality circuit is designed just in case when the source of SERDES clock is different to AIF2 sys_clk but it is not applied to the current Keystone II SoC design. (you can ignore the feature for now)

    Hope this help to you.

    Regards,

    Albert 

     

  • Hi Albert,

    In the pic above, the clock path emphasized by red lines feeds the SerDes PLL in AIF2 module and generates the rx_bclk, TX clock and sys_clk showing in the pic below

    And the clock path emphasized in blue lines showing in the two pics below is for VBUS clock generation

    Am I right?

    *******************************************************************************************************************

    So the precondition that AIF2 does not contain CDR is why the other end of AIF2 link must reuse its recovered clock for TX.

    And why AIF2 does not contain CDR is just because DSP is always an REC as master port and the CPRI spec demands the slave port must  reuse its recovered clock for TX. That's why the AIF2 is not necessary to contain a CDR circuit.

    Is what I say above OK?

    *******************************************************************************************************************

    Regards,

    Feng

  • Correct. now we are in the same page. !

    Albert

  • Thanks for your help, Albert!

    Regards,

    Feng