Increasing the number of quicktune profiles

[bluewater]

Hi everyone, I'm trying to increase the number of quick_tune profiles from the 256 limit and need some help.
First I'm assuming this is possible in the first place, if not I'd be curious what limits the number of quick tunes to 256?
I have tried to increase available memory within the NIOS to accommodate more quick tune profiles by doing the following:

in the following files change :
hdl/fpga/platforms/common/bladerf/software/bladeRF_nios/src/devices.h
hdl/fpga_common/include/bladerf2_common.h
Change
-#define NUM_BBP_FASTLOCK_PROFILES 256
+#define NUM_BBP_FASTLOCK_PROFILES 2400

in the following file:
hdl/fpga/platforms/bladerf-micro/build/nios_system.tcl
Change:
-set_connection_parameter_value nios2.data_master/ram.s1 baseAddress {0x00020000}
+set_connection_parameter_value nios2.data_master/ram.s1 baseAddress {0x00040000}
-set_connection_parameter_value nios2.instruction_master/ram.s1 baseAddress {0x00020000}
+set_connection_parameter_value nios2.instruction_master/ram.s1 baseAddress {0x00040000}

in the following file:
hdl/fpga/platforms/bladerf-micro/build/platform.conf
Double rams value:
function get_qsys_ram() {
if [ "${1}" == "A4" ] || [ "${1}" == "A5" ] || [ "${1}" == "A9" ]; then
+ #rams=131072
+ rams=262144
else
rams=32768
fi

Then I rebuilt all libraries and firmware. Ubuntu 20.04, Quartus 17.1, BladeRF May Release commit(e50f28f)
I no longer get memory errors while performing more than 256 bladerf_get_quick_tune() calls,
but when I try to bladerf_schedule_retune() thru those profiles, I only see RF transmissions for the last 256 frequencies being hopped over.
For example if I call bladerf_get_quick_tune() for freqs 0-255 everything works fine.
But if I call bladerf_get_quick_tune() for freqs 0-512, I only see hopping over freqs 256 thru 512.
Perhaps when the profiles are being saved to memory in NIOS, any profile over 256 will write over the existing stored profiles?
Perhaps a uint8_t variable might explain this behavior ?
I'm really struggling with this and if anyone has any thoughts or could point me in a direction to focus my efforts I sure would appreciate it!

[dre]

I've been looking into the same thing... I'm trying to get 1024 fastlock parameters to work and I see the same thing where it doesn't replay all of the frequencies that are supposedly stored. It was only doing a quarter of them, and it didn't click until you mentioned an 8-bit rollover, which now makes sense now.

I started looking into the NIOS core to try and figure out where the recall of the parameters might be and I haven't found anything obvious. Have you had any luck finding where an 8-bit rollover might be occuring?

[radiomuxer]

Mind trying the pkt_retune2.c changes below with your nios_system.tcl and platform.conf changes? If 512 profiles works, then try incrementing RETUNE_QUEUE_MAX until the desired number of profiles is met.

Code: Select all

--- a/hdl/fpga/platforms/common/bladerf/software/bladeRF_nios/src/pkt_retune2.c
+++ b/hdl/fpga/platforms/common/bladerf/software/bladeRF_nios/src/pkt_retune2.c
@@ -41,9 +41,9 @@ void rfic_invalidate_frequency(bladerf_module module);
 #endif
 
 /* The enqueue/dequeue routines require that this be a power of two */
-#define RETUNE2_QUEUE_MAX   16
-#define QUEUE_FULL          0xff
-#define QUEUE_EMPTY         0xfe
+#define RETUNE2_QUEUE_MAX   512
+#define QUEUE_FULL          ((uint16_t)0xffff)
+#define QUEUE_EMPTY         ((uint16_t)0xfffe)
 
 /* State of items in the retune queue */
 enum entry_state {
@@ -63,20 +63,20 @@ struct queue_entry {
 };
 
 static struct queue {
-    uint8_t count;      /* Total number of items in the queue */
-    uint8_t ins_idx;    /* Insertion index */
-    uint8_t rem_idx;    /* Removal index */
+    uint16_t count;      /* Total number of items in the queue */
+    uint16_t ins_idx;    /* Insertion index */
+    uint16_t rem_idx;    /* Removal index */
 
     struct queue_entry entries[RETUNE2_QUEUE_MAX];
 } rx_queue, tx_queue;
 
 /* Returns queue size after enqueue operation, or QUEUE_FULL if we could
  * not enqueue the requested item */
-static inline uint8_t enqueue_retune(struct queue *q,
+static inline uint16_t enqueue_retune(struct queue *q,
                                      fastlock_profile *p,
                                      uint64_t timestamp)
 {
-    uint8_t ret;
+    uint16_t ret;
 
     if (q->count >= RETUNE2_QUEUE_MAX) {
         return QUEUE_FULL;
@@ -96,9 +96,9 @@ static inline uint8_t enqueue_retune(struct queue *q,
 
 /* Retune number of items left in the queue after the dequeue operation,
  * or QUEUE_EMPTY if there was nothing to dequeue */
-static inline uint8_t dequeue_retune(struct queue *q, struct queue_entry *e)
+static inline uint16_t dequeue_retune(struct queue *q, struct queue_entry *e)
 {
-    uint8_t ret;
+    uint16_t ret;
 
     if (q->count == 0) {
         return QUEUE_EMPTY;
@@ -131,7 +131,7 @@ static inline struct queue_entry* peek_next_retune(struct queue *q)
 
 /* Get the queue element at the given offset relative to the removal index */
 static inline struct queue_entry* peek_next_retune_offset(struct queue *q,
-                                                           uint8_t offset)
+                                                           uint16_t offset)
 {
     if (q == NULL) {
         return NULL;
@@ -410,7 +410,7 @@ void pkt_retune2(struct pkt_buf *b)
                 status = -1;
         }
     } else {
-        uint8_t queue_size;
+        uint16_t queue_size;
 
         switch (module) {
             case BLADERF_MODULE_RX:

[radiomuxer]

Found the uint8_t nios profile number mask on fastlock save. This should fix it.

Code: Select all

--- a/hdl/fpga/platforms/common/bladerf/software/bladeRF_nios/src/pkt_8x32.c
+++ b/hdl/fpga/platforms/common/bladerf/software/bladeRF_nios/src/pkt_8x32.c
@@ -98,7 +98,7 @@ static inline bool perform_write(uint8_t id, uint8_t addr, uint32_t data)
 
 #ifdef BOARD_BLADERF_MICRO
         case NIOS_PKT_8x32_TARGET_FASTLOCK:
-            adi_fastlock_save( (addr == 1), (data >> 16), (data & 0xff));
+            adi_fastlock_save( (addr == 1), (data >> 16), (data & 0xffff));
             break;
 #endif  // BOARD_BLADERF_MICRO

[dre]

radiomuxer -- that looks promising! I'll have to wait until the weekend to try, but just looking at the code and the calls to that function that might be where the rollover is happening. I'll also try your other suggestions as well. -- Thanks

[radiomuxer]

These changes can be found on branch dev-more-quicktune-profiles.

[bluewater]

Thank you radiomuxer for taking the time to respond and for looking into this! I can confirm that changing:
- adi_fastlock_save( (addr == 1), (data >> 16), (data & 0xff));
+ adi_fastlock_save( (addr == 1), (data >> 16), (data & 0xffff));
has allows me to expand and use the number of quick tune profiles for my needs. Thank you again! Any chance this change will find its way into the main line code, or is this something I'll have to update on my own?

[dre]

The changes to the adi_fastlock_save call worked for me as well.

I took a look at the link supplied by radiomuxer and I've got some questions. On the A9 build chain I was able to get up to 3865 for the NUM_BBP_FASTLOCK_PROFILES define. I was not able to get up to 3880 however. The error messages indicated that I was running out of RAM. Here's the last successful compile I got for the A9.
##########################################################################
Done! Image, reports, and checksums copied to:
hostedxA9-2024-12-06_15.06.31

hostedxA9.rbf checksums:
MD5: a606a9ca5aa81be7c15db88e29b6f4b6
SHA256: b8c72de9e3707cc2058657eacd1f57583ce571153e253323bd187648816f7707

Fitter Status : Successful - Fri Dec 6 15:05:20 2024
Quartus Prime Version : 17.1.0 Build 590 10/25/2017 SJ Lite Edition
Revision Name : hosted
Top-level Entity Name : bladerf
Family : Cyclone V
Device : 5CEBA9F23C8
Timing Models : Final
Logic utilization (in ALMs) : 6,695 / 113,560 ( 6 % )
Total registers : 14437
Total pins : 173 / 224 ( 77 % )
Total virtual pins : 0
Total block memory bits : 3,012,096 / 12,492,800 ( 24 % )
Total RAM Blocks : 374 / 1,220 ( 31 % )
Total DSP Blocks : 8 / 342 ( 2 % )
Total HSSI RX PCSs : 0
Total HSSI PMA RX Deserializers : 0
Total HSSI TX PCSs : 0
Total HSSI PMA TX Serializers : 0
Total PLLs : 3 / 8 ( 38 % )
Total DLLs : 0 / 4 ( 0 % )
##########################################################################

For the A4, I was only able to get up to 2048. I kept getting fitter errors and not RAM errors. I found an error message:
"Error (170048): Selected device has 308 RAM location(s) of type M10K block. However, the current design needs more than 308 to successfully fit"

I'm using Quartus II 17.1.0.590 to compile on Ubuntu 20.04.1. I don't think newer versions of Quartus would improve the fitting issue.

Radiomuxer, have you guys been able to compile 2048 fastlock profiles for the A4? There might have to be some checks in the tcl build to break out the A4 vs A9 to declare additional memory.