Latency Compensation Setup - 2.0 English

The DFE PRACH core generates some latency to the data, due to the processing pipeline. The minimum latency is equivalent to the delay experienced by a sample undergoing the lowest amount of decimation (2x) in the DFE PRACH core, when it is being processed in the first available slot for a RACH channel.

The decimation rate, the location of the source CCID within the CC sequence and the RACH channel being used to process the decimation can all extend this latency.

The minimum latency can be queried using the following function in the legacy system:

u32 dataDelay;

dataDelay = XDfePrach_GetTDataDelay(InstancePtr);

For a multi-band configuration, the following function can be used:

u32 dataDelay;

dataDelay = XDfePrach_GetTDataDelayMB(InstancePtr, BandID);

Where the BandID specifies which Band the Delay applies to. Note that this call can be used in a single band system by setting BandID==0.

In a multi-band configuration, the core has to adjust the internal frame timing so that the frames on different bands are spaced by integer multiples of 16 clock cycles. This is performed after the Frames are synchronized using FrameInit. When reading back the Data Delay, this adjustment is included in the value returned. The first band (band 0) has no adjustment and therefore, the lowest Data Delay. The other bands are adjusted relative to band 0, with adjustment delays between 0 and 15 clock cycles.

The DFE PRACH core generates the output TUSER signal on the timebase interface by delaying the TUSER signals received on each of the data input interfaces. The default behavior is to delay each TUSER by a number of clock cycles equal to the minimum latency of the data processing pipeline, which corresponds to the value returned by XDfePrach_GetTDataDelay or XDfePrach_GetTDataDelayMB. These TUSERs are then concatenated and output on the timebase interface.

However, you can adjust TUSER by an additional delay, for example, to move the TUSER triggering pulse so that it aligns with the center of the decimating FIR impulse response (group delay). There is no compensation for the processing delays that are caused by different decimation rates applied to different PRACH channels.

The core provides this facility through the functions:

XDfePrach_SetTUserDelay(InstancePtr, 50); // Additional 50 clock-cycle TUSER delay for Band 0

currentDelay = XDfePrach_GetTUserDelay(InstancePtr); //Returns TUSER delay for Band 0

XDfePrach_SetTUserDelayMB(InstancePtr, 75, BandID); // Additional 75 clock-cycle TUSER delay for Band “BandID”

currentDelay = XDfePrach_GetTUserDelayMB(InstancePtr, BandID); //Returns TUSER delay for Band “BandID”

Where the BandID specifies which band the delay applies to. Each band can have its own delay value. This extra delay can be set to any number of clock cycles from 0 to 4042 as required. This delay value is in addition to the delay which is automatically applied by the core to ensure that the data for different bands is separated by an integer multiple of 16 clock cycles.