Hi, Andrew, On Jul 19, 2013, at 7:14 AM, Andrew Martens wrote:
> In my recent adventures into the fft library I did come across a bug that > affects fft_biplex_real_4x (and by extension fft_wideband_real) output. > > It was in the init script for mirror_spectrum used in the bi_real_unscr_4x > block. There was a swap in latency settings for delay blocks for the sync > input (sync_delay0 and sync_delay1 specifically). This caused some of the > output channels to be swapped on output (with the actual fft_bins affected > depending on latency settings). Unfortunately, this bug was introduced in > commit 007f55c55 (in 2011) so has been around affecting our data for a while. > This is fixed in the latest fft changes in the ska-sa repo on github. I am not able to reproduce this bug using the many different parameter settings of the the fft_wideband_real and fft_biplex_real_x4 blocks that I tried. Can you please provide more details of the parameter settings that exposed this problem for you? What part of commit 007f55c55 introduced the bug? As far as I can tell, that just converted the existing mirror_spectrum block to xblocks and added a mask initialization script for it, but I don't think there was any real change in functionality. If you drill down into fft_biplex_real_4x_delay_bram_test.mdl, you'll see that it still has the pre-xblock version of mirror_spectrum, which you can compare with the mirror_spectrum_init.m introduced in commit 007f55c55. FWIW, I'm not really big fan of how the mirror_spectrum block is implemented. As far as I can tell, it seems to re-align sync and data to account for latency skew introduced by the parent subsystem! Anyone trying to use this block elsewhere will be in for an unpleasant surprise. Anyone trying to understand why this BRAM-free block has a "bram_latency" parameter will probably be somewhat confused for a while (I sure was). > You can see this bug clearly in simulation using an impulse response as input > to the fft. Input a pulse of amplitude 0.5 into the second fft input one > clock cycle after the sync pulse (0s on shift input). You should get a > complex exponential with frequency 1 (f(t-delta) <=> e^(-delta*fw)F(w)) on > the output. It is easy to see channel swapping as the output function is nice > and smooth. This is exactly the kind of test I did. I did not see any evidence of channel swapping, only nice smooth sinusoids. In any case, I'm not sure this would be John's problem since he says things simulate OK but misbehave in hardware. Thanks, Dave
