Accumulation length is typically measured in FFT windows. So for your case, you have 2048 point FFT and 4 samples per clock, so that means one FFT window every 2048/4 = 512 FPGA clocks. So if accum length is 1024, that would be 1024*512 clocks = 512 kClocks, and at 100 MHz FPGA clock, that's about 5 milliseconds. The data rate is just how much data you are taking per accumulation divided by the accumulation length in seconds. So in your case, you have 2048 real FFT points -> 1024 complex channels, and then if you have 4 inputs, that's 10 total terms (4 auto correlations and 6 cross terms if i did the math right). If each is stored as a 32 bit real, 32 bit imaginary, that's 80 bytes per channel, or 80*1024 = 80 kB per accumulation. So if your accum length were 5 ms, that's 80 kB / 5e-3 s = 16.384e6 bytes/s
On Mon, Aug 4, 2014 at 12:18 PM, Rolando Paz <[email protected]> wrote: > Thanks again Glenn. > > In Peter MacMahon's User Guide for the Parkes Radio Telescope, this reads: > > Accumulation Length = 13 > Spectral Dump = 30,048 spectra per second > Data Rate = 471Mbits/second > > Accumulation Length = 2 > Spectral Dump = 195.313 spectra per second > Data Rate = 2.99Gbits/second > > Accumulation Length = 1024 > Spectral Dump = 381 spectra per second > Data Rate = ? > > Accumulation Length = 256 > Spectral Dump = 1,526 spectra per second > Data Rate = ? > > What is the equation that relates these three variables: Accumulation > Length, Spectral Dump and Data Rate? > > Best Regards > > Rolando Paz > > > 2014-08-04 9:47 GMT-06:00 G Jones <[email protected]>: > > Hi Rolando, >> I think that sync period seems OK. Accumulation length is set by the user >> typically, but the default is probably fine. The one concern is that number >> is > 2^32, so be careful that your sync period register is set up to handle >> that case. The software registers are 32 bits wide, so it probably will >> overflow. In which case you should reduce accumulation length to make sure >> that sync period is < 2^32. When you do that, you'll also want to use the >> appropriate value for the accumulation length register, wherever that is in >> your design. >> >> Glenn >> >> >> On Mon, Aug 4, 2014 at 11:38 AM, Rolando Paz <[email protected]> wrote: >> >>> Hi All >>> >>> The sync_period is = n * k * LCM (reorder orders) * PFB_taps * >>> FFT_length / #simultaneous_inputs >>> >>> n=100 >>> k= 1460? (copied from poco) >>> LCM(2,2,2,9)=18 >>> PFB_taps=4 >>> FFT_length=2048 >>> #simultaneous_inputs=4 >>> >>> sync_period= 5382144000 >>> >>> 1) Is this sync_period correct? >>> 2) k is the Accumulation Length. How do I get this value? >>> 3) Is it correct the value of LCM (reorders)? >>> >>> Now I understand more the design, so more questions arise :-) >>> >>> Best Regards >>> >>> Rolando Paz >>> >>> >> >
