IQNet Different configurations

Hi LN,

Can you share which board do you use? Or at least which device?
Also which SDK version is this?

Best Regards,
Yordan

Hi Yordan

We are using
K2L EVM along with AFE7500 EVM
www.einfochips.com/.../k2l-evm.html
RFSDK Ver 2,5
MCSDK Release: 03.01.04
IQN2 LLD Applies to Product Release: 01.00.00.08

Best Regards
LN

Hi,

The experts on this are notified. Their feedback should be posted directly here.

Best Regards,
Yordan

Hi WoodAll,

Actually we would like to implement a sample nudge (either advance 1 sample or delay 1 sample) in the 10ms Frame timing.  The Software based PLL would compute whether the current frame boundary needs to be adjusted by +/1 1 sample.

This adjustment needs to be done for each 10ms frame. Is this possible through some other  method.

Best Regards

LN

I'm doubtful there's anything you can do for the current frame, since IQN2 is in the middle of processing it.  You may be able to adjust the next frame to account for the difference.

There are multiple aspects to this. First, you have to program the AT for frame size in clocks, and for RadT, clocks per sample and clocks per symbol (in the LUT).  Then you program either AID or AIL for the symbols per frame, and samples per symbol (in the LUT).  These must match.  If your total samples per frame (the sum of the symbol lengths) does not match the programmed AT frame time, IQN2 will stop and throw an EE exception.  It is too late to do this while you're in frame, because the hardware has already read the configuration registers.

HI Woodall,

We would like to apply this adjustment for the next frame . Would you think that is possible, We will find out the adjustment in the current frame N and would like to apply in next frame N+1. Also the periodicity of this adjustment is around 50ms . Please let us know all the steps in IQNet configuration

Best Regards

LN

Hi,

To my knowledge this has never been tried, but it should work if you can find the sweet spot in the previous frame for making the update (I would start with a point in the middle of the frame). Without doubt, you should start from a *working* configuration for the normal LTE 10ms frame time. These then are the registers that you will need to modify: (you should read about them in the IQN2 User Guide – there may be multiple copies of the register)

AT:

• BCN Clock Counter TC (AT offset 0x004c)
• BCN Offset (AT offset 0x0020). This may or may not need to change.
• System Event Modulo TC (AT offset 0x0404). You may need to adjust each event’s clocks to keep them in sync with the frame.
• Symbol LUT RAM (AT offset 0x0800). See Note below. If the number of entries in the LUT is changed, then the RadT Counter TC (AT offset 0x0218) will need to change to reflect it (this would be an initialization change, not needed during runtime). The LUT RAM is programmed in clocks.

 AID or AIL: (AID is shown. AIL offsets may be different)

• IQ EFE FRM SAMP TC MMR RAM (AID offset 0x0800). See Note below. If the number of entries in the LUT is changed, then the IQ EFE Frame Count (AID offset 0x0400) will need to reflect it. The MMR RAM is programmed in samples per symbol.
• IQ IFE FRM SAMP TC MMR RAM (AID offset 0x2800). See Note below. If the number of entries in the LUT is changed, then the IQ IFE Frame Count (AID offset 0x2200) will need to reflect it. The MMR RAM is programmed in samples per symbol.
• uAT BCN TC (AID offset 0x5004)
• uAT EGR RadT TC (AID offset 0x5080)
• uAT EGR RadT Offset (AID offset 0x5084) This may not need to be changed.
• uAT ING RadT TC (AID offset 0x5100)
• uAT ING RadT Offset (AID offset 0x5104) This may not need to be changed.
• uAT RadT Event Compare (AID offset 0x5200) This may not need to be changed.
• uAT RadT Event Clock Count TC (AID offset 0x5204)

Basically, any configuration that has to do with clock counts with respect to frame, symbol and event times.

Note: Most of the time, the LUTs are programmed with either a single value (if all the symbols in the frame are the same length), or a slot’s worth (a slot being either 1.0ms or 0.5ms). The entries in the LUT are then looped over to attain a frame’s worth of symbols. To ease the burden of when to apply the change, it may be easier to load the tables with all 140 symbols in the frame.

Good luck!

Dear Woodall,
Thanks for your detailed answer. I am LN's colleague and have been working along the lines you indicated. I would like some clarifications based on my observations:
1) The radio initialization utilities provided in RFSDK initialize only the AID2 versions of the registers you mentioned. Does that mean those are the only ones that are read and hence the only ones that need to be modified?
2) The EGR Radt TC (0x5080) and INGR Radt TC (0x5100) registers contain the value 2457599, which is the number of samples per frame. I am programming this to match the sum of the 140 entries in the IQ EFE FRM SAMP TC MMR RAM and IQ IFE FRM SAMP TC MMR RAM respectively. Would this be the correct approach?
3) The BCN TC(offset 0x5004) contains 0 and so I presume it doesn't need to change?
4) I am programming the above registers once every 50 ms and observe discontinuous Rx (missed samples). How does one overcome this issue? Is there any way to incrementally debug modifications made to the IQNET framework?

Thanks,
Shiv.

Hi Shiv,

Responses:

1) Yes.  If you are using DFE then you will use only AID and not AIL, so the AIL registers are not needed.  You can also globally disable AIL since the LLD will enable them by default.  And the reverse is also true - if you're using SerDes to drive AIL from CPRI/OBSAI, you can just power off AID (literally, you can shut off the DFE power domains).

2) No, the IFE/EFE FRM_SAMP_TC_MMR RAMs are programmed as a terminal count in 32-bit samples per symbol, whereas the EGR/INGR RadT TCs are in clocks per frame.  Don't forget that all of these are "terminal counts" (ie. minus 1).

3) Yes.

4) If possible, you may try starting your tests with one of the alternate configurations.  If it works, then the problem is just the timing of when the registers are written relative to the frame.  In this case, try writing the update earlier in the frame, or later in the frame to see how it affects symbol output.  This is the difficult part of this - knowing when the hardware will read the registers for the frame.  It may require writing the LUTs much closer to when they are used.  Like I said earlier, this has never been done before, so you're breaking new ground... :)