The previous version of the DCP is shown below. This has changed in a number of ways compared to the DCP described in Dynamic Control Packet v2.0. If upgrading from a system which uses version 1.1 DFE PRACH in the AMD Vivado™ Design Suite 2022.2 or earlier, this appendix details how the DCP should be altered to work with the new version of the core.
Some of the fields remain the same as in v1.1 and earlier, but have moved position within the packet. The RCID, CCID, slotID, subFrameID, frameStructure, numSumb, Dual Preamble, cpLEngth, and timeOffset field all retain the same definition as previously. However, it should be noted that some of these fields no longer have any effect on the behavior of the DFE PRACH core. They remain in the DCP because they contain information which may be required by the FFT PRACH processing. For more information, see the RFSoC FT PRACH LogiCORE IP Product Guide (PG429). The fields which fall under this category are: frameStructure, numSymb, Dual Preamble, cpLength, and timeOffset.
- The RCID field continues to be used by the DCP to identify the RACH channel that the capture is running on.
- The CCID field continues to be used to identify the source component carrier that a PRACH capture is coming from. This field is now used in conjunction with a band field, which identifies which band the CCID belongs to. If converting a legacy packet, which will be single band, the band field should be forced to 0 in the updated packet.
- The Config ID is no longer used by the DCP and has been removed.
- The FrameID is no longer used by the DCP and has been removed. Previously, this was an optional field. From v2.0, all dynamic control packets will act on the next slot and subframe, which match those requested, without reference to the current frame. Any management of capture requests with respect to FrameID must take place externally.
Length
The length of a capture was previously calculated based upon the decimation rate, the FFT size and the number of FFTs requested. This calculation has been removed from the DFE PRACH core and replaced by a "length" field. The length field specifies how many slots to capture (see Dynamic Control Packet v2.0). The required length can be calculated as follows:
-
FFTduration = 1/SCSPRACH seconds
-
Total FFT Duration = numSym * FFTduration seconds
-
Total PRACH duration = Total FFT Duration + CyclicPreficLength seconds
-
Required number of slots = Ceiling (Total PRACH duration/slot duration)
The SCSPRACH value forms part of the FrameStructure field in the legacy packet. The Slot duration varies depending upon the SCS value for the source CCID and will be part of the uplink configuration.
Decimation
In the legacy DCP, the decimation rate was calculated by the core. In the current DCP, the decimation rate is specified directly in the Decimation field (see Dynamic Control Packet v2.0). The value that should be placed in this field can be taken from (see Table 3, which shows the supported formats).
If using an FFT size not listed in the table, alternative decimation rates can be calculated as follows:
The FFT Size forms part of the FrameStructure field in the legacy packet. The CC Sample Rate will be part of the uplink configuration.
The fields of the legacy dynamic configuration packet are detailed in the following tables.
| Field Name | Bits | Definition |
|---|---|---|
| configID | 12 | Configuration identifier supplied by the external scheduling logic. Not used by the DFE PRACH core. |
| RCID | 4 | RACH channel identifier (0-15). Must correspond to an enabled RACH channel. |
| CCID | 4 | Component carrier identifier (0-15) from which to extract the RACH. |
| FrameID | 8 | Frame number for start of capture (0-255). Note: Frame number
is tracked internally from 0 to 255. The internal frame count is
initialized to 0 when the first
frame_init trigger is seen on the TUSER
bus.Note: Frame
number check can be disabled with
XDfePrach_Init.EnableUseFrameID == 0. With this
setting, the Dynamic scheduler will only check the subFrameID
and slotID when looking for a match. The FrameID will be
ignored. |
| subFrameID | 4 | Subframe number for start of capture (0-9). |
| slotID | 4 | Slot number for start of capture (0-7 depending on sub-carrier spacing, as described in static scheduling section above). |
| frameStructure | 8 | The frameStructure, in conjunction with the CCID
configuration, determines the decimation rate applied to the RACH
capture. Bits [7:4] determine the target FFT size for the captured output. Bits [3:0] determine the PRACH sub-carrier spacing (SCS). Refer to Table 3 for full details. |
| DualPreamble | 1 | Dual Preamble bit can be set when PRACH channels
are adjacent in frequency domain. This reduces the total decimation applied to the channel by a factor of 2x. This alters the frequency offset (if used) to calculate the center between the two preambles rather than in the middle of a single preamble. |
| frequencyOffset | 24 | Value of demodulation frequency for PRACH
down-conversion. Used to program the NCO. In units of 0.5*SCS, where
SCS is the PRACH channel's subcarrier spacing. If
the core has been initialized with If the core has been initialized
with |
|
numSymb |
4 | numSymb is the number of FFTs required by the dynamic capture. The core captures sufficient samples to drive numSym+1 FFTs, each of the length given by frameStructure[3:0]. The field is diminished so a value of "0" capture 1 FFT, "1" captures 2 etc. |
| cpLength | 17 | Cyclic prefix length. Not used by the DFE PRACH core. |
| timeOffset | 17 | Time offset of PRACH from capture start position. Not used by the DFE PRACH core. |