search

EttusResearch / uhd

The USRP™ Hardware Driver Repository
http://uhd.ettus.com
Other
995 stars 666 forks source link

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

Open f380cedric opened 3 years ago

f380cedric commented 3 years ago

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

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

Additional Information

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

f380cedric commented 3 years ago

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 commented 3 years ago

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.

image

@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 commented 3 years ago

@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 commented 2 years ago

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.