Hi Andrew, 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, EJ On Tue, Aug 8, 2017 at 6:00 AM, Andrew Lanez via USRP-users < [email protected]> wrote: > 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 <[email protected]> > wrote: > >> Hi, >> >> 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? >> >> Thanks, >> Andrew >> > > > _______________________________________________ > USRP-users mailing list > [email protected] > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
