Oh yeah... I actually knew that! Noticed that line several months ago but overlooked it this time because I was so determined to find the culprit for something else (Function Probe polling a file of tap values to rewrite taps to noc FIR block causes splashing across spectrum). Might post a new topic on that with video if we can't figure it out.
That half sample shift doesn't happen when we run noc_block_fir_filter against its SystemVerilog testbench. Hoping the shift only happens if datastream crosses from hardware to host domain which would be fine since our application keeps the datastream on hardware. Just not sure how to verify no half sample shift is happening in the hardware domain. On Fri, Apr 20, 2018 at 3:56 PM, Jon Pendlum via USRP-users < [email protected]> wrote: > Hey Andrew, > > The next line in fir_block_ctrl_impl.cpp sends the final tap: > sr_write(SR_RELOAD_TLAST, uint32_t(taps.back())); > > The half a sample shift is odd though. > > On Sat, Apr 21, 2018, 6:23 AM Marcus D. Leech via USRP-users < > [email protected]> wrote: > >> On 04/20/2018 12:01 PM, switchlanez via USRP-users wrote: >> >> Hello, >> >> >> >> An oddity regarding the RFNoC FIR Filter block. fir_block_ctrl_impl.cpp >> writes tap values to the settings registers with: >> >> >> >> for (size_t i = 0; i < taps.size() - 1; i++) { >> sr_write(SR_RELOAD, uint32_t(taps[i])); >> >> } >> >> >> >> which loops from 0 to taps.size() - 1. So if I define 41 taps from GRC, >> it only takes taps indexed from 0 to 39 and never writes tap index 40 (the >> 41st tap) to the settings register. >> >> >> >> I sort of confirmed this by comparing the RFNoC FIR Filter output >> against the GNU Radio Decimating FIR Filter (with Decimation=1) output with >> the same 41 taps and same input fed to both. Output gets shifted by half >> of a complex sample: >> >> >> >> GR FIR: >> >> 1 + .997j >> >> .994 + .991j >> >> .988 + ... >> >> >> >> RFNoC FIR: >> >> 0 + 1j >> >> .997 +.994j >> >> .991 + .988j >> >> >> >> Which is an effect of a FIR filter that has an even number of taps (40 >> instead of 41). >> >> >> >> So I modified the condition in the FIR driver file to write from 0 >> to taps.size() instead of taps.size()-1. Defined the 1st tap value to >> be 1000 with all remaining 40 taps as 0s. Viewed output on a spec an and >> saw nothing on output. Then moved the non-zero tap to the middle (21st >> index) with leading 20 and trailing 20 taps being 0s and saw the input fed >> to output. Now if I didn't modify the FIR driver file so it stops at >> taps.size()-1 and writes only 40 of my 41 taps and set the first tap to >> 1000 with 40 trailing zeros, I see input fed to output. Was the >> taps.size()-1 check intentional? >> >> >> >> Andrew >> >> This definitely looks to me like a subtle bug in the "off by one" error >> category. >> >> One of our RFNoC devs will probably chime in at this point, and provide >> an opinion.... >> >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
