get stuck when load software.bin through /dev/ttyUSB1

[Siris-Li]

I have raised a similar question #775 before, but this time it's quite a different case.
My working environment is VM Ubuntu 20.04, arty A7 35T board, symbiflow tools and the project I use is the proj_template under proj directory, which is one of the built-in default project.
When I run make load, it will be stuck at this command:
/home/limx/CFU-Playground/soc/bin/litex_term --speed 1843200 --kernel /home/limx/CFU-Playground/proj/proj_template/build/software.bin /dev/ttyUSB1
I have tried the following methods to solve it, but failed:

1. Reduce the UART_SPEED from the default 1843200 to 115200.
2. Press Ctrl + C or other keys on my keyboard. Press Ctrl + C twice quickly will end this command and other ways will cause nothing to happen.
3. Remove the whole CFU-Playground folder and rebuild everything by git clone.

[tcal-x]

@limingxuan-pku thank you for the report. I will try to reproduce the issue. It could be that the integration of Symbiflow tools with CFU Playground has broken somehow.

[tcal-x]

@limingxuan-pku , I have some updates.

Using the project proj/proj_template_v, which has a very small CFU, and compiling with USE_SYMBIFLOW=1, I saw unreliable behavior on my board. It would display the main menu, but usually when I selected some subtask, it would hang. This seems to indicate a marginal timing path. NOTE that this behavior can be different even we have the same board and part --- since it can come down to manufacturing variations whether a particular bitstream work work on your board or my board.

I did a further experiment; I made the CFU even simpler, just a bitwise-XOR as follows in cfu.v:

   //
   // select output -- note that we're not fully decoding the 3 function_id bits
   //
-  assign rsp_payload_outputs_0 = cmd_payload_function_id[0] ? 
-                                           cmd_payload_inputs_1 :
-                                           cmd_payload_inputs_0 ;
+  assign rsp_payload_outputs_0 = cmd_payload_inputs_1 ^ cmd_payload_inputs_0 ;

After I made this change, it worked reliably for me. Note that the software isn't even using CFU instructions in this project. I suspect that this change in the design led the tools to randomly end up with a better place/route solution.

The main challenge is this, the lack of feedback from the tools whether they think they have met timing.

Another experiment we could do is reducing the clock rate to a bit lower than the currently used 75MHz. However, we can't lower it too much, or else the DDR memory will start malfunctioning (it has a minimum clock rate requirement).

[tcal-x]

The unmodified proj/proj_template_v, which did not work reliably at first, did work reliably for me when I lowered the sys clock to 70MHz:

make clean
make USE_SYMBIFLOW=1 EXTRA_LITEX_ARGS="--sys-clk-freq=70000000"  prog
make USE_SYMBIFLOW=1 EXTRA_LITEX_ARGS="--sys-clk-freq=70000000"  load

[Siris-Li]

@tcal-x Thanks for your tests. I've tried your suggestions but it doesn't work for me.
However, I notice some information shown on my terminal when I try to run make prog.

python3 -m litex.soc.software.crcfbigen bios.bin --little
python3 -m litex.soc.software.memusage bios.elf /home/limx/CFU-Playground/soc/build/digilent_arty.proj_template/software/bios/../include/generated/regions.ld riscv64-linux-gnu

ROM usage: 27.40KiB     (21.41%)
RAM usage: 0.00KiB      (0.00%)

The RAM usage here is a little bit weird.

With all the environment and running parameter the same (use symbiflow, sys_clk=75MHz, arty a7 35t board, project under proj/proj_template) except that the OS changed from VM Ubuntu 20.04 to VM Ubuntu 18.04, I load everything on my board reliably. Here is the information shown on my terminal in VM Ubuntu 18.04 compared with the information before:

python3 -m litex.soc.software.crcfbigen bios.bin --little
python3 -m litex.soc.software.memusage bios.elf /home/limx/CFU-Playground/soc/build/digilent_arty.proj_template_v/software/bios/../include/generated/regions.ld riscv32-unknown-elf

ROM usage: 27.24KiB     (21.28%)
RAM usage: 1.61KiB      (20600.00%)

[tcal-x]

Thanks @limingxuan-pku I will try with 20.04 when time allows. Thanks again for the clarifying details.

[tcal-x]

On a new 20.04LTS VM on Google Cloud, using all tools from the Conda packages that I get from running make install-sf and make enter-sf, I see

python3 -m litex.soc.software.crcfbigen bios.bin --little
python3 -m litex.soc.software.memusage bios.elf /home/tcal/google/CFU-Playground/soc/build/digilent_arty.proj_template_v/software/bios/../include/generated/regions.ld riscv32-unknown-elf

ROM usage: 27.13KiB     (21.20%)
RAM usage: 1.61KiB      (20.12%)

[tcal-x]

On my personal laptop, 18.04LTS, I get:

python3 -m litex.soc.software.crcfbigen bios.bin --little
python3 -m litex.soc.software.memusage bios.elf /media/tim/GIT/clean/CFU-Playground/soc/build/digilent_arty.proj_template_v/software/bios/../include/generated/regions.ld riscv64-unknown-elf

ROM usage: 27.15KiB     (21.21%)
RAM usage: 1.61KiB      (20.12%)

so almost the same.

[Siris-Li]

@tcal-x Thanks for your tests! So the problem is most likely due to my VM environment. I'll rebuild my VM to see if it works.