In software-defined radio (SDR), it can be useful to dynamically reconfigure the RF front-end (RFFE) between two consecutive packets. One common example is to apply a frequency-hopping scheme to the transmitted waveform, which makes the transmission more resistant to jamming since the frequency band used keeps changing.

Dynamic RFFE reconfiguration can also be used in cognitive radio applications. Cognitive radio adds an “intelligent” aspect to the RFFE. Unoccupied channels can be dynamically selected in order to avoid interface with other users (often referred to as “spectrum sensing”) or the best channel can be chosen in order to meet user requirements and provide the appropriate level of quality of service (QoS).

Since the RFFE is reconfigured dynamically, it means that a certain amount of time is required and the configuration process must have a low latency is order to avoid communication link downtime.

In the blog post series, OFDM reference design: Moving into cognitive mode (part 1, part 2), a cognitive behavior was added to the OFDM reference design included with Nutaq's Advanced Development Platform (ADP) software suite and implemented on the Radio420X FPGA mezzanine card (FMC). In this cognitive radio demonstration, twelve registers in the Radio420X’s LMS6002D RF integrated circuit (RFIC) are reconfigured in order to change the local oscillator frequency. Six registers are for the reception path while the other six are for transmission. Depending of the current and target frequencies, all six in each path do not necessarily need to be reconfigured (see the “TX/RX PLL” section of the LMS6002D Programming and Calibration Guide).

The LMS6002D uses a Serial Peripheral Interface (SPI) to provide external access to its internal register. When the Radio420X FMC is connected to a carrier board, the FPGA is the master of the SPI bus. The application programming interface (API) included with the ADP provides high-level functions to configure the phase-lock loop (PLL) parameters of the LMS6002D. However, once the decision to reconfigure the RFFE has been made by the processing algorithm, the SPI commands go through the FPGA’s soft microcontroller (MicroBlaze), which can add a significant amount of latency. This extra latency may not be suitable for applications that have high performance requirements.

To avoid this problem, the Radio420X has ports for directly generating SPI transactions from the FPGA user logic. Since the decision can be made inside the FPGA logic, the latency can be kept consistent and as low as possible.

One factor that affects the reconfiguration time of the local oscillator is the SPI transaction time. In this post, the latency of the SPI core inside the Radio420X is benchmarked.

SPI transaction time

For the SPI transaction time benchmark, the same logic described in OFDM reference design: Moving into cognitive mode – part 2 has been used. A ChipScope core was added to the design to monitor the start and busy flags of the LMS6002D SPI core.

For the test, the design clock has been configured to 80 MHz. The SPI core uses an independent clock derived from the reference clock of the FPGA board. When the SPI clock is configured to 10 MHz, the following ChipScope acquisitions were obtained:

Figure 1: First SPI transaction time at 10 MHz

Figure 1: First SPI transaction time at 10 MHz

Figure 2: Total SPI transaction time for 12 registers at 10 MHz

Figure 2: Total SPI transaction time for 12 registers at 10 MHz

Between the start bit and the deassertion of the busy flag of the first transaction, there are 270 clock cycles at 80 MHz. This represents 3.375 µs or approximately 34 clock cycles at 10 MHz. The 34 clock cycles are due to the 16 bits that need to be transferred (R/W bit + 7-bit address + 8-bit data) and some delays before and after the bit transaction. Between SPI transactions of each register, a few clocks cycles at the design clock frequency are added due the user logic implementation of this benchmark. As shown in Figure 2, the total transaction time of 12 registers is 3350 clock cycles or 41.875 µs. 

By increasing the SPI clock frequency, the transaction time should decrease linearly since almost all of the logic uses the SPI clock. The following result was obtained with a 20 MHz SPI clock:

Figure 3: First SPI transaction time at 20 MHz

Figure 3: First SPI transaction time at 20 MHz

Figure 4: First SPI transaction time at 20 MHz

Figure 4: Total SPI transaction time for 12 registers at 20 MHz

Figure 3 shows that the time for one SPI transaction has dropped from 3.375 µs at 10 MHz to 1.775 µs at 20 MHz. Figure 4 shows that the time for 12 SPI transactions has dropped from 41.875 µs at 10 MHz to 21.575 µs at 20 MHz. These results confirm that SPI transaction time is mainly related to the SPI clock frequency.

All the source code for the SPI core implementation is available in the Radio420 folder of the ADP installation. The current clock frequency for the LMS6002D SPI core can be configured in spi_radio420x.vhd while the implementation of the SPI core is in spi_register.vhd. The current implementation of the SPI core can certainly be optimized in order to further decrease the latency of the SPI transactions if your application has higher requirements. The extra delays before and after the SPI transactions could be dropped if the core is able to handle consecutive transactions without toggling the serial enable signal. The SPI core would then only take 16 SPI clock periods.

The LMS6002D datasheet states that it can handle a 50 MHz SPI clock at 3.3V. On the Perseus601X carrier board, the voltage of the SPI signals is set to 2.5V, therefore a frequency a little bit lower than 50 MHz could be reached.