• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 101 subscribers
  • Views 1143 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AIF2 usage for data transfer between TMS320C6670 and Xilinx FPGA

ANUJ AGARWAL
Intellectual 400 points

Hi I wish to make a connection between 6670 DSP (with respect to each of 4 cores) and FPGA (supporting SERDES link and CPRI protocol).

The operartions to be implemented are read and write.

In my case, previously SRIO was used for this interface but now SRIO is to be used for inter DSP communication. Hence SRIO cannot be used.

I am left with option of using AIF2 peripheral, but unable to decide on which feature/mode I can use for my use case.

After going through the available literature and sample code on AIF2, I believe generic packet mode for CPRI is the most suitable option.

But, I wish to use it for 1.4MHz LTE Rate and see that there is a specific option available in AIF2. But, I am not sure if I can use LTE mode for inter device communication. Can anyone please suggest if LTE mode can be used in my scenario?

 

Also, please suggest on what basis can I select a core for transmission/reception of messages? (IN SRIO, I was able to distinguish the core number with the help of LSU registers)

 

Is there any sample/reference code available for the DSP-FPGA communication using LTE feature for AIF2?

 

Is there any sample/reference material (other than User guide and LLD) available for the same?

 

Also, please suggest what components of AIF2 are covered by loopback mode supported by AIF2? (For SRIO, we had Digital and SERDES loopback modes, but for AIF2, I read only internal loopback mode is available. So, wish to know how it maps to loopback modes available in SRIO?)

 

In anticipation of response for all/some of the above queries

Thanks

Regards

