Hi Andrew, As far as I can tell, that particular verilog block implements a 32-bit floating point to 16-bit fixed point conversion. The name may be a misnomer because it does not actually break the input into I/Q channels.
For floating to fixed conversion in software, I usually refer to this wikipedia page, which includes notation information and provides a quick/easy conversion: https://en.wikipedia.org/wiki/Q_(number_format) Usually my rule of thumb is that if there's a plausible way to do something in software, it's better to do it in software :D The C++ control block driver is a good place to wrap some helper code (e.g., converting taps, calculating magic numbers, etc etc) around your time-critical and performance-intensive FPGA operations. EJ On Sun, Aug 13, 2017 at 7:30 AM, Andrew Lanez <[email protected]> wrote: > 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/b108e88 > 865ee0fa68e685461681d8ca6a320b937/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
