AIF2 Pi and Delta timing.

Hi Rogue,

Here are responses for your various questions.  Please close (mark "Answered") your other threads where you asked the same questions.  Also, please realize that AIF2 is a very complex peripheral, and as is mentioned on other threads, it takes several passes through the various training materials in addition to extensive experimentation with the hardware itself before it begins to make sense.

1) how is 64 byte RM internal fifo buffer is related to +-5ms drift time?

Actually it is not used for drift at all… The buffer is far too small for that purpose.  It is understandable how you would look to the RM for the drift buffer since other CPRI architectures have put a drift removal buffer in those RM, but the TI CPRI architecture differs.  When daisy chaining (or re-transmitting) the buffer in the RT is used for drift normalization.  For reception of WCDMA traffic, there is a very shallow drift buffer built into the AIF_DIO (or IQN2_DIO).  For all other radio standards, the AIF2/IQN2 does not remove reception drift, but rather writes the received traffic ASAP it the DMA destination buffer.

2)Also in UL or while receiving samples using AIF2 the symbol number and slot number information present in psInfo of descriptor, where does aif2 gets this value - from PHY_timer or RAD_timer.

CPRI: The PHY timer is used as a reference point for starting the link.  Once started, the transmitted link is remains aligned and never drifts, however the received link is a fiber or wired delayed version of the transmitted link. If this fiber connection is very long, the delay can be significant.  Also heating or cooling of this length of fiber/wire can cause a timing variation of the received CPRI traffic.  The received AxC are extracted positionaly relative to the CPRI beginning of frame.  So in effect, the UL samples timing is a function of the transmitting device, and that transmitting device is using the PHY_timer.

OBSIA: The OBSAI PHY is transmission is started via the PHY timer.  The AxC is inserted into the PHY based on the RAD timer.  While these two concepts ideally would be separate, the data is serialized into the OBSAI PHY so there is unfortunately a complex relationship between the two.

3)What is the way to find out if AxCOFFSET programmed is right in case of the aif2 is connected via optical fibre to RF? How do I find out the correct value for axcoffset?

First of all, in a simple system it is best to align the CPRI 10ms frame boundary with the radio frame boundary so that you can simply use an AxC offset of zero.  It’s best to define time==0 when the first sample of LTE Symbol0 arrives at the ADC on your RF board (which is exactly the same time as when sample0 or symbol0 is transmitted at your DAC.  The fact that we have CPRI PHY/LINK offsets and AxC_Offsets gives more degrees of freedom than is useful in a simple system.  However you are free to do it any way you wish.

In your system, you will already need to have clock/timing circuits which exactly align to the LTE radio network.  Ideally you would align the CPRI PHY beginning of frame at the DL RF card to this LTE radio 10ms boundary and set the AxC offsets to zero within the CPRI link.  I don’t know of a good way to measure, but you would observed degradation of the LTE cyclic prefix guard-band when it is done incorrectly.  Perhaps in the lab with a UE which is very close to the BTS reception antenna, when you look at captured LTE Symbols, you would see sample corruption at the beginning or end of the captured LTE Symbol.

4) In CPRI link , if momentarily the RF is shutdown and rebooted again, but the DSP is running just fine, but momentarily aif2 wont be rx any UL iq data, Then should this cause any error, like loss of packet?

This really depends on your definition of “RF is shutdown”..  In CPRI, there is always a transmitting CPRI device and a receiving CPRI device.  TI CPRI devices will continue to pass “zero’ed traffic” when there is no actual traffic to transmit.  In this way, the TI devices will keep the CPRI link up and running even if there is no higher layer SW generating traffic to send.  From the “RF shutdown” condition, it’s not clear if you are also shutting down the CPRI device on the RF card or not.  Assuming that you keep your CPRI device up and running on the RF card and that device will pass zero’s instead of actual AxC traffic, the receiving CPRI device will not “know” the difference between zero’ed traffic and actual AxC traffic.  In both cases, the receiving TI CPRI device will form packets correctly where the content is zero’s or real AxC traffic respectively.

Clearly if your “RF shutdown” also shuts down the CPRI transmitter on the RF board, the receiving CPRI circuit will immediately shutdown as well and attempt to regain sync to the low level CPRI protocol with the CPRI transmitter.   During this period of time, any open packets will be truncated and errored plus not addition packet traffic will commence until after the CPRI PHY protocol is again re-established.

There is a separate discussion for CPRI control traffic which is usually CRC protected.   Most users do not use CPRI control traffic, so it’s not likely the source of your question.