Re: [USRP-users] RFNOC REPLAY streaming to two UBX
Hi Rob, Thank you once again for answering my question! I have one more question? Did you change anything in the default FPGA image, in order to be able to sustain a maximum 125 MS/s for 4 channels on N310, or 200 MS/s for 2 channels on X310? By looking into x310_rfnoc_image_core.yml and the same is for n310_rfnoc_image_core.yml, I can notice that replay is connected over the crossbar to DUC. The Connection would look something like PCIe -> CrossBarSwitch ->* Replay -> CrossBarSwitch *-> DUC -> Radio. I can imagine that it would be more efficient to connect Replay directly to the DUC. PCIe -> CrossBarSwitch ->* Replay -> DUC -*> Radio. However, I am not sure, would that work with the new design due to the clock domain crossings? Kind Regards, EMil On Tue, Oct 6, 2020 at 3:40 PM Rob Kossler wrote: > Hi Emil, > With UHD 4.0, this works. And, the latest FPGA images from Ettus include > the Replay block on the X310 (in the past, this was just for the N310) so > you don't even have to build your own image. And, the latest FPGA images > provide access to the full 1GB ram such that you could store arb waveforms > for 2 channels with memory depth of 125M samps for each channel. > > I verified that I could play 4 channels at 125 MS/s from the UHD 4.0 > Replay block on the N310. I believe that I also verified 2 channels at 200 > MS/s on the X310, but I don't remember for certain. > > Rob > > On Tue, Oct 6, 2020 at 7:00 AM Emil Bjelski via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi All, >> >> I am investigating the option to stream samples from RFNOC_REPLAY block >> to two UBX-160 MHz cards with full speed (i.e. 200 Msps for each board). >> I would also like to support timing control for both of these two >> transmissions. >> >> I am planning to use new RFNOC architecture and UHD 4.0. >> However, before diving deeper I would like to hear from you if this is >> possible to be done in straightforward manner with the newest RFNOC >> developments. >> >> I see from the previous posts >> ( >> http://ettus.80997.x6.nabble.com/USRP-users-transmitting-on-two-channels-with-replay-block-td13915.html >> ). >> That with older RFNOC design and UHD 3.xxx streaming from RFNOC was >> limited to a single UBX radio. >> Meaning that an FPGA image with 2 Replay blocks was needed in order to >> stream samples to two UBXs radios. >> >> What would be the easiest way to proceed with new UHD 4.0? >> >> Thanks in advance on the answers, >> >> Emil >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] RFNOC REPLAY streaming to two UBX
Hi All, I am investigating the option to stream samples from RFNOC_REPLAY block to two UBX-160 MHz cards with full speed (i.e. 200 Msps for each board). I would also like to support timing control for both of these two transmissions. I am planning to use new RFNOC architecture and UHD 4.0. However, before diving deeper I would like to hear from you if this is possible to be done in straightforward manner with the newest RFNOC developments. I see from the previous posts ( http://ettus.80997.x6.nabble.com/USRP-users-transmitting-on-two-channels-with-replay-block-td13915.html ). That with older RFNOC design and UHD 3.xxx streaming from RFNOC was limited to a single UBX radio. Meaning that an FPGA image with 2 Replay blocks was needed in order to stream samples to two UBXs radios. What would be the easiest way to proceed with new UHD 4.0? Thanks in advance on the answers, Emil ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Installation from source (Gnuradio 3.8.2.0 on Ubuntu 18.04.05) - test failure qa_cpp_py_binding (Failed) ...
Hi Michael, I agree with you comments 1) and 2) therefore I will disable Thrift and CTRLPORT. Related to 3) before posting questions I was checking mailing lists and I read that CTRLPORT should work well with thrift *0.10.0.* Therefore I have installed thrift version 0.10.0., however there are still errors. Kind Regards, Emil On Sun, Oct 4, 2020 at 5:33 PM Michael Dickens wrote: > Hi Emil - A few thoughts: > > 1) This is a GNU Radio question; not a USRP one. You'd be better served by > querying the GR discussion list < > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >. > > 2) Those failing tests are related to CTRLPORT and it's use of Thrift. > Unless you are going to be using the CTRLPORT feature of GNU Radio, then > you should disable that component as well as the use of Thrift ... just > don't use it. If you don't know what it is, then you don't need it. > > 3) CTRLPORT / Thrift interface has not been actively maintained for years, > and Thrift keeps moving forward ... so, there are likely to be > incompatibilities between them ... might be there already. If I recall > correctly, CTRLPORT's Thrift interface works with Thrift versions 0.10.0 > and 0.11.0 ... might work with 0.12.0 ... and has issues with 0.13.0 (the > current Thrift release). I might be wrong here too. Hence: What version of > Thrift are you using? Can you revert to, say, 0.11.0? That might help here. > > I hope this is useful! - MLD > > > > On Sun, Oct 4, 2020 at 5:28 AM Emil Bjelski via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi All, >> >> I getting errors when calling make test, while installing Gnuradio >> 3.8.2.0 on Ubuntu 18.04.05. >> I have also installed thrift version 0.10.0. >> >> These are errors >> `99% tests passed, 3 tests failed out of 368 >> Total Test time (real) = 166.29 sec >> The following tests FAILED: >> 171 - qa_cpp_py_binding (Failed) >> 172 - qa_cpp_py_binding_set (Failed) >> 173 - qa_ctrlport_probes (Failed) >> Errors while running CTest` >> >> Further if I call >> >> ctest --output-on-failure >> >> I get following >> >> `170/368 Test #170: qa_copy >> Passed0.46 sec >> Start 171: qa_cpp_py_binding >> 171/368 Test #171: qa_cpp_py_binding >> ..***Failed0.83 sec >> EE >> == >> ERROR: test_001 (__main__.test_cpp_py_binding) >> -- >> Traceback (most recent call last): >> File >> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding.py", >> line 111, in test_001 >> rval = v1.get() >> File >> "/home/tkazaz/workarea/gnuradio/build/gnuradio-runtime/python/gnuradio/gr/../../../swig/runtime_swig.py", >> line 7519, in get >> return _runtime_swig.RPC_get_string_get(self) >> RuntimeError: basic_string::_M_construct null not valid >> >> == >> ERROR: test_002 (__main__.test_cpp_py_binding) >> -- >> Traceback (most recent call last): >> File >> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding.py", >> line 162, in test_002 >> radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift') >> TypeError: __init__() got an unexpected keyword argument 'argv' >> >> -- >> Ran 2 tests in 0.352s >> >> FAILED (errors=2) >> DEPRECATED: Using filename with gr_unittest does no longer have any >> effect. >> >> Start 172: qa_cpp_py_binding_set >> 172/368 Test #172: qa_cpp_py_binding_set >> ..***Failed0.71 sec >> EE >> == >> ERROR: test_001 (__main__.test_cpp_py_binding_set) >> -- >> Traceback (most recent call last): >> File >> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding_set.py", >> line 107, in test_001 >> rval = g3.get() >> File >> "/home/tkazaz/workarea/gnuradio/build/gnuradio-runtime/python/gnuradio/gr/../../../swig/runtime_swig.py", >> line 7519, in get >> return _runtime_swig.RPC_
[USRP-users] Installation from source (Gnuradio 3.8.2.0 on Ubuntu 18.04.05) - test failure qa_cpp_py_binding (Failed) ...
Hi All, I getting errors when calling make test, while installing Gnuradio 3.8.2.0 on Ubuntu 18.04.05. I have also installed thrift version 0.10.0. These are errors `99% tests passed, 3 tests failed out of 368 Total Test time (real) = 166.29 sec The following tests FAILED: 171 - qa_cpp_py_binding (Failed) 172 - qa_cpp_py_binding_set (Failed) 173 - qa_ctrlport_probes (Failed) Errors while running CTest` Further if I call ctest --output-on-failure I get following `170/368 Test #170: qa_copy Passed0.46 sec Start 171: qa_cpp_py_binding 171/368 Test #171: qa_cpp_py_binding ..***Failed0.83 sec EE == ERROR: test_001 (__main__.test_cpp_py_binding) -- Traceback (most recent call last): File "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding.py", line 111, in test_001 rval = v1.get() File "/home/tkazaz/workarea/gnuradio/build/gnuradio-runtime/python/gnuradio/gr/../../../swig/runtime_swig.py", line 7519, in get return _runtime_swig.RPC_get_string_get(self) RuntimeError: basic_string::_M_construct null not valid == ERROR: test_002 (__main__.test_cpp_py_binding) -- Traceback (most recent call last): File "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding.py", line 162, in test_002 radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift') TypeError: __init__() got an unexpected keyword argument 'argv' -- Ran 2 tests in 0.352s FAILED (errors=2) DEPRECATED: Using filename with gr_unittest does no longer have any effect. Start 172: qa_cpp_py_binding_set 172/368 Test #172: qa_cpp_py_binding_set ..***Failed0.71 sec EE == ERROR: test_001 (__main__.test_cpp_py_binding_set) -- Traceback (most recent call last): File "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding_set.py", line 107, in test_001 rval = g3.get() File "/home/tkazaz/workarea/gnuradio/build/gnuradio-runtime/python/gnuradio/gr/../../../swig/runtime_swig.py", line 7519, in get return _runtime_swig.RPC_get_string_get(self) RuntimeError: basic_string::_M_construct null not valid == ERROR: test_002 (__main__.test_cpp_py_binding_set) -- Traceback (most recent call last): File "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding_set.py", line 129, in test_002 radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift') TypeError: __init__() got an unexpected keyword argument 'argv' -- Ran 2 tests in 0.253s FAILED (errors=2) DEPRECATED: Using filename with gr_unittest does no longer have any effect. Start 173: qa_ctrlport_probes 173/368 Test #173: qa_ctrlport_probes .***Failed1.18 sec E == ERROR: test_001 (__main__.test_ctrlport_probes) -- Traceback (most recent call last): File "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_ctrlport_probes.py", line 67, in test_001 radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift') TypeError: __init__() got an unexpected keyword argument 'argv' == ERROR: test_002 (__main__.test_ctrlport_probes) -- Traceback (most recent call last): File "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_ctrlport_probes.py", line 108, in test_002 radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift') TypeError: __init__() got an unexpected keyword argument 'argv' == ERROR: test_003 (__main__.test_ctrlport_probes) -- Traceback (most recent call last): File "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_ctrlport_probes.py", line 148, in test_003 radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift') TypeError: __init__() got an unexpected keyword argument 'argv' == ERROR: test_004
Re: [USRP-users] Error while installing RFNOC on ubuntu 18.04.5
Hi Michael, I would like to install the latest release and UHD 4.0. Could you point me where I can find the precompiled binaries? Thank you a lot on your reply, Emil On Fri, Oct 2, 2020 at 3:30 PM Michael Dickens wrote: > Hi Emil - What branch of UHD and GR are you trying to build? That AppNote > is a bit dated, and needs a serious update! If what you want is the latest > releases of UHD and GR, for many OSs those are available for download and > install as precompiled binaries. - MLD > > On Fri, Oct 2, 2020 at 8:59 AM Emil Bjelski via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi All, >> >> I am installing RFNOC using pyboms by following instructions given on >> https://kb.ettus.com/Getting_Started_with_RFNoC_Development >> >> However, during installation, there is an error (given below). >> Does anyone know what could be the issue? >> >> Thank you in advance on answers. >> >> [ 86%] Building CXX object >> gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/usrp_source_impl.cc.o >> In file included from >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcregisterhelpers.h:26:0, >> from >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/basic_block.h:42, >> from >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/block.h:27, >> from >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/sync_block.h:27, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/include/gnuradio/uhd/usrp_block.h:26, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_block_impl.h:26, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.h:23, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:24: >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager.h:56:17: >> warning: ‘template class std::auto_ptr’ is deprecated >> [-Wdeprecated-declarations] >> static std::auto_ptr boot; >> ^~~~ >> In file included from /usr/include/c++/7/bits/locale_conv.h:41:0, >> from /usr/include/c++/7/locale:43, >> from /usr/include/boost/format.hpp:23, >> from /home/emil/rfnoc/include/uhd/types/dict.ipp:12, >> from /home/emil/rfnoc/include/uhd/types/dict.hpp:154, >> from >> /home/emil/rfnoc/include/uhd/types/device_addr.hpp:11, >> from /home/emil/rfnoc/include/uhd/stream.hpp:11, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/lib/gr_uhd_common.h:26, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:23: >> /usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here >>template class auto_ptr; >> ^~~~ >> In file included from >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcregisterhelpers.h:26:0, >> from >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/basic_block.h:42, >> from >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/block.h:27, >> from >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/sync_block.h:27, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/include/gnuradio/uhd/usrp_block.h:26, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_block_impl.h:26, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.h:23, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:24: >> /home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager.h:57:17: >> warning: ‘template class std::auto_ptr’ is deprecated >> [-Wdeprecated-declarations] >> static std::auto_ptr aggregator; >> ^~~~ >> In file included from /usr/include/c++/7/bits/locale_conv.h:41:0, >> from /usr/include/c++/7/locale:43, >> from /usr/include/boost/format.hpp:23, >> from /home/emil/rfnoc/include/uhd/types/dict.ipp:12, >> from /home/emil/rfnoc/include/uhd/types/dict.hpp:154, >> from >> /home/emil/rfnoc/include/uhd/types/device_addr.hpp:11, >> from /home/emil/rfnoc/include/uhd/stream.hpp:11, >> from >> /home/emil/rfnoc/src/gnuradio/gr-uhd/lib/gr_uhd_common.
[USRP-users] Error while installing RFNOC on ubuntu 18.04.5
Hi All,
I am installing RFNOC using pyboms by following instructions given on
https://kb.ettus.com/Getting_Started_with_RFNoC_Development
However, during installation, there is an error (given below).
Does anyone know what could be the issue?
Thank you in advance on answers.
[ 86%] Building CXX object
gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/usrp_source_impl.cc.o
In file included from
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcregisterhelpers.h:26:0,
from
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/basic_block.h:42,
from
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/block.h:27,
from
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/sync_block.h:27,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/include/gnuradio/uhd/usrp_block.h:26,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_block_impl.h:26,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.h:23,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:24:
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager.h:56:17:
warning: ‘template class std::auto_ptr’ is deprecated
[-Wdeprecated-declarations]
static std::auto_ptr boot;
^~~~
In file included from /usr/include/c++/7/bits/locale_conv.h:41:0,
from /usr/include/c++/7/locale:43,
from /usr/include/boost/format.hpp:23,
from /home/emil/rfnoc/include/uhd/types/dict.ipp:12,
from /home/emil/rfnoc/include/uhd/types/dict.hpp:154,
from /home/emil/rfnoc/include/uhd/types/device_addr.hpp:11,
from /home/emil/rfnoc/include/uhd/stream.hpp:11,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/gr_uhd_common.h:26,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:23:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
template class auto_ptr;
^~~~
In file included from
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcregisterhelpers.h:26:0,
from
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/basic_block.h:42,
from
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/block.h:27,
from
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/sync_block.h:27,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/include/gnuradio/uhd/usrp_block.h:26,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_block_impl.h:26,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.h:23,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:24:
/home/emil/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager.h:57:17:
warning: ‘template class std::auto_ptr’ is deprecated
[-Wdeprecated-declarations]
static std::auto_ptr aggregator;
^~~~
In file included from /usr/include/c++/7/bits/locale_conv.h:41:0,
from /usr/include/c++/7/locale:43,
from /usr/include/boost/format.hpp:23,
from /home/emil/rfnoc/include/uhd/types/dict.ipp:12,
from /home/emil/rfnoc/include/uhd/types/dict.hpp:154,
from /home/emil/rfnoc/include/uhd/types/device_addr.hpp:11,
from /home/emil/rfnoc/include/uhd/stream.hpp:11,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/gr_uhd_common.h:26,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:23:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
template class auto_ptr;
^~~~
In file included from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.h:24:0,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:24:
/home/emil/rfnoc/src/gnuradio/gr-uhd/include/gnuradio/uhd/usrp_source.h:31:19:
error: redefinition of ‘struct uhd::stream_args_t’
struct GR_UHD_API stream_args_t {
^
In file included from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/gr_uhd_common.h:26:0,
from
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:23:
/home/emil/rfnoc/include/uhd/stream.hpp:58:16: note: previous definition of
‘struct uhd::stream_args_t’
struct UHD_API stream_args_t
^
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc: In
constructor ‘gr::uhd::usrp_source_impl::usrp_source_impl(const
uhd::device_addr_t&, const uhd::stream_args_t&, bool)’:
/home/emil/rfnoc/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:74:7: error:
class ‘gr::uhd::usrp_source_impl’ does not have any field named
‘_recv_timeout’
_recv_timeout(0.1), // seconds
^
[USRP-users] RFNoC Replay Bloch timmed commands
Hello All, I would like to use RFNoC Replay Block with timed commands, in order to transmit waveform at allocated time slots. I see relatively new post and Ettus wiki ( https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD) which mentions that Replay Block can be used with timed commands. (see line "Using RFNoC blocks like the Replay Block to transmit phase coherent bursts"). In same time I have found an earlier post ( http://ettus.80997.x6.nabble.com/USRP-users-X310-Replay-Block-and-receiver-timming-td11818.html ) where it is mentioned that Replay Block does not support timed commands. I am wondering what is current status related to support of timed commands with Replay Block? Kind Regards, Tarik ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC SVD Block
Hi Adnan, Take a look to this document https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_3/ug902-vivado-high-level-synthesis.pdf . I feel that HLS is the way to go. However, if I remember correctly the maximum size of the matrix that is supported by HLS linpack implementation of the SVD is *8x8.* Just due to my curiosity. Why do not you buffer samples and perform SVD in the software? (I feel that that will be much easier). Cheers, Emil On Wed, Sep 11, 2019 at 6:45 PM Quadri,Adnan via USRP-users < usrp-users@lists.ettus.com> wrote: > This Verilog AXI is so amazing. I just went through the project link > quickly. > > We can test our verilog implementation on GRC! This will be so helpful. > Thank you so much for sharing the information. > > Adnan > -- > *From:* Marcus Müller > *Sent:* Wednesday, September 11, 2019 11:34 AM > *To:* Quadri,Adnan ; > usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] RFNoC SVD Block > > Thanks! I'm always curious about how our hard- and software > infrastructure is being used! > > By the way, in case you want to test a verilog SVD implementation > within a signal processing framework: Bowen Hu did a very interesting > Google Summer of Code project this year, in which he made it possible > to just drop in a Verilog Module in a GNU Radio block and use that to > do signal processing in a pure host computer simulation. He'll be at > GRCon this year! > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_B0WEN-2DHU_gr-2Dverilog=DwIDaQ=OAG1LQNACBDguGvBeNj18Swhr9TMTjS-x4O_KuapPgY=JoNl3b2Pn0MHhs668QvjpcSGl6s3MEmtJLBypH6x02U=OAza1LeUx_20PABZFpa8SFpGhqGusnLgCJPv8Qn9IY4=RVT10qjiHFS4-MdCMHF5eFq0-VWOEryN7swfWuOKkZI= > > > Best regards, > Marcus > On Wed, 2019-09-11 at 15:13 +, Quadri,Adnan wrote: > > Hello, > > > > Thanks for your prompt response and sorry for my delayed one. > > > > I have thought about the first option you have discussed, which is to > > use already implemented SVD but modify it to fit with the nocshell. > > > > As we go down that way, I will update this thread with questions or > > any significant findings. > > > > Thank you, > > Adnan > > From: Marcus Müller > > Sent: Friday, September 6, 2019 4:00 PM > > To: Quadri,Adnan ; > > usrp-users@lists.ettus.com > > Subject: Re: [USRP-users] RFNoC SVD Block > > > > Hello Adnan, > > > > I'm currently not aware of anyone doing that. > > > > However, since one of the typical applications of beefier FPGAs is > > math > > accelerators for linear algebra problems, it's more than likely > > someone > > did in fact implement an SVD before, and you might just need to > > connect > > it to a nocshell to make it work in RFNoC. There's a lot of > > interesting > > papers out there on SVD implementations for fixed point math on > > FPGAs, > > I think Drexel uni had some interesting stuff for SVD-based channel > > estimation for OFDM. I've not seen any code of them, though... > > > > So, from an algorithmic point of view, an SVD isn't too hard. IIRC, > > sequential algorithms can work in-place, and thus (for a m×n matrix, > > n>m) don't need more than n² space for intermediate and final result > > (+2m for index and scale storage if you want to pivot elegantly). > > > > Now, I've not ever implemented more than a C++ QR decomposition > > (which > > is the core algorithm for most EVD problems, which you typically > > householder-transform an SVD problem to), so I'm really not competent > > to comment on hardware implementations, but chances are you want to > > compute a lot of result values in parallel if you're doing it in the > > FPGA – because otherwise, you'd abhor doing much work in hardware > > (that > > being _hard_) in favor of doing it easier-to-debug and also free-to- > > have in the shape of LAPACK software. (Subtext message, more for > > future > > readers than for you: Evaluate whether something really should be > > done > > in hardware; it's not inherently better to do things in hardware.) > > But that parallelism might imply that in-place is not a feasible way > > of > > computing things, and your memory requirements might be much larger. > > Depending on the size of SVD you're planning to do, that might or > > might > > not be an issue. > > > > Best regards, > > Marcus > > > > On Fri, 2019-09-06 at 19:05 +, Quadri,Adnan via USRP-users wrote: > > > Hello, > > > > > > We are trying to perform singular vector decomposition. The idea is > > > to work on an RFNoC block that takes in summation of samples from > > the > > > Radio source and will perform SVD. > > > > > > Is anybody working on something similar? > > > Currently, the RFNoC OFDM synchronizer block has timing constraint > > > issues and can't be used to build FPGA image. > > > > > > Just asking around to get some suggestions/advice and idea if > > working > > > on that Verilog implementation of SVD is something doable and if > > > anybody tried anything similar. > > > > > > Thank you, > >
Re: [USRP-users] Compiling UHD examples errors
Hi, I want to compile and install one of the existing example scripts that are located in */rfnoc/src/uhd/host/examples/*. As a first step, I decided to use existing CMakeLists.txt for init_usrp. However, after calling in */rfnoc/src/uhd/host/examples/init_usrp* *cmake ../* I get error: *CMake Error at CMakeLists.txt:52 (UHD_INSTALL): Unknown CMake command "UHD_INSTALL".CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 3.3)*... On Tue, Aug 13, 2019 at 7:31 PM Michael Dickens wrote: > OK; that OS is great for GR / UHD / RFNoC work. What step are you on in > the guide? > > On Tue, Aug 13, 2019, at 12:51 PM, Emil Bjelski wrote: > > Hello Michael, > > I am using Ubuntu 18.04.2 LTS. > > I installed UHD, GnuRadio and RFNoC using pybombs by following "Getting > stared with RFNoC development tutorial": > https://kb.ettus.com/Getting_Started_with_RFNoC_Development > > Kind Regards, > > Emil > > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Compiling UHD examples errors
Hello Michael, I am using Ubuntu 18.04.2 LTS. I installed UHD, GnuRadio and RFNoC using pybombs by following "Getting stared with RFNoC development tutorial": https://kb.ettus.com/Getting_Started_with_RFNoC_Development Kind Regards, Emil On Tue, Aug 13, 2019 at 5:12 PM Michael Dickens wrote: > Hi Emil - Can you tell us what OS you're using for the UHD host computer? > If you're trying to compile UHD from source, which version of UHD (release > / GIT / version). Those are useful starting points. Cheers! - MLD > > On Tue, Aug 13, 2019, at 10:47 AM, Emil Bjelski via USRP-users wrote: > > Hello everyone, > > I trying to compile UHD examples following tutorial provided here: > https://kb.ettus.com/Getting_Started_with_UHD_and_C%2B%2B > > However, I am facing issue when runining: > cmake ../ > > I get this error: > CMake Error at CMakeLists.txt:52 (UHD_INSTALL): > Unknown CMake command "UHD_INSTALL". > > -- Configuring incomplete, errors occurred! > > > I am sure that uhd is installed as I am able to execute command > uhd_find devices. > > What could be the issue? > > Thanks, > > Emil > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Compiling UHD examples errors
Hello everyone, I trying to compile UHD examples following tutorial provided here: https://kb.ettus.com/Getting_Started_with_UHD_and_C%2B%2B However, I am facing issue when runining: cmake ../ I get this error: CMake Error at CMakeLists.txt:52 (UHD_INSTALL): Unknown CMake command "UHD_INSTALL". -- Configuring incomplete, errors occurred! I am sure that uhd is installed as I am able to execute command uhd_find devices. What could be the issue? Thanks, Emil ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Burst detection, DRAM buffering and streaming to PC
Hello everyone, I am implementing the system on USRP X310 where the maximum sampling rate needs to be used on both Rx channels, so in total ( 2 (IQ) x 2 (RF cards) x 200 MSPs). After doing tests of throughput between USRP and PC, I experience that there will be bottleneck related to writing samples in memory of PC (I am using SSD). This is also confirmed by numerous previous post on the usrp mailing list. Before I describe what is my question and idea, I will shortly describe system requirements. My system needs to sample data periodically as I am sending bursts of data from time to time. One burst sent from Tx can have a duration of 6-10ms, then there is a gap of 10 ms, after which I am again sending a burst of data (signal). So in short, I would have at maximum 10 ms of data then gap of 10ms (or more if needed) sampled at highest X310 sampling rate 800MSPs. My idea is to develop RFNoC CE for burst detection (the burst contains preamble with good correlation properties). This RFNoC CE would indicate when there are valuable samples available for streaming to PC. Therefore, my idea would be to stream only samples that correspond to a valuable signal to PC. In the worst case, I would have ~16MB of data to transfer every 10ms (this would result in throughput of ~1.6GB/s). Saving 16MB of data in BRAM might not be a good approach. Therefore I would like to save 16MB in DRAM (DDR3) memory, and from DDR3 Stream data to PC. However, after reading several posts on the mailing list I am confused if there are already available block which could support me in the development of DRAM FIFO controlled by the burst detector. I am aware of RFNoC reply functionality for Tx side, however, I am not aware if there is an example where samples are streamed from DRAM to PC. Summarizing my goal in the logical diagram: |Radio Block| > |Burst Detector| || | YES/NO | /<-- |->|DRAM FIFO|--->|PCIe| My questions would: 1. What is the maximum writing speed to DRAM on X310? 2. Are they already available RFNoC block which would support the development of controlled DRAM FIFO? 3. In general, if you have any useful comments, guidelines please let me know. Thanks a lot, Emil ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
