EJ, I spent some time wrestling with the 32-bit to 16-bit conversion in my verilog noc block then realized doing the conversion in the C++ control block driver might be more straightforward. I'm trying to digest the following:
https://raw.githubusercontent.com/EttusResearch/fpga/b108e88865ee0fa68e685461681d8ca6a320b937/usrp3/lib/vita/float_to_iq.v I can't tell if that converter is fixed-point. I'm inclined to believe it's 16-bit compressed floating point. Do you or anyone have references to do an equivalent conversion in C++? Andrew On Thu, Aug 10, 2017 at 8:51 AM, EJ Kreinar <[email protected]> wrote: > 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
