Triggering Configuration Changes - 2.0 English

All changes to the configuration of the DFE PRACH core that affect the processing of data are controlled by a triggering mechanism. This includes activating and deactivating the core, adding and removing component carriers from the TDM sequence, changes to PRACH extraction settings, enabling and disabling antennas, and entry into and exit from low power mode.

First, an XDfePrach_TriggerCfg structure is used to define the triggers. This is passed to the XDfePrach_SetTriggersCfg function to make the new trigger setup current. Then the trigger is made active through a further software API call, according to the particular configuration change that is being made. When the trigger condition is met, the requested change is put into effect by the hardware.

A variable TriggerCfg of type XDfePrach_TriggerCfg has four fields.

• TriggerCfg.Activate defines the trigger to be used for activating and deactivating the core.
• TriggerCfg.RachUpdate defines the trigger to be used for RACH channel, component carrier, and antenna configuration updates. The RACH Update trigger is applied after any update to the CC configuration or RACH channel configuration. The RACH Update trigger applies to all bands.
• TriggerCfg.LowPower defines the trigger to be used for entry into and exit from low power mode.
• TriggerCfg.FrameInit is an array of triggers. Each band can have an independent initialization trigger. There is one array entry per band.
  • FramInit[0] is used to identify the boundary of a radio frame in band 0.
  • FramInit[1] is used to identify the boundary of a radio frame in band 1, if enabled.
  • FramInit[2] is used to identify the boundary of a radio frame in band 2, if enabled.

There are three types of triggers:

Immediate Triggers

The simplest type of trigger is the immediate trigger. To define an immediate trigger, set TriggerCfg.<trigger>.Mode to 0. When an API call that uses the corresponding trigger is subsequently made, the trigger condition is considered to be met as soon as the API performs a write to the hardware register controlling the configuration parameter in question. The configuration change therefore takes effect immediately.

Note: Immediate triggers are primarily used for development and debugging, and also during parts of the core initialization sequence where precise synchronization of updates is not needed. Because the timing of a register write across the AXI interconnect cannot be guaranteed, and the AXI4-Lite control interface operates in a different clock domain from the AXI4-Stream data interface, this mechanism is not suitable for use in situations where sample-accurate alignment of configuration changes is required.

Single-shot Triggers

For activating and deactivating the core, updating the RACH channels and CC configuration, enabling and disabling antennas and synchronizing the frame counter, a single-shot trigger should be used. To define a single-shot trigger, set TriggerCfg.<trigger>.Mode to 1. It is also necessary to define the source for the trigger by setting TriggerCfg.<trigger>.TUSERBit to indicate which bit of s_axis_din_tuser should provide the trigger event. The type of trigger event the hardware should respond to is determined by TriggerCfg.<trigger>.TuserEdgeLevel. Values for this field are listed below:

• 0 defines an active-Low trigger
• 1 defines an active-High trigger
• 2 defines a falling-edge trigger
• 3 defines a rising-edge trigger

When an API call that uses the corresponding trigger is subsequently made, the trigger condition is considered to be met as soon as the specified event occurs on the chosen bit of s_axis_din*_tuser. The delay between the trigger event and the configuration change taking effect depends on the nature of the configuration change, as described in the following sections. Once the trigger has occurred, it is deactivated until the next API call enables it again.

In the multiband case, there are up to three TUSER ports. For Activate, Low Power and RACH Update triggers, s_axis_din0_tuser is always used as the triggering port. These triggers apply across the whole core, and are allocated to the default bus. If performing a Frame Init trigger, the API allows one trigger to be defined per band. Each trigger is then associated with its respective TUSER bus.

Continuous Trigger

Once activated, a continuous trigger causes the corresponding event to occur repeatedly without further software intervention. To define a continuous trigger, set TriggerCfg.<trigger>.Mode to 2 and define the TUSERBit and TuserEdgeLevel fields as described above for a single-shot trigger. When an API call that uses the corresponding trigger is subsequently made, the trigger condition is considered to be met as soon as the specified event occurs on the chosen bit of s_axis_din*_tuser. The delay between the trigger event and the configuration change taking effect depends on the nature of the configuration change, as described in the following sections. The trigger remains enabled so that subsequent activity on the same TUSER bit can cause the requested configuration change to re-occur.

Continuous triggers are primarily useful for the frame synchronization process or for entry into and exit from low power mode, for example to periodically enable and disable uplink processing in a TDD system.

As with the single shot trigger, the Low Power continuous trigger is always associated with the TUSER on band 0. If using the Frame Init Trigger, then a separate trigger can be defined in the API, per band, and is associated with its respective TUSER bus.