The OOT module .xml file definition currently only supports writing scalar
registers, so you need a custom C++ driver. The int_vector option has not
been implemented, and honestly I'm not sure if it would even make sense
because there's many different ways the HDL could implement a "vector" of
taps... it's not really a one-size-fits-all problem.
My recommendation would be to model your hf_chlizer's C++ driver on the
in-tree fir_block_ctrl_impl. Use the sr_write functions to program your
taps as your HDL code requires.
You'll notice fir_block_ctrl_impl uses integer taps. This ends up being a
little clumsy when developing flowgraphs, since your flowgraph application
needs to handle the floating point / fixed point conversion. In the past,
I've created a C++ driver that accepts floating point inputs and converts
to fixed point before programming to FPGA registers. Your preference.
Hope this helps,
On Tue, Aug 8, 2017 at 6:00 AM, Andrew Lanez via USRP-users <
> Typo, the 3rd to last paragraph should read:
> Or I could hack *rfnoc_fir_cci()*. I started this by replacing int vectors
> with std::complex vectors everywhere FIR taps were referenced in the
> in-tree module's C++ library but I stopped when it traced up to block.h
> because that may affect other modules.
> On Tue, Aug 8, 2017 at 2:56 AM, Andrew Lanez <switchla...@gmail.com>
>> I am developing a FIR filter that will eventually accepts complex taps
>> reprogrammable during runtime. As a first iteration, I want to verify it
>> works like the in-tree module with int_vector real taps. So I configure the
>> settings register in OOT module's .xml file to take int_vector taps but
>> running it returns:
>> RuntimeError: RuntimeError: not yet implemented: int_vector
>> I guess it's because the in-tree module's ettus.rfnoc_fir_cci() make
>> function supports int_vector whereas my rfnocmodtool generated make
>> function hf_chlizer.fir() does not.
>> So I changed my OOT module's .xml to use ettus.rfnoc_fir_cci() instead of
>> hf_chlizer.fir() and output shows both I and Q samples are filtered
>> identically by real taps.
>> But ettus.rfnoc_fir_cci() does not seem to support complex_vector taps.
>> So I must revert to hf_chlizer.fir() in which case I get:
>> RuntimeError: RuntimeError: Invalid block definition in
>> /home/switchlanez/rfnoc/share/uhd/rfnoc/blocks/fir.xml: RuntimeError:
>> Found invalid arguments for block fir.
>> Or I could hack hf_chlizer.fir(). I started this by replacing int vectors
>> with std::complex vectors everywhere FIR taps were referenced in the
>> in-tree module's C++ library but I stopped when it traced up to block.h
>> because that may affect other modules.
>> 1) What's the best approach to implement a vector of complex taps
>> reprogrammable during runtime?
>> 2) My verilog code assumes one complex tap is 32 bits (leftmost 16 bits
>> for I, rightmost 16 bits for Q) and formats complex samples the same
>> (in-tree module also handles complex sample this way). Will UHD
>> automatically convert complex floats incoming from the host to sc16 for the
>> embedded settings registers?
> USRP-users mailing list
USRP-users mailing list