Status, Events, and Interrupts - 2.0 English

RFSoC DFE PRACH LogiCORE IP Product Guide (PG391)

Document ID
PG391
Release Date
2024-05-30
Version
2.0 English

The DFE PRACH core continuously monitors for error conditions and records them in status registers. The API provides access to this error information, along with other status signals generated by the core. A full set of interrupt enable, disable, masking and clearing functions is provided to support designs where the optional IRQ signal is connected to the control microprocessor.

The following datapath error conditions are individually recorded by the DFE PRACH core:

Arithmetic overflow within the NCO mixing stage
Arithmetic overflow occurs in the NCO mixing stage when the demodulation of the CC samples by the NCO output exceeds the 16-bit datapath available in the core.
Arithmetic overflow within the decimation filter chain
Arithmetic overflow occurs in the decimating filter when the FIR result exceeds the 16-bit datapath available in the core.
Flow control overrun within the NCO channel selector
Overrun within the NCO channel selector occurs when the aggregate bandwidth into the NCO exceeds Fc, the core clock. Each NCO supports up to four time-interleaved CCs. The sample rate on any one CC is either Fc/16, Fc/8, Fc/4, or Fc/2. If the cumulative sample rate of all of the CCs being processed by an NCO is greater than Fc, then an overrun will occur.
Flow control overrun within the decimation filter channel selector
Decimator overrun occurs when the aggregate sample rate at the input of one of the FIR stages exceeds Fc. As decimation occurs, pairs of channels are combined (TDM) to supply input to the next stage of filtering. If too many channels are decimated, at too low a decimation rate, then the aggregate sample rate will be too high for the next FIR to process and an overrun will occur.

In all cases of datapath errors, the identity of the RACH channel and antenna affected by the overflow or overrun is recorded. If more than one such event occurs, only the identity of the lowest-numbered channel or antenna is preserved.

The following additional events can also be accessed via the API:

Band 0 CC sequence error
If the input TID sequence presented on s_axis_din0_tid does not match the band 0 configuration programmed into the core via the API, an error is flagged.
Band 1 CC sequence error
If the input TID sequence presented on s_axis_din1_tid does not match the band 1 configuration programmed into the core via the API, an error is flagged.
Band 2 CC sequence error
If the input TID sequence presented on s_axis_din2_tid does not match the band 2 configuration programmed into the core via the API, an error is flagged.
RACH update triggered
When a RACH update is requested, this status information confirms whether the trigger condition was met. Triggering of RACH update will adopt a new RACH channel and component carrier configuration into the core. Triggering without uploading new RACH channel and component carrier configuration will lose the current configuration and cause unpredictable results. Newly adopted configurations will not start a RACH capture until a Frame initialization is triggered.
Band 0 Frame Initialization triggered
Indicates that the frame initialization trigger for band 0 has been seen on s_axis_din0_tuser. When this triggering condition is met, any new RACH configuration for band 0, which has been adopted by a RACH update will be activated.
Band 1 Frame Initialization triggered
Indicates that the frame initialization trigger for band 1 has been seen on s_axis_din1_tuser. When this triggering condition is met, any new RACH configuration for band 1, which has been adopted by a RACH update will be activated.
Band 2 Frame Initialization triggered
Indicates that the frame initialization trigger for band 2 has been seen on s_axis_din2_tuser. When this triggering condition is met, any new RACH configuration for band 2, which has been adopted by a RACH update will be activated.
Band 0 Frame Error
A frame initialization trigger is only ever expected on the boundary between two radio frames. The Frame Error event indicates that a frame initialization trigger has been seen on band 0 at a time when it was not expected. This indicates that either the scheduling logic or the system timing has entered a corrupted state. The core should be deactivated and reactivated to align the frame correctly.
Band 1 Frame Error
A frame initialization trigger is only ever expected on the boundary between two radio frames. The Frame Error event indicates that a frame initialization trigger has been seen on band 1 at a time when it was not expected. This indicates that either the scheduling logic or the system timing has entered a corrupted state. The core should be deactivated and reactivated to align the frame correctly.
Band 2 Frame Error
A frame initialization trigger is only ever expected on the boundary between two radio frames. The Frame Error event indicates that a frame initialization trigger has been seen on band 2 at a time when it was not expected. This indicates that either the scheduling logic or the system timing has entered a corrupted state. The core should be deactivated and reactivated to align the frame correctly.

The use of the XDfePrach_GetEventStatus and XDfePrach_ClearEventStatus functions to check the CC sequence error and RACH update trigger status was described in the previous sections. The same mechanism is used to obtain information about overflow and overrun events. Details of the exact location of the overflow or overrun can be retrieved using the function XDfePrach_GetStatus, as shown by the following code.

/* Declare a status mask structure */
XDfePrach_StatusMask status_bits;

/* Query the core status */
XDfePrach_GetEventStatus(InstancePtr, &status_bits);

if (status_bits.DecimatorOverrun != 0) {
  XDfePrach_Status status;
  XDfePrach_GetStatus(InstancePtr, &status);

  printf("Decimator Overrun: RCID #%d, antenna %d\n",
    status.DecimatorOverrun.FirstRCIdOverrunning);
    status.DecimatorOverrun.FirstAntennaOverrunning);
}

For details of the other information available from the XDfePrach_GetStatus function, see XDfePrach_GetStatus.

An interrupt masking function is provided to support designs where the optional IRQ signal is connected to the control microprocessor, or to other logic such as an integrated logic analyzer core. The following code demonstrates how to choose which of the events will generate an interrupt on the IRQ output of the core.

/* Declare an interrupt mask structure */
XDfePrach_InterruptMask IrqMask = { 0 }; // All interrupts enabled (unmasked)

/* Populate the structure */
IrqMask.DecimatorOverflow  = 1; // Disable (mask) Decimator overflow interrupts
IrqMask.MixerOverflow      = 1; // Disable (mask) Mixer overflow interrupts

/* Set up the interrupt mask */
XDfePrach_SetInterruptMask(InstancePtr, &IrqMask);

Whenever an event occurs, the corresponding bit will be set in the event status register and an interrupt will be generated by driving IRQ high unless the event has been masked as shown above. If the same event then re-occurs before XDfePrach_ClearEventStatus has been called, the status bit and the IRQ state will remain high. The IRQ line will not be driven low again until the event has been cleared.