Latency Compensation Setup - Latency Compensation Setup - 2.0 English - PG391

The DFE PRACH core generates some latency to the data due to the processing pipeline. The minimum latency is equal to the delay experienced by a sample undergoing the lowest level of decimation (2x) in the DFE PRACH core. This occurs when the sample is processed in the first available slot for an RACH channel.

The following factors can extend this latency:

• The decimation rate
• The location of the source CCID within the CC sequence
• The RACH channel being used to process the decimation

Use the following function to query the minimum latency in the legacy system (single band configuration):

u32 dataDelay;

dataDelay = XDfePrach_GetTDataDelay(InstancePtr);

For a multi-band configuration, use the following function:

u32 dataDelay;

dataDelay = XDfePrach_GetTDataDelayMB(InstancePtr, BandID);

Where the BandID specifies which band the delay applies to. You can use this call in a single band system by setting BandID==0.

In a multi-band configuration, the core must adjust the internal frame timing. This is done 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 the FrameInit triggers. 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. It does so 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. This value 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 processing delays 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. The core can set this extra delay to any number of clock cycles from 0 to 4042 as required. The frames of all three bands must be aligned on an integer multiple of 16 clock cycles. If they are not externally aligned, the core automatically applies an internal delay to meet this requirement. The extra delay is in addition to this automatic delay.