Dynamic PRACH Scheduling - Dynamic PRACH Scheduling - 2.0 English - PG391

RFSoC DFE PRACH LogiCORE IP Product Guide (PG391)

Document ID
PG391
Release Date
2025-11-26
Version
2.0 English

The dynamic PRACH scheduling mechanism allows an AXI4-Stream control interface to control the demodulation frequency, CCID source, decimation configuration, location, and duration for a PRACH capture. To make use of the dynamic scheduling mode, you must enable it when the core is configured.

Dynamic scheduling instructions are provided in the form of a configuration packet. This is supplied to the core using the s_axis_sched interface. The dynamic configuration packet (DCP) consists of seven 32-bit words. It is based on the structure of the ORAN C-Plane packet (see O-RAN-WG4.CUS.0 v6.00, table 5.6). The packet must arrive at least 1/32 ms in advance of the intended start point of the PRACH capture.

The s_axis_sched interface is an AXI4-Stream interface. The operation of the s_axis_sched interface is illustrated below.

Figure 1. Timing Diagram for the s_axis_sched Interface

The s_axis_sched interface can accept AXI4-Stream data in which TVALID toggles. This is an update from v1.1, in which the s_axis_sched interface only operates with packetized data, with TVALID remaining High for the duration of the packet. In v2.0, the core can deassert TREADY while the packet is being received.

If the interval between consecutive packets is at least seven cycles, back pressure does not occur on TREADY. If DCP packets are sent to the core with an interval of less than seven cycles between packets, then TREADY can be deasserted. This can be verified using the DFE PRACH Example Design to experiment with different timing cases.

The DFE PRACH core can accept sequential dynamic control packets. However, it is expected that sequential packets apply to different RCIDs. If multiple dynamic control packets are sent to the same RCID, the first packet received for that RCID is overwritten by the later packets.

If requesting multiple captures on the same RCID, wait until the first capture has begun (samples begin to output) before sending the second DCP. In this scenario, the second DCP begins its capture at the scheduled time as long as that is after the first DCP has finished.

Figure 2. Timing Diagram for Multiple Captures on the Same RCID

You can see that the two DCP for the same RCID are input to the core such that the second DCP does not enter until the output samples from the first have begun. This allows captures to be specified such that the end of the first and the start of the second occur on consecutive slots. If targeting consecutive slots, the TLAST on the first capture appears approximately 1/64 ms before the true end of slot (not indicated in figure). This is necessary to provide time to load the second DCP into the core.

Version 2.0 of the DFE PRACH core has a different structure of the DCP that the one in version 1.1 and earlier. The latest version of the dynamic control packet exposes the decimation setting used in the dynamic capture. This allows greater control of the decimation rate, which is useful when extracting multiple PRACH channels adjacent in frequency (extracted as a single channel).

The updated DCP also exposes the NCO settings. This allows the core to set an arbitrary demodulation frequency, for instance, based upon the number of channels adjacent in frequency. In earlier versions, the core derived the NCO frequency based on the PRACH PRB values.

The updated dynamic control packet also allows the duration of the PRACH capture to be specified. In previous version, this was calculated based upon the frameStructure and the requested number of FFTs. The length of the capture is now specified directly as a number of slots.