Compiler optimization -O0 and RAM size for bladerf-micro-A9-hosted

[adc]

Hi.

I'm using:

- bladerf-micro-A9-hosted
- Ubuntu 22.04.3 LTS
- Quartus 22.1 lite
- Terasic USB blaster

I'm trying to debug the NIOS C code using gdb. As reported in the ...hdl/fpga/platform/common/README.md file:

Another common occurence when debugging is finding out that a variable has been optimized out and its value is not printable. The best way to get around this is to reduce the level of compiler optimization.

So, I changed the compiler optimization from -OS to -O0, as recommended. When I try to compile, the compiler complains about a couple of C lines but they can be temporarily commented out. After that, it states that the available memory is not enough (as from the README). Again. according to the readme:

Open $BLADERF_DIR/hdl/fpga/platforms/<platform>/build/platform.conf
Find the get_qsys_ram function, and change the return value to be the nearest power of 2 larger than the required memory size from the above. Sometimes simply doubling the existing return value is good enough.
Rebuild the FPGA in its entirety. This is required because the FPGA needs to instantiate more block RAMs to fit the larger Nios, and it will need to re-fit the surrounding logic.

Therefore, I changed the RAM size (platform.conf, line 42) from:

Code: Select all

rams=131072

to

Code: Select all

rams=262144

When I try to run the build_bladerf.sh script, however, I get the following error message:

Code: Select all

2023.12.19.17:45:22 Error: nios_system.nios2.data_master: <b>ram.s1</b> cannot be at 0x20000 (0x0 or 0x40000 are acceptable)
2023.12.19.17:45:22 Error: nios_system.nios2.instruction_master: <b>ram.s1</b> cannot be at 0x20000 (0x0 or 0x40000 are acceptable)

As an alternative solution, I tried to modify the size of the RAM using the Platform Designer in Quartus. Here I got the same error message but I changed the base address to 0x0004_0000 and all seemed to be ok. Then, I compiled the project using Quartus and I could see the related changes in the RTL viewer (for instance, the memory addr is one bit longer). I also managed to compile the C code after regenerating the bsp.

I can download the new image on the FPGA, but unfortunately, I cannot manage to run the JTAG for any task related to the NIOS with the new image. In particular, I cannot download the .elf file:

Code: Select all

Info: Downloading ../../../../../quartus/work/bladerf-micro-A9-hosted/bladeRF_nios/bladeRF_nios.elf
nios2-download: Searching for JTAG Node Instance for nios2 in ../../../../../quartus/work/bladerf-micro-A9-hosted/output_files/hosted.jdi
Using cable "USB-Blaster [1-10.1]", device 1, instance 0x00
Pausing target processor: not responding.
Resetting and trying again: FAILED
Leaving target processor paused
make: *** [../../../common/bladerf/software/bladeRF_nios/Makefile:1002: download-elf] Error 4

and I cannot connect the debugger:

Code: Select all

Using cable "USB-Blaster [1-10.1]", device 1, instance 0x00
Pausing target processor: not responding.
Resetting and trying again: FAILED
Leaving target processor paused

The JTAG and all the rest work smoothly when I switch back to the original settings and I run again the same procedure.

Any idea about the cause of this issue?

Thanks!

[robert.ghilduta]

It sounds like there might be an alignment or otherwise overlapping memory region due to the size increase. I would suggest going back to Platform Designer, making the changes, and (in Platform Designer) go to System -> Assign Base Addresses. This should reshuffle the memory space to make room and align everything. Hopefully this fixes the issue. To make the change persistent, you'll have to copy some of the nios_system file parameters back to nios_system.tcl . Also please don't forget to generate the QSYS file by going to Generate -> Generate HDL in Platform Designer!

[adc]

Hello Robert,

Thanks for your answer. The Address Map on Platform Designer doesn't show any overlap for the configuration I was using. However, as you suggested, I tried to "Assign Base Addresses" again, and I can see several changes in the Address Map. Please note that the addresses get modified even if I run "Assign Base Addresses" without changing anything. Unfortunately, this operation doesn't seem to fix the issue, as the final outcome is the same. The issue seems to be related to the base address of the RAM. If I block it to its original value (0x0002_0000), the other addresses can be reassigned without any issue. However, the Platform Designer indicates that when the memory size is 262144 bytes, the base address of the RAM should be 0x0000_0000 or 0x0004_0000, and none of these two values works. Please note that what is described above also happens if I keep the original memory size (131072 bytes).

Any other ideas?

Thanks.

[robert.ghilduta]

Here is the patch I tried (before compiling anything else). Make sure to run build_bladerf.sh with -c . I think the issue was that modifying the FPGA source code after the BSP was built causes the BSP (which the C NiOS code uses to reference everything) to be stale. Building with the new RAM values from start make the BSP also refer to the correct addresses.

Code: Select all

diff --git a/hdl/fpga/platforms/bladerf-micro/build/nios_system.tcl b/hdl/fpga/platforms/bladerf-micro/build/nios_system.tcl
index 6530f959..248b09fd 100644
--- a/hdl/fpga/platforms/bladerf-micro/build/nios_system.tcl
+++ b/hdl/fpga/platforms/bladerf-micro/build/nios_system.tcl
@@ -496,7 +496,7 @@ set_connection_parameter_value nios2.data_master/peripheral_spi.spi_control_port
 
 add_connection nios2.data_master ram.s1
 set_connection_parameter_value nios2.data_master/ram.s1 arbitrationPriority {1}
-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.data_master/ram.s1 defaultConnection {0}
 
 add_connection nios2.data_master rffe_spi.spi_control_port
@@ -556,7 +556,7 @@ set_connection_parameter_value nios2.instruction_master/nios2.debug_mem_slave de
 
 add_connection nios2.instruction_master ram.s1
 set_connection_parameter_value nios2.instruction_master/ram.s1 arbitrationPriority {1}
-set_connection_parameter_value nios2.instruction_master/ram.s1 baseAddress {0x00020000}
+set_connection_parameter_value nios2.instruction_master/ram.s1 baseAddress {0x00040000}
 set_connection_parameter_value nios2.instruction_master/ram.s1 defaultConnection {0}
 
 add_connection nios2.irq command_uart.interrupt
diff --git a/hdl/fpga/platforms/bladerf-micro/build/platform.conf b/hdl/fpga/platforms/bladerf-micro/build/platform.conf
index 2b07a44c..422e4a52 100644
--- a/hdl/fpga/platforms/bladerf-micro/build/platform.conf
+++ b/hdl/fpga/platforms/bladerf-micro/build/platform.conf
@@ -38,7 +38,7 @@ function get_device_family() {
 # RAM during Qsys generation
 function get_qsys_ram() {
     if [ "${1}" == "A4" ] || [ "${1}" == "A5" ] || [ "${1}" == "A9" ]; then
-        rams=131072
+        rams=262144
     else
         rams=32768
     fi

[daisymaria]

Compiler optimization flags control the level of optimization applied to the code during compilation. Uno Online

[approvaltrivial]

Compiler optimization flags,dinosaur game such as -O0, are directives given to the compiler to control the level of optimization applied to the generated code.