Anuj Agarwal

  • 0
    TI__Expert 4740 points

    Hi,

    If you are thinking about using Generic packet mode, that means you are trying to transfer various size of packet with flexible packing and the data is not IQ data.

    I was confused why you want to transfer LTE 1.4 MHz type of IQ data, even though you want to use Generic packet mode.

    Generic packet mode is very flexible and use the whole link BW flexibly for whatever the packet size is. packet is only differentiate by SOP and EOP signal which is created by delimiter. we have 4b5b encoding and NULL delimiter for that purpose.

    I attached an example of CPRI generic packet mode. LLD also has this. AIF2 LLD also has this code 

    5126.Aif2_Cpri_Generic_Packet_Test.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    /****************************************************************************\
    * Copyright (C) 2009 Texas Instruments Incorporated. *
    * All Rights Reserved *
    * *
    * GENERAL DISCLAIMER *
    * ------------------------------------------------------------------- *
    * All software and related documentation is provided "AS IS" and without *
    * warranty or support of any kind and Texas Instruments expressly disclaims*
    * all other warranties, express or implied, including, but not limited to, *
    * the implied warranties of merchantability and fitness for a particular *
    * purpose. Under no circumstances shall Texas Instruments be liable for *
    * any incidental, special or consequential damages that result from the *
    * use or inability to use the software or related documentation, even if *
    * Texas Instruments has been advised of the liability. *
    ****************************************************************************
    * *
    * Written by : *
    * Albert Bae *
    * Texas Instruments *
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     In case of AIF2, the loopback mode is supported by SERDES. AIF2 UG SERDES register map shows this loopback mode field. AIF2 core doesn't have its own digital internal loopback.

    Regards,

    Albert  

  • 0 in reply to Albert Bae
    Intellectual 400 points

    Hi

    Thanks a lot for your response. I got replies to all by above queries.

    Kindly answer the following queries as well:

    For DSP- FPGA interaction, I shall be using CPRI Generic mode with Packet DMA at 8x link rate for 1 link. 

    Through this link, I wish to READ and WRITE data on FPGA of varied length from DSP.

    Hence, DSP is Source and FPGA is destination for the READ and WRITE transactions.

     

    Though, I have been able to find how to  transfer various size of packet with flexible packing. But, now I wish to extend this send and receive of packets to READ and WRITE data from DSP on FPGA.

     

    Kindly suggest how I can do the same through AIF2.

     

    Regards

    Anuj Agarwal

  • 0 in reply to ANUJ AGARWAL
    TI__Expert 4740 points

    AIF2 interface supports WRITE process and that means you can send packet from DSP to FPGA.

    but it doesn't support READ process which menas DSP send request to FPGA and FPGA respond with packet.

    AIF2 can only send request packet to FPGA and FPGA master should control this request to send back requested data. It totally depends on your application in DSP and FPGA.

    Regards,

    Albert 

  • 0 in reply to Albert Bae
    Intellectual 400 points

    Hi Albert

    Thanks a lot for your quick response.

    Also, can you please elaborate on the following statement: (How can we achieve the same)

    AIF2 can only send request packet to FPGA and FPGA master should control this request to send back requested data. It totally depends on your application in DSP and FPGA.


    To support READ (in addition to WRITE) operation, one might distinguish the request packet using a particular data and data size in the packet. Is the method correct?

    Or is there any other way/configuration/parameter through which I can distinguish the request packet from a normal WRITE transaction packet?


    Thanks a lot for the support

    Regards

    Anuj

  • 0 in reply to ANUJ AGARWAL
    TI__Expert 4740 points

    To support READ (in addition to WRITE) operation, one might distinguish the request packet using a particular data and data size in the packet. Is the method correct?
     [Albert] yes, you need to have your own way to distinguish the packet. HW doesn't support that feature.

    Regards,

    Albert

     

  • 0 in reply to Albert Bae
    Intellectual 400 points

    Dear Albert

    Thanks a lot for your response and help.

    There is a change in my requirements. I now need to support continuous transfer (send and receive) of IQ data at 1.2 Mbps between corepac and FPGA (CPRI supported) through AIF2. 

    To elaborate further, I need to support the following:

    1) CPRI protocol on AIF2

    2) continuous data send and receive of IQ data at 1.2 Mbps

    3) Communication between DSP and FPGA through AIF2

    4) Each core preferably uses 1 AxC internally and all cores to use 1 physical link 

     

    Please let me know which mode would be best suited for the same.

    Thanks

     

    Regards

    Anuj Agarwal

  • 0 in reply to ANUJ AGARWAL
    TI__Expert 4740 points

    Hi,

    What you are trying to do now is the normal use case of AIF2 with CPRI protocol.

    you can get more information from AIF2 UG and also see AIF2 CSL and LLD in your latest PDK or MCSDK SW package. (it has example code inside)

    and you need to choose which Radio standard (WCDMA, LTE) you will use for the AIF2. you can find something that matched with 1.2 Mbps data rate.

    Regards,

    Albert 

  • 0 in reply to Albert Bae
    Intellectual 400 points

    Dear Mr Albert

    Thanks a lot for your guidance.

    I am confused over using AIF2 in LTE mode because of following and similar statements I read at different places from which it is inferred that for inter device communication, generic packet is the only mode supported:

    1) AIF2 UG: AIF2 marks the LTE symbol with the received AIF2 channel number and the LTE symbol index (count value starting at 0 on the radio frame boundary). The packet is then transferred to FFTc; The whole transfer of the LTE symbol from AIF2 to L2 and finally to FFTc is performed with no interrupts of real time action by any of the CorePac cores. (packet exchanges between AIF2 and PA occur in much the same way).

    Inference: LTE mode is used for data transfer between radio head and co-processors.
    Question: Can LTE mode be used for data transfer between FPGA and DSP core and not radio head/ coprocessors?

     

    2) AIF2 LLD: The AIF2 has a special mode called generic packet for inter-device communication. It allows to used the AIF2 to transfer general digital packets betweens DSPs or between a DSP and a FPGA.

    Inference: Generic packet mode is used for inter-device communication.

    Question: Our use case is to send/receive IQ data between FPGA and DSP core which matches inter device communication mode. But data cannot be sent/received continuously in this mode. Hence, even though generic mode supports inter device communication, it is not best suitable for our use case as it doesnt transfer IQ data continuously? 

     

    3) AIF2 LLD: The AIF2 LLD works together with CPPI and QMSS LLDs to support the transport of LTE antenna samples between the radio equipment and the Keystone FFTC accelerators.

    Inference: In LTE mode, LTE antenna samples are transferred between radio equipment and FFTC accelators and not between FPGA and DSP core.

     

    Kindly guide if LTE mode can be used for 'Inter device communication : Send/receive IQ sample data between FPGA and DSP core on LTE sample rate (1.2 Mbps)'

     

    Thanks

  • 0 in reply to ANUJ AGARWAL
    Intellectual 400 points

    Hi

    I am eagerly waiting for the response.

    Kindly suggest the replies to above queries.

     

    Regards

     

  • 0 in reply to ANUJ AGARWAL
    TI__Expert 4740 points

    Hi,

    Your case looks special. you want to transfer original LTE5 AxC IQ steam continuously but you also want to transfer this data from your FPGA to the DSP core.

    From my thinking, you'd better use LTE AxC mode for this rather using generic packet mode, becasue generic mode has smaller BW and other limitation of transferring continuous IQ stream. in your case, you don't need to directly deliver the received IQ samples to FFTC but just store it on L2 or MSMC memory and DSP core can handle those data in run time. AIF2 fully support flexible DMA for your case. your FPGA can generate full CPRI frame with LTE5 MHz symbols and it will be delivered to DSP local memory by AIF2 DMA machine. you can use TI LLD CPPI and QMSS library to setup DMA for this transfer.

    Regards,

    Albert 

  • 0 in reply to Albert Bae
    Intellectual 400 points

    Dear Albert

    Thanks a lot for the information. Please guide on the below queries as well:

    1) As LTE AxC mode is also not the obvious mode for above mentioned requirements, can you also list the limitations of LTE mode for my use case?

    2) Please elaborate on how to transfer 'continuous' stream of IQ data in LTE mode?

    3) In multicore environment, data shall be received on 1 physical link for all cores. So how can a core be mapped in AIF2 so as to deliver the received packets on 1 link to specific cores?  e.g. In SRIO, we do it with the help of LSU registers and in ethernet, we do it with the help of PDSP and LUT.    So, how core mapping can be achieved in AIF2 and how the decision can be taken that a particular sample/packet is meant for specific core?

    4)  How are AxCs mapped? The numPeAxC (number of AxC on egress side) and numPdAxC (number of AxC on ingress side) are different variables in example code. Does this mean that AxC is not bidirectional? Is it feasible to use 4 AxC (1 per core) against 1 AxC (for all cores)? If yes, how would this mapping be done? And what would be the benefits?

    I am really thankful to you for your guidance and support.

    Thanks

  • 0 in reply to ANUJ AGARWAL
    TI__Expert 4740 points

    here is the answer.

    1) Generic packet mode consumes additional BW by delimiter (4B5B encoding or NULL encoding) and generic mode doesn't support correct timing for LTE. you can generate some general event from AT but you can not guarantee that your LTE symbol receiving time is matched with that AT event timing. AxC mode always support correct symbol streaming timing for both PD,PE and AT and doesn't consume any unnecessary BW for LTE data transfer. AxC mode operation is exactly matched with what your Radio head digital part is doing and it is our original intention of designing AIF2

    2)It is in many of our TI documents and Radio spec. you may get useful information from AIF2 UG, MNavigator UG, CPRI spec 4.1 and LTE spec. Also study AIF2 LTE example code in our PDK or MCSDK (AIF2 LLD)

    3) AIF2 and SRIO is totally different interface. Most AIF2 packet data is AxC symbol and the destination is always monolithic descriptors in the memory (DDR, MSMC, L2). if you use L2 as a destination, specific core program can handle that. if you used DDR or MSMC as a destination, your application should know which core program need to handle which AxC symbol data and how it can be pushed in FFTC input queue. it cannot be handled by AIF2 HW

    4) this question doesn't make sense to me. please read other answers and think about this again. in real case, Egress is used for DL and Ingress is used for UL, so we don't; need to use symmetrical setup for both sides, but it can be symmetrical if user wants to test it with loopback mode.

    Regards,

    Albert

  • 0 in reply to Albert Bae
    Prodigy 20 points

    Hi,

    I also need to transfer the original IQ stream to DSP memory and process it from there.  Can you provide example code on how to do this?  I need to: (1) how to initiate transfer, (2) how to define destination starting and ending addresses in DSP memory, (3) how to reset starting address after reaching end, (4) get an interrupt after buffer is half full or full.

    Thanks,

    John