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 support for LTE UE

Other Parts Discussed in Thread: TSW3725

Hi,

I want to know the AIF2 support for LTE UE (for both FDD and TDD).

Does AIF2 support for the following:

1. Dynamic frame offset changes  for both UL and DL.

2. Dynamic UL and DL configuration at slot level, including first slot.

3. Possibility to route AIF2 system interrupts to other interfaces (say SRIO).

4. Periodic system interrupts at symbol level.

Regards,

Dhanasekaran SS

  • Hi,

    Here is the answer of your questions.

    1. I don't know what is frame offset. you'd better use wording in UG. as far as I know, you can not change those critical setup in run time.

    2. I think slot is not good wording, because LTE has symbol concept and WCDMA has slot concept. if we disable any LTE channel for reconfiguration, the protocol layer will be down for at least one frame time, so we cannot do that on symbol time level and it should be frame time level.

    3. there is no direct event connection from AIF2 to different IP. AIF2 external events are connected to Cores and CICs. your CPU application can handle the incoming event from AIF2 and activate SRIO right away.

    4. Yes. it is main job of AT. please carefully read AT chapter.

    Regards,

    Albert 

  • Hi,

    I am also interested to know the procedure for "Frame Synchronization" (1 milli second) in LTE UE for 20MHz FDD mode.

    I am using Azcom SCBP (with CPRI interface to TI C6618) + TI TSW3725 RF for testing LTE Phy at 20MHz FDD mode.

    I used packet DMA to transfer data from AIF2 to L2 memory. Ran the Cell Search algorithm and found that "T Frame" has the offset of 4650 samples.

    1. I would like to discard the 4650 IQ samples received from AIF2 Rx Interface. How to do this in run time? Is there a register in AIF2 which drops 4650 IQ samples before packet DMA picks up the data and transferred to L2 memory?

    Please specify a way to handle this.

    Thanks in advance,

    Srinivas V

  • Hi,

    Is that 4650 sample delay came from your RRH or FPGA on your board? I think it is too big because it is more than one LTE20 symbol. If the delay is small amount (4 sample ~ 16 sample), we recommend using ingress AxC offset to compensate the delay but I think 4650 sample is too big even though it also can be covered by AxC offset.

    you'd better check your FPGA or radio head design and timing to know what makes such a big delay and try to solve the problem first before thinking about using AxC offset.

    Regards,

    Albert  

  • Hi Albert,


    Thanks for the reply. 4650 sample delay due to processing of LTE at Slot/sub frame level.

    Today I carried out a simple experiment to check whether samples are dropped in AIF2 interface (receive direction - PD).

    AIF2 interface is set to "Monolithic Descriptors" (7) with a event triggering for every 0.5 milli seconds.
    Started captured the data received through Rx Descriptors into a BigBuffer. (10 milli seconds)
    On the fly changed the PD AxC Offset (as listed below):
            aifObj.hCsl->regs->PD_DMACHAN[0] = FALSE;  //Absolute address 0x01F63600
            aifObj.hCsl->regs->PD_DMACHAN_A[0] = 100;   //Absolute address 0x01F64000   (connected to PD AxC Offset)
            aifObj.hCsl->regs->PD_DMACHAN[0] = TRUE;    //Absolute address 0x01F63600
    Continued capturing the data in BigBuffer (10 milli seconds).

    Through Blackhawk emulator, I captured the data to a file (memory dump). I have fed the data to Matlab script which detects the T Frame Boundary (LTE Phy frame). I don't see any change in the location of the T frame (Phy frame boundary offset). I expected 100 samples drift in LTE Phy frame by programming "PD AxC Offset (0x01F64000)".
    Please advice on how to go ahead. My requirement is to drop 100 samples on the fly while AIF2 receive data is transferred to L2 memory through a DMA. I am testing LTE Phy (20MHz) on C6618.

    Question: Is it allowed to reconfigure the PD AxC Offset when link is active? (LTE FDD, TI C6618 connected through CPRI) 


    Thanks & Regards,
    Srinivas V

  • Hi,

    I have never received that kind of request(changing AxC offset runtime) from any other customer and it is quite new to me. but you may try it if you really want. AxC offset operates based on frame boundary. that means if you change the offset in the middle of the current frame, it will be applied from the next frame boundary. this indicates your Rx buffer should be at least 20ms amount to confirm the change. Let me know your test result, if it works for you or not. (just change the AxC offset in runtime, without turning off the channels)

    Regards,

    Albert 

  • Hi Albert,


    Thanks for the reply. I carried out the experiment by just changing the AxC offset in run time, with out turning off the channels. Captured data for 20ms before changing the AxC offset and captured data for 50ms after the AxC offset. I don't see any change in "T" frame boundary (in LTE, 20MHz). So, I conclude that Changing the AxC offset is not dropping the samples in AIF2 Rx (Data transferred for every 0.5ms (slot level) using packet DMA, with 7 monolithic descriptors (as per the AIF2 example provided in pdk).

    aifObj.hCsl->regs->PD_DMACHAN_A[0] = 1000;   //Absolute address 0x01F64000   (connected to PD AxC Offset)

    Do I need to change some alter/modify some other registers in AIF2 to drop the samples before they are transferred (through packet DMA) to L2 memory (on C6618)? I am running LTE UE Phy layer software at 20MHz.

    Thanks & Regards,

    Srinivas V

  • that means the AxC offset cannot be applied in run time and the channel should be turned off and on.

    Axc offset will drop certain amount of the first samples in frame if it is correctly applied (I already tested it several times) you may confirm this by applying the axc offset from init time and you will see the offset amount of data will be dropped from the received packet.

    Regards,

    Albert