Hi Wan My lack of documentation has caught up with me :)
Each stage in the FFT has a certain number of coefficients as well as a block that delays input data for a length of samples. These coefficients and delays can be implemented in distributed RAM or block RAMs (BRAMs). For very few coefficients/delays it is wasteful to use a whole BRAM (it is not possible to use 'part' of a BRAM (well, not easilyy that is)). These parameters allow you to choose the point at which storage is swapped from distributed RAM to BRAM and allows fine-tuning for designs. Increasing these values reduces the number of BRAMs used. This point used to be hard-coded but has been revealed in the 10.1 porting effort. Divide these values by the number of bits in your data stream (x2 as the input streams are complex) and coefficient size (x2 as the coefficients are complex) and you will get the number of data values/coefficients at which this change occurs; e.g If 'Input/Output bit width' is 25 bits and the 'Number bits above which to store stage's delay in BRAM' is 10 then the switch to BRAM will happen at (2^10/ (25*2) = 1024/50) around 20 delays. I would recommend using the following settings with the ROACH boards for the FFT blocks for maximum performance with minimal resource usage; Input/Output Bit Width - 25 (the DSP48E arithmetic blocks in Virtex5 support 25x18 bit multiplies, using less bits does not lead to much saving except routing resources) Coefficient Bit Width - 18 Add latency - 1 Mult Latency - 3 BRAM Latency - 3 Optimisation Target - Logic Number bits above which to store stage's coefficients in BRAM - 12 Number bits above which to store stage's delays in BRAM - 12 Don't specify the multiplier use (leave it as behavioral HDL) I will document things better as I find time. Regards Andrew 2009/6/23 <[email protected]> > Hi Andrew: > > Thanks for your information. > > I am still not sure on next two options in fft_wideband_real: > > Number bits above which to store stage's coeffcients in BRAM > Number bits above which to store stage's delay in BRAM > > Thanks > > Wan > > ------------------------------ > *From:* Andrew Martens [mailto:[email protected]] > *Sent:* Monday, 22 June 2009 8:48 PM > > *To:* Cheng, Wan (ATNF, Marsfield) > *Cc:* [email protected] > *Subject:* Re: [casper] about the shift input of FFT > > Hi Wan et al > > The 'convert with overflow indication', convert_of is now fixed and the > change propagated to the FFT subsection in the library so the FFT blocks > should now accurately indicate if an overflow occured. Please do an update > to get these changes. Note that the overflow bit does not go high with the > data that caused the overflow but a lot earlier and is to used as an > indicator that an overflow occured 'somewhere' . I will implement the delays > properly when I have more time again so that it lines up correctly. > > Regards > Andrew > > 2009/6/22 Andrew Martens <[email protected]> > >> Hi Wan >> >> The overflow block that generates the overflow output does not currently >> work properly, fixing it keeps slipping my mind. I will fix it as soon as I >> can. >> >> The FFT needs the same number of bits as there are stages i.e 5 stage = 5 >> bits. If you give it more it will just slice off the ones it needs and >> ignore the rest so 32 bits should be more than enough. >> >> >> Regards >> Andrew >> >> 2009/6/22 <[email protected]> >> >>> Hi Andrew: >>> >>> Now I can find the OF output from FFT module is high. Does this mean the >>> FFT is overflow? But I already set all shift bit to '1'. >>> >>> I an not very sure how many shift bits the FFT module has. I just give it >>> 32 bits width '1'. >>> >>> Thanks >>> >>> Wan >>> >>> ------------------------------ >>> *From:* Andrew Martens [mailto:[email protected]] >>> *Sent:* Monday, 22 June 2009 4:23 PM >>> *To:* Cheng, Wan (ATNF, Marsfield) >>> *Cc:* [email protected] >>> *Subject:* Re: [casper] about the shift input of FFT >>> >>> Hi Wan >>> >>> The FFT applies gain to any repeating input signal. You can view this >>> happening with the following MATLAB commands; >>> >>> x = 0:1:32; >>> y = sin(4*x*2*pi/32); >>> plot(abs(fft(y,32))); >>> >>> You will see that the output has spikes of height 16 instead of 1 which >>> you would expect from a sinusoid of amplitude 1. The FFT scales the signal >>> by 2^(n-1), where n is the number of stages in the FFT (a 32 bin fft has >>> log2(32) = 5 stages etc). >>> >>> This scaling has the potential to introduce overflow errors. >>> >>> The CASPER FFT allows you to remove the risk of overflows by shifting the >>> data down by one bit at each stage in the FFT. The shift input allows you to >>> set how much shifting is done. The default is normally to leave this all >>> '1's but it depends on what your input data looks like. >>> >>> I hope this answers your question. If you have MLIB_ROOT properly defined >>> in your environment, you should have access to some documentation on the FFT >>> (and most blocks). Press the 'Help' button in the mask dialog. >>> >>> Regards >>> Andrew >>> >>> 2009/6/22 <[email protected]> >>> >>>> Hi: >>>> >>>> Could anyone give me some idea on the function of shift input pin of >>>> FFT? >>>> I find some example design set it to all 1s. This means every stage are >>>> set to shift 1. What does this mean? >>>> >>>> Thanks >>>> >>>> Wan >>>> >>> >>> >> >
