OOT RFNoC Block not automatically recognized (and then don't propagate actions and properties)

[f380cedric]

Issue Description

Due to a bug in UHD4, OOT blocks (as described in 1) are not recognized by UHD.
One of the drawbacks is that the custom controller is not used, falling back to the noc_block_base controller with unknown registration.
This controller does not seem to forward action such as issue_stream_cmd.

It does mean that in graph such as radio → ddc → gain_block → rx_streamer,
issuing issue_stream_cmd on rx_streamer does not reach the radio, being dropped by the gain_block.

One workaround is to issue the stream command on the ddc/radio block.
Another is to build part of the block OOT (the verilog part), while building the custom controller part (hpp/cpp) in-tree.
However, I think it should work without a custom controller (and relying only on noc_block_base).

Setup Details

• UHD/FPGA: e520e3f (UHD-4.0 branch)
• OS: Debian GNU/Linux bullseye/sid
• USRP model: X310

Expected Behavior

OOT without custom block should forward command by default, in particular the issue_stream_cmd.

Actual Behaviour

The action seems to be blocked/dropped by the custom block.

Steps to reproduce the problem

• clone + build UHD-git-e520e3ff8ee0dde4a1630ea198d7a506bbc6fb26
• cp -r "$UHD_DIR"/host/examples/rfnoc-example /tmp/
• cd /tmp/rfnoc-example/
• cmake -S . -B build -DUHD_FPGA_DIR="$UHD_DIR"/fpga
• cd build && make
• sudo make install
• make x310_rfnoc_image_core
• viv_jtag_program $FILEPATH_TO_DOT_BIT # Or using uhd_image_loader
• cd "$UHD_DIR"/host/examples
• Download the patch attachment.txt
• patch < attachment.txt
• g++ -g -o test rfnoc_rx_to_file.cpp -lboost_program_options -luhd
• ./test --rate 20e6 --block-id '0/Block#0' --spp 256 --progress # it times out, the RX LED stays off.

Additional Information

Mailing list discussion: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2021-January/063522.html

[f380cedric]

Rob from usrp-user mailing list has probably found the issue:

I previously did not have the link options correct for building OOT. If
you look in the CMakeLists.txt file in the Ettus rfnoc example apps folder,
you will see a link option "-Wl,--no-as-needed". I didn't look into it
thoroughly, but without that option, the OOT blocks do not get linked in
(or at least their code to register themselves at startup never executes).
Once I added this linker option to my custom app, the OOT blocks register
fine and behave normally.

So
g++ -g -o test rfnoc_rx_to_file.cpp -lboost_program_options -luhd
should be
g++ -g -o test rfnoc_rx_to_file.cpp -lboost_program_options -luhd -Wl,--no-as-needed -lrfnoc_example
otherwise the OOT controller library is not correctly linked to the executable.

I cannot test it, could someone test it?

[jpendlum]

I am unable to reproduce this issue in a GNU Radio OOT module made with rfnocmodtool. I verified both that the gain block's block controller is being loaded (i.e. you don't have to use the generic "Block#0" block ID) and that the flowgraph radio → ddc → gain_block → rx_streamer works as expected.

@f380cedric Do you want to try making a gain block using rfnocmodtool? The RFNoC4 Workshop has instructions on how to do this: https://www.youtube.com/watch?v=M9ntwQie9vs (starts at around 29:14)

[f380cedric]

@f380cedric Do you want to try making a gain block using rfnocmodtool?

Thanks for the reply.
However, my interest is to make it work with custom C++ program.
I have little to no interest in GnuRadio.

If my previous comment was not clear:
I think using compiled examples in the OOT (under apps folder)
or compiled GnuRadio block should work out of the box, as stated by your comment.
The issue is when you want to build a custom C++ program out of the OOT tree, ie. without using the provided CMakeLists.txt.
The shared library of the OOT module is not correctly linked
without -Wl,--no-as-needed (linker option that is present in the provided CMake rules).

I do not use UHD4 anymore, so I cannot verify it.
I will close the issue as soon as someone verifies that adding -Wl,--no-as-needed to g++ solves the linkage issue.

[mbr0wn]

It looks like the problem is that UHD doesn't load the custom DLLs automatically, and the default block controller DROPs actions and property propagation. I think these are both issues we can (and should) address.

I'm guessing an easier fix than providing custom linker flags would be to LD_PRELOAD the DLL.

[mbr0wn]

We've added support for more easily auto-loading OOT DLLs, so I'll be closing this